<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Robert,<br>
<blockquote
cite="mid:CAFN7Y+VXnLJuHYWtwexbBK6J+2eWnbwBt4pB0_fHiALne2Gvhw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Sebastian,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 23 October 2015 at 18:07,
Sebastian Messerschmidt <span dir="ltr"><<a
moz-do-not-send="true"
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"> 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>
</div>
</blockquote>
<div><br>
</div>
<div>Have a look through the archives, I've written a lot
about the DrawThreadPerContext model that I introduced
back in the OSG-2.0 days.<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> 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>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, you'd do the double buffering at the StateSet and
Drawable level. Essentially you'd have Node's in the
scene graph manage two alternatives and have each update,
cull traversal for a frame work on one version, and draw
to work on the other. You could double buffer whole
subgraphs if you wanted. <br>
<br>
Within these double buffered StateSet and Drawable you can
share all the arrays/stateattributes that are constant and
just have the changing parts duplicated.<br>
</div>
<div> <br>
</div>
<div>This is advanced OSG usage though, it may well be that
this added complexity isn't required at all. You haven't
really told us anything about your application usage and
confirmed bottlenecks to know what is the best route for
your application to get better performance.<br>
</div>
</div>
</div>
</div>
</blockquote>
Thanks for your insights. I know the biggest concern is the
structure of the scene-graph but at some point one will get stuck or
will simply have to live with the sheer number of drawables spit out
by external tools (I also cannot merge certain geometries due to
additional attributes that need to be per-primitive)<br>
In my scenario I have a extremely high number of nodes in the scene,
which need to stay where they are in terms of structure. Let's
assume that I have purely static scene. It will perform with a
decent framerate (100Hz for instance).<br>
As soon as I add some HUD-Camera containing osgText::Text nodes it
will almost drop to 50Hz, as the cull and draw are no longer able to
execute in parallel, by simply adding one HUD-text node. <br>
Right now I add them as post-render camera/child of the main camera,
so maybe the problem is my camera arrangement. <br>
Apart from this, there might be the use case, where the scene is
mainly static with some elements drawn on top, which are dynamic,
which cause the same frame-rate degradation.<br>
In my case, the scene loaded with the osgviewer has double the
frame-rate from my viewer, which adds some dynamic text on top,
which is not really satisfying. If you want some example
illustrating this, I can totally provide some as a "DON'T DO THIS"
example.<br>
<br>
I'm simply was wondering, why the update overlaps the draw/cull. I
was under the impression, that cull/draw can be parallelized, as
long as the data rendered is updated in the update phase. But of
course, there are changes which need to sent down the pipe. <br>
I guess the optimizations I'm looking for are simply restrained by
the way OpenGL works and might be relaxed with Vulkan etc<br>
<br>
Cheers<br>
Sebastian <br>
<blockquote
cite="mid:CAFN7Y+VXnLJuHYWtwexbBK6J+2eWnbwBt4pB0_fHiALne2Gvhw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Robert.<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
osg-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a>
</pre>
</blockquote>
<br>
</body>
</html>