[osg-users] Maximizing rendering throughput

[Glenn Waldron]

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.

Everything else (scene graph structure, etc.) is safe to change during the
Update traversal/callbacks.

Hope this helps.

Glenn Waldron

On Fri, Oct 23, 2015 at 1:07 PM, Sebastian Messerschmidt <
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> 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 listosg-users at lists.openscenegraph.orghttp://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/f0088755/attachment-0003.htm>