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.milhar...@ib-caddy.si <mailto:robert.milhar...@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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
