Hi Robert,
thanks for the quick reply.
I think one can solve the inheritance stuff regardless of the sorting of
the state graph. In the current implementation you already provide both
directions (inheritance and overriding of states) and in a bottom up
implementation of the stategraph one could do the same?! (Don't know,
but I think so).
But inheritance brings me to another example. By adding Transform Nodes
one adds transformations to the initial transformation of the model. You
'inherit' the transformation of the base model and add your own stuff by
adding an transformnode on top of it.
Exactly the same thing I like to do with shaders. The shader should be
attached to the geometry. By adding instance parameters on top of it I
like to change the behaviour of the shader. This is possible in the
current implementation, however one will loose the stategraph sorting,
possibly causing the shader to be rebind all the time.
To benefit from startgraphsorting one has to 'mix' the instance
parameters below the shader statesets in the graph, which is really
difficult, if you think about an abstract layer, like the plugin system.
(Is it?)
Richard
________________________________
Hi Richard,
I'm afriad I'm not going to dive into a complex topic as I'm away on a
trip, I'll try to give a quick reply to one quetion.
> So the primary question is: Why is the stategraph build from the root
to
> the leafs of the scenegraph and not the other way around?
All OpenGL state in the OSG is inherited top down, and does so in the
same way that scene graph is structured from the root at the top to the
leaf at the bottom. The osgUtil::StateGraph is built as mini graph that
mimics the scene graph structure and the inheritance that it implies,
but contains only the elements that are visible. The state graph has to
built this way to achieve the standard model of inheritance that the OSG
adheres too, to do it any other way would break this inheritance
convention and break most features along with it.
Robert.
On Wed, Apr 9, 2008 at 7:19 AM, Schmidt, Richard, SDGE1
<[EMAIL PROTECTED]> wrote:
Hi,
I got some questions about the stategraph build by osg while
culltraversal.
So the primary question is: Why is the stategraph build from the root to
the leafs of the scenegraph and not the other way around?
To explain it a bit, lets make an example:
You want to display a model (a car for example), which is available as
.ive file. The model itself has a complex stateset with many
texturebinds. For each instance of the model in your scene you add a
transform node and a stateset which sets the material color. By doing so
you will loose the ability of osg to build a proper stategraph, the
stategraph becomes 'fragmented' because of setting the material color in
the parent stateset of the models graph.
The general problem is: In the scenegraph, the parameters of the
instances are in the inner nodes (the transform nodes). In the
stategraph, the parameters of the instances are at the leaf nodes.
Just consider another example: Lets assume you want upload
positions/rotations through uniforms to a shader. The statesets of the
uniforms have to be placed under the shader stateset to get the
stategraph sorting work properly.
I am currently working on integrating speedtree into osg. I converted
the shaders to glsl and the parameters to uniforms. The geometry is
setup like the examples of speedtree. It's all working pretty well, but
I am stuck with the problem above.
I'd like to organize the scenegraph as shown at the attached image
(please ignore the PositionAttitudeTransform, the position and rotations
are part of the stateset InstancesParms).
Basics of speedtree:
*four different shaders( in the example above are just three of them)
*3 levels of statesets:
*first level: the shaders
*second level: the 'template' parameters of the model (like
texture and material properties
*third level: the instance parameters (like scale, position,
windoffset, rotation)
Now consider adding level of detail to the graph and try to organize the
graph like osg needs it: The shaders at the root, than the 'template'
stateset and than the instances. The result is that one has to clone the
whole LOD hierarchy for each shader which is not a desired solution.
I would prefer, if the stategraph is build from bottom up, instead of
top down.
Greetings,
Richard
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
