Hi Robert,
Hi Sebastian,
On 23 October 2015 at 18:07, Sebastian Messerschmidt
<sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>> wrote:
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.
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.
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?
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.
Within these double buffered StateSet and Drawable you can share all
the arrays/stateattributes that are constant and just have the
changing parts duplicated.
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.
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)
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).
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.
Right now I add them as post-render camera/child of the main camera, so
maybe the problem is my camera arrangement.
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.
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.
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.
I guess the optimizations I'm looking for are simply restrained by the
way OpenGL works and might be relaxed with Vulkan etc
Cheers
Sebastian
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
