A common source of confusion is how to use SilverLining and Triton in applications that render to multiple windows or viewports. Both SilverLining and Triton can be configured to work in such environments, but there are a few tricks you should know about first.
The first thing you need to determine is whether your viewports can all share a single graphics context or device. If so, you may use the same SilverLining::Atmosphere, Triton::Ocean, and Triton::Environment class instances for every viewport, which keeps things very simple and efficient. Just use our SetCameraMatrix() and SetProjectionMatrix() functions to set the appropriate camera view and projection prior to rendering each view, and you’ll get the desired results – for the most part. SilverLining’s precipitation effects do need to know which camera you’re drawing. In order to ensure these effects work properly, be sure to also use the optional “camera” parameter on Atmosphere::DrawSky() and Atmosphere::DrawObjects – this can be a pointer to whatever class encapsulates your application’s cameras or views. All that matters is that it is a unique value for each viewport.
If you’re using OpenSceneGraph, it offers a GraphicsContext class you can use to share the same GraphicsContext among several views when setting them up. Use this to be safe.
Another concern with multiple viewports is thread safety. If your engine attempts to “update” each view simultaneously from another thread, make sure you are not calling any SilverLining or Triton methods from your update thread. It is not necessary to call methods such as Atmosphere::UpdateSkyAndClouds() or Ocean::UpdateSimulation(); SilverLining and Triton will call these implicitly at draw time as needed on its own, when it is safe to do so. You also need to ensure you aren’t trying to draw two views at the same time when sharing an Atmosphere or Ocean among several viewports; wrapping your calls to SilverLining and Triton in a mutex object is a good practice to enforce this.
There are some applications that render to different devices from the same application instance; for example, to multiple projectors or totally different display devices hooked up to one PC. In this case, it’s sometimes not possible to share a graphics context between these windows. If this describes your application, you have two options. One is to enable “resource sharing” between these graphics contexts, which will still let you share the same Atmosphere, Ocean, and Environment among them (for example, using wglShareLists()). If that’s not an option, as a last resort you can maintain separate Atmosphere, Ocean, and Environment objects per viewport, which will keep all of SilverLining and Triton’s resources separate, yet duplicated, for each viewport. For OpenSceneGraph users, both SilverLining and Triton include an OSG multi-window example that illustrates one way of creating and associating these objects with their respective cameras in a safe manner.
There are several strategies for integrating SilverLining and Triton with multi-viewport applications, and our customers have done all of the above successfully. I hope this article helps you to choose the best approach.
