[osg-users] Maximizing rendering throughput

[Robert Osfield]

Hi Sebastian,

On 23 October 2015 at 21:03, Sebastian Messerschmidt <
sebastian.messerschmidt at gmx.de> wrote:

> 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)
>

Tools that "generate" data for us to render often provide the data in a
form that is very poorly optimized for real-time work.  Sometimes for an
easy life you just have to pull in the data and put up with it.  Sometime
the peformance requirements are so strict on the rendering side you are
forced to be creative and process the data into a more rendering friendly
form.  The various different types of shaders we can write these days can
help in one be quite creative on just how you do the final rendering.  For
things like per-primitive data one can use things like textures or uniform
arrays to store the data to avoid the need for separate primitives.  This
can't be achieved in all cases.  Custom drawables can be another route for
passing high frequency attribute data.

Whether any of these routes might be practical in your case I can't say as
I don't know enough about the specifics of the nature of the data you are
working with.



>
> 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
>

Vulkan will give us a bit more flexibility to pre-prepare data before
passing on to the drive so should help with dynamic data, however, this
future a little while off yet.

On the OSG/OpenGL side there is still lots of things that can be done.
Even on the text side.  The osgText::Text implementation was written for
OpenGL 1.1 hardware and drivers, and does a few things quite crudely
because of old bottlenecks that we used to have to deal with on the
hardware/driver side, alas this bring it's own bottlenecks.  Personally I'd
like to be able to deprecate the OSG's Text implementation and start
afresh, but backwards compatbility/time available rather restricts this.

This however needn't restrict you, if you have quite limited needs for text
rendering capability you might be able to roll your own light weight text
rendering implementation that copes much better with dynamic data. Either
double buffering at the scene graph level or internally in a custom
drawable might be a route forward.  Text is essentially just a bunch of
textured quads.  As the text you want to render changes you need to provide
a different set of quads positions and texcoords, but this could easily be
managed by double buffering two osg::Vec3Array+Vec2Array respectively
within a custom drawable.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151026/24c04c87/attachment-0003.htm>