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
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
