Hi everyone,
I have a question concerning the possible limitations that might exist in
the following scenario:
- Let's say I have a special node object in my scene graph:
class SpecialNode : public osg::Node {
protected:
osg::ref_ptr<osg::PositionAttitudeTransform> _subgraph;
public:
void traverse(osg::NodeVisitor& nv);
}
- note that this SpecialNode is not even an osg::Group.
- on creation, I build a simple sphere geode with a
PositionAttitudeTransform, and store this directly in my SpecialNode with a
referenced pointer member, _subgraph
- I also specify a initialBounding sphere to avoid the complete special
node being removed because it has no size.
- I override the traverse(osg::NodeVisitor&) function in that SpecialNode
so that, in case I have a cull traversal, I also do:
_subgraph->accept(nv);
As a result, my subgraph is correctly displayed on screen when rendering
this scene.
Now more interesting, I can also do in this traverse() operation:
_subgraph->accept(nv)
_subgraph->setPosition(pos2)
_subgraph->accept(nv)
_subgraph->setPosition(pos3)
_subgraph->accept(nv)
...
And this will render multiple copies of my subgraph with the proper
position offsets.
=> The question I have is : to which extend could such a mechanism be used:
- would this still work as expected, if instead of changing the Position, I
were to change:
1. A StateAttribute in a sub stateset ?
2. An uniform value ?
- Are there some obvious issues I should be aware of when using this
approach ?
The whole idea behind the scene is: I when to render a planet, and in this
traverse operation I am to generate multiple subtiles and cull them
(hundreds of them) so I would like to optimise the cull stage, and it
doesn't really make sense to store all the tiles as regular children since
they are always changing. And at the end I would consider directly pushing
the modelView matrix (to move to the proper tile location) on the cull
visitor, them traversing a shared tile template, then pushing the next
modelview matrix, etc... Any advise on this ? ;-)
Cheers,
Manu.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
