<div dir="ltr">Sebastian, here is my understanding.<div><br></div><div>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.</div><div><br></div><div>Everything else (scene graph structure, etc.) is safe to change during the Update traversal/callbacks.</div><div><br></div><div>Hope this helps.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Glenn Waldron</div></div></div></div>
<br><div class="gmail_quote">On Fri, Oct 23, 2015 at 1:07 PM, Sebastian Messerschmidt <span dir="ltr"><<a href="mailto:sebastian.messerschmidt@gmx.de" target="_blank">sebastian.messerschmidt@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi Robert, <br>
<br>
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. <br>
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. <br>
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. <br>
<br>
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?<br>
<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
Sebastian <br>
</font></span><blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hi Robert,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 23 October 2015 at 12:36, Robert
Milharcic <span dir="ltr"><<a href="mailto:robert.milharcic@ib-caddy.si" target="_blank">robert.milharcic@ib-caddy.si</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
</blockquote>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<div>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. <br>
<br>
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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Robert.<br>
</div>
<div><br>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
osg-users mailing list
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a>
</pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>