Hi J-S, I was suspecting the pointer issue with statesets, thanks for your clarifications!
But I didn't realize I could just as simply push/pop another stateset, will certainly use that tip ! ;-) Cheers, Manu. 2011/11/17 Jean-Sébastien Guay <[email protected]> > Hi Emmanuel, > > => 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 ? >> > > No, not as simply as changing the position. The reason is that the cull > visitor accumulates matrices by value, so each time you change the position > and re-traverse you're adding a new matrix on the stack before each > traversal. But Uniforms and state in general are accumulated by pointer > (the last pointer that was in a StateSet when a drawable gets drawn is the > one that is applied) so changing a uniform or other state attribute for the > second traversal will change it for all "instances" of your object. > > However you can do it another way: create different statesets with the > different attributes you want, and before calling accept() each time, do > cv->pushStateSet(ss1.get()); and after do cv->popStateSet(); . > > > - Are there some obvious issues I should be aware of when using this >> approach ? >> > > Not really, this is what the cull visitor does itself when it traverses a > node (group, etc)... > > > 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 ? ;-) >> > > This is what you're doing (indirectly) with your setPosition() between > each accept(). So it's fine. > > Hope this helps, > > J-S > -- > ______________________________**________________________ > Jean-Sébastien Guay > jean-sebastien.guay@cm-labs.**com<[email protected]> > http://www.cm-labs.com/ > > http://whitestar02.dyndns-web.**com/<http://whitestar02.dyndns-web.com/> > ______________________________**_________________ > osg-users mailing list > osg-users@lists.**openscenegraph.org <[email protected]> > http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** > openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
