Sorry I implied in my previous post that using the DescriptionList of the StateSet was a bad idea; this was an error on my part.
The DescriptionList of either the StateSet, or the Node. or even the Drawable works for me. Just as long as it's used only as a mechanism for transporting this data back to the app, and doesn't interfere with rendering performance if the app simply ignores it.
Note to the OP (Robert): The general philosophy behind the FLT loader is to return an unoptimized scene graph that matches the FLT model as close as possible. Optimizations can be performed by the app after loading the model. With respect to the material codes, this means your modification to the FLT loader should not worry about trying to be "smart" about sharing duplicate material codes; leave that as a post-load step to be optionally performed by the application.
J-S -- Good catch on the Optimizer issue, dropping the DescriptionList of StateSets when they become shared. Seems like a possible bug. Unexpected behavior, at the least. After all, the word "DUPLICATE" is in the name of the flag.
-Paul
-------- Original Message --------
Subject: Re: [osg-users] [osgPlugins] How to read/write/access
OpenFlight Surface Material Code (SMC) and Feature ID (FID) ?
From: Jean-Sébastien Guay <[email protected]>;
Date: Thu, April 14, 2011 9:19 am
To: OpenSceneGraph Users <[email protected]>
Hi Paul,
> One of the default osgUtil::Optimizer flags is
> SHARE_DUPLICATE_STATE. So if two StateSets are otherwise identical
> and would be shared under this optimization, adding a different
> material code to the description list of the two StateSets would
> impair that optimization.
>From what I can see, the StateSet comparison only compares Uniforms and
StateAttributes (both normal and texture attributes). See
Optimizer::StateVisitor::optimize() in osgUtil/Optimizer.cpp.
So adding different descriptions to two StateSets that are otherwise
identical will actually result in only one of the sets of descriptions
"winning" once the stateset is shared. So if, as I said, the SMC is
associated to a texture or a material (in the sense of an
osg::Material), then that's fine, there will never be a different SMC
when the textures/materials are identical.
Anyways, if adding it to the nodes is fine, go with that, I was just
saying that it sounded natural to me (anything textured as concrete
should have the SMC of concrete, and setting the SMC in the descriptions
of the stateset gives you this sharing for free) but I don't know how it
actually works in the OpenFlight format, so if what I say is nonsense,
then just disregard it. Then again no one has yet said that this
association is not actually the case, if that had been said I would just
have dropped the subject altogether :-)
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
_______________________________________________
osg-users mailing list
[email protected]
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
