[osg-users] uniform buffers for transform stack and other constants

Gedalia Pasternak gpasternak at mak.com
Mon Mar 13 08:15:07 PDT 2017


Hello,
   I've seen that OSG has some basic primitives for uniform buffers, but
they seem designed for homogeneous data. Most modern engines use uniform
buffers to represent various levels of shader constants based on frequency
of state changing, so you might have a per frame UBO/per pass UBO, a
material UBO, and a per draw call UBO. (one-off object changes might be the
done with the simpler uniform system.)

Typically that data is not homogeneous, but represented by a C structure
that has to be somewhat carefully laid out.
For example I've switched to a UBO for OSG's transform stack:
struct osg_TransformStack
{
   osg::Matrixf ModelViewMatrixInverse;
   osg::Matrixf ModelViewMatrix;
   osg::Matrixf ModelViewProjectionMatrix;
   osg::Matrixf ProjectionMatrix;
   osg::Matrix3 NormalMatrix;
};

That can get mapped to a UBO via
   _extensions->glBufferData(GL_UNIFORM_BUFFER, sizeof(osg_TransformStack),
&osg_transformstack, GL_DYNAMIC_DRAW);

And the UBO in glsl would look like:

struct osg_TransformStack
{
    mat4 ModelViewMatrixInverse;
    mat4 ModelViewMatrix;
    mat4 ModelViewProjectionMatrix;
    mat4 ProjectionMatrix;
    mat3 NormalMatrix; // Mat3's don't actually map great to std140 layouts
};

layout(std140) uniform osg_transform_stack_block
{
   osg_TransformStack osg;
};

Replacing the individual uniforms that OSG adds to replace the legacy
gl_*Matrix calls in State::convertVertexShaderSourceToOsgBuiltIns() with a
UBO saves me a few ms a frame, but I'm doing all the uniform buffer
management by hand and I've had to significantly modify the state class. (I
think some of the performance gain is from avoiding OSG's uniform
management abstractions as well.)  I've had to do something similar with
materials, otherwise I have significant performance degradation when
switching off the fixed function pipeline.
  Has anyone else experimented with UBO's in this manor? Is there a cleaner
OSG way to do that's still high performance?

Gedalia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170313/64816f77/attachment-0001.htm>


More information about the osg-users mailing list