2012/4/2 Robert Osfield <[email protected]>: > I'm a bit perplexed by what exactly you are proposing. StateAttribute > are designed to just pass data to OpenGL, they typically aren't active > objects that on the fly decide what state they are in. Also > osg::State object just tracks and applies what state is required, > hardwiring to specific state only happens for very special > StateAttribute like osg::Program and this has to be done to properly > mange osg::Uniform. Also RenderStage is loosely coupled with State > that is applied. This loose coupling is deliberately designed into > the OSG to allow it to be extensible and easily to extend. What you > suggests sounds like it breaks quite a few of these design aspects.
Well, I agree with you on that one. I wasn't particularly happy with my solution either. But I definitely need the functionality it provides and I think it can be argued that such functionality is useful in general. > I'm also not clear on why you really need to go to such lengths. > There may well be far easier ways to handle what you are doing. ... and I would very much prefer a solution which wasn't that intrusive. So - my actual problem: I have (rather deep) multi-parent (for memory reasons - really can't change that) sub-graphs which contains lots of Geodes with GL_CULL_FACE enabled (performance reasons - don't want to change that). When the geodes are culled some of the parental paths yield a MVM with a positive determinant (no mirroring) and some of the parental paths yield a MVM with a negative determinant (mirroring along a single axis), the latter causing the front/back faced to be switched. No matter what FrontFace / CullFace is set in the graph - it's not possible to get both sets of subgraphs to be rendered, unless you somehow allow the attribute's value to depend on the MVM calculated by this specific NodePath. So because it's not possible to do this with attributes alone I added a feature which basically says "I don't want to manage the front face attribute manually, just automatically apply whatever value the current MVM requires". This is why I need something like my proposed AUTO. Why I think FLIP is quite useful: You seldom want a specific front face setting or a specific cull face setting - usually you just want it to be the the inverse of what it currently is (because front face, cull face and a negative determinant in the MVM each cancel each other out). Also one might not use the cull traversals "real" MVM (instead using some uniforms to the same effect), in which case my AUTO would not work. Another area where I am using these settings is the StateSet of Cameras used for planar reflections (which also bring a negative determinant to the MVM). And then there is a point to be made about it being not very nice that the whole scene has to use a consistent back/front setting here when all every node cares about is inverting the setting... Don't get me wrong though - I'm not saying that this must or should be done by adding another FrontFace (or CullFace) mode... this was just the easiest way I saw. Cheers, Felix _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
