CompositeViewer support: Difference between revisions

Jump to navigation Jump to search
m
m (→‎Swap Buffers: https://groups.google.com/g/osg-users/c/cIMLA2zkdyE/m/cUx9JZA2J4MJ)
Line 484: Line 484:
additional mechanism for holding back the next frame.  There are
additional mechanism for holding back the next frame.  There are
mechanisms for doing a swap ready check for multi-context systems <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg72040.html</ref>
mechanisms for doing a swap ready check for multi-context systems <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg72040.html</ref>
As for general notes about threading, if you are working on the same
graphics context as you are then all the draw dispatch and the draw
GPU can only be done by a single graphics thread so there is little
opportunity to make it more parallel without using another graphics
card/graphics context and interleaving of frames.
Cull and draw can only run in a parallel once all the dynamic geometry
has been dispatched, otherwise the draw will be dispatching data that
is being modified by the next frames update and cull traversals.
Perhaps you have some dynamic geometry or StateSet's that are holding
back the next frame.<ref>https://groups.google.com/g/osg-users/c/JY1mVGofOEg/m/8P7j5titqVcJ</ref>
There are limits with the time of threading you can do with cameras
that share the same graphics context - the draw traversals has to be
single threaded for each camera's rendering, this applies to FBO's as
well as normal rendering to a graphics window.
You should be able to still run multi-threaded if you have multiple
graphics contexts, but the osgdistortion example just uses on graphics
context, and multiple FBOs. <ref>https://groups.google.com/g/osg-users/c/RYEOlTMItbI/m/SQSrf0f5jXoJ</ref>
You can have a slave Camera in the Viewer that is used a prerendering
camera or a Camera in the scene graph that is used a prerender camera.
Cameras in the scene graph are treated almost exactly the same way as
slave Camera, it's just high level things like threading and how the
view and projection matrices are assigned per frame that differ. <ref>https://groups.google.com/g/osg-users/c/RNgKAZTCyN0/m/kGPsRpxLlWQJ</ref>
If you want to create and chain RenderStages then using an osg::Camera
in the scene graph is often one of the best ways to do this, and use
the Camera::setRenderOrder(..) to control the order. You can also use
a custom cull traversal callback to create RenderStage/RenderBin and
assign these to the rendering backend, but this does require a greater
knowledge of the internals of the rendering backend.<ref>https://groups.google.com/g/osg-users/c/45_bw3QUELs/m/aXvWKsuKKgUJ</ref>


=== Scene Modification ===
=== Scene Modification ===

Navigation menu