Hi Roger, I'm open to fixes, but it'd be good to put them in a generally accessible place in appropriate.
I do wonder if we could add a traversal into osgUtil::Optimizer that detects transforms that scale their subgraphs and then add the GL_NORMALIZE for these. This visitor could then be run after the flatten static transforms traversal and be applied only when necessary. Fancy writing such a Visitor :-) Robert. On 7/2/07, Roger James <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Robert Osfield > Sent: 02 July 2007 14:32 > To: osg users > Subject: Re: [osg-users] osgconv scaling affects colours > > On 7/2/07, Roger James <[EMAIL PROTECTED]> wrote: > > Robert, > > > > Thanks for the quick response. Doh, that was my first thought! But I got > sidetracked when I saw that camera node in the scene and wondered what > would happen if I took it out! > > > > I think I will hack a renormalize option into osgconv and see what > happens. > > > > However, I still do not understand why removing the cone drawable, which > as far as I can see is switched off by the switch node, should make things > appear to work. > > > Its probably the Optimizer's FlattenStaticTransform working in certain > scene graph set ups and not in others, it can't flatten all scene > graphs. When it doesn't flatten the lighting issue is probably > apparent, so rather than a optimizer bug its the exact opposite - the > optimize if fixing the problem! > You are as usual correct ;-) , if I had looked more closely at my test files I would have noticed it. Would you accept a submission for osgconv that added a GL_NORMALIZE to the transform before fstv.removeTransforms is called. I am assuming that adding this will not affect the fstv. If the fstv worked then the transform and its associated state would have been removed. e.g. transform->setMatrix( C * R * S * T ); if (!S.isIdentity()) { // Add a normalize state transform->getOrCreateStateSet()->setMode(GL_NORMALIZE, osg::StateAttribute::ON); } root->addChild(transform); transform->addChild(node); osgUtil::Optimizer::FlattenStaticTransformsVisitor fstv; root->accept(fstv); fstv.removeTransforms(root); I could add a parameter to control this behaviour if that would help. Alas the model I pulled this little test from has highlighted some other lighting normal issues with daeReader. I will look into these when time permits. Roger _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
