[osg-users] Maximizing rendering throughput

[Sebastian Messerschmidt]

Hi Glenn,
> Sebastian, here is my understanding.
>
> StateSets and Drawables must be marked as DYNAMIC is you plan to 
> change them. That's because they are used by the rendering stage, 
> which can overlap the next frame's update.
Okay, thank you for your insights.
>
> Everything else (scene graph structure, etc.) is safe to change during 
> the Update traversal/callbacks.
>
> Hope this helps.
Okay, there is some idea growing, how to get the maximum out of my use case.
>
> Glenn Waldron
>
> On Fri, Oct 23, 2015 at 1:07 PM, Sebastian Messerschmidt 
> <sebastian.messerschmidt at gmx.de 
> <mailto:sebastian.messerschmidt at gmx.de>> wrote:
>
>     Hi Robert,
>
>     Thanks for the explanation. I'm still puzzled by the question
>     which elements can be updated in the update-phase without setting
>     them to dynamic. I always was under the impression, that the
>     update is performed before cull/draw are actually executed.
>     Right now I need some thread safe "time slot" to change the scene
>     graph in terms of inserting nodes, updating transforms etc. I
>     guess it is totally okay to do this in the update callback/operation.
>     But for changes to images, text, an arrays of drawables I need to
>     set them to DYNAMIC if I understood you correctly. So basically
>     what I got is, that I could put the draw of those elements as far
>     to beginning of the draw as possible.
>
>     As for the double buffering: Can it be done at drawable level?
>     Like swapping the front/back drawable back and forth, effectively
>     doubling the geometry/image space needed?
>
>     Cheers
>     Sebastian
>>     Hi Robert,
>>
>>     On 23 October 2015 at 12:36, Robert Milharcic
>>     <robert.milharcic at ib-caddy.si
>>     <mailto:robert.milharcic at ib-caddy.si>> wrote:
>>
>>         First of all, I didn't know that cull and draw traversal can
>>         execute in parallel on a single scene. I always thought that
>>         cull and draw can only execute sequential (serial) in all
>>         available threading models. Anyway,  what I know for sure is
>>         that update and draw traversal can indeed execute in parallel
>>         within some threading models, and that is the reason why we
>>         need DYNAMIC variance, to tell drawing thread it must process
>>         dynamic elements first, and then immediately allow execution
>>         of the update traversal in a main thread while STATIC
>>         elements are still being rendered in a draw thread. I also
>>         suspect that next frame cannot start before all the
>>         static+dynamic elements are rendered. If I'm correct on this
>>         one, then few DYNAMIC elements should not affect frame rate
>>         at all, because there is plenty of time to do the processing
>>         while STATIC elements are still being rendered.
>>
>>
>>     With the DrawThreadPerContext and
>>     DrawThreadPerContextCullThreadPerCamera threading models the
>>     static part of the rendering can be done in parallel with the
>>     next frame.  You guess this correct.
>>
>>     The one thing I'd add is that the OSG itself doesn't attempt to
>>     sort DYNAMIC objects so that are drawn first.  You can set up
>>     your StateSet::RenderBinDetails to force the dynamic objects to
>>     be drawn first, but you can only do this for objects that don't
>>     affect the rendering of other objects, or are affected by what is
>>     the fame buffer already.
>>
>>     In the case of text it has to be placed in the depth sorted bin
>>     which is drawn after the main opaque bin, so if there are text
>>     objects set to DYNAMIC then you stop the next frame from start
>>     till the end of dispatch of the last depth sorted dynamic
>>     object.  This may well be very near the end of the draw dispatch
>>     so you come pretty close to nullifying all the capacity for
>>     running the draw thread in parallel with the next frames' update
>>     and cull traversals. This is likely the situation for Sebastian.
>>
>>     Using double buffering of Text object's is probably the best way
>>     to avoid updating a Text object while it's being drawn, allowing
>>     the Text DataVariance to remain STATIC. Such double buffering
>>     could be done a custom Node that has two Text objects, one for
>>     current frame being updated, and one for the previous frame still
>>     being rendered.
>>
>>     Robert.
>>
>>
>>
>>
>>     _______________________________________________
>>     osg-users mailing list
>>     osg-users at lists.openscenegraph.org  <mailto:osg-users at lists.openscenegraph.org>
>>     http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>     _______________________________________________
>     osg-users mailing list
>     osg-users at lists.openscenegraph.org
>     <mailto:osg-users at lists.openscenegraph.org>
>     http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151023/cf109437/attachment-0003.htm>