Not all attributes have modes, as you've discovered with Material. The current OSG paradigm of being able to setAttributeAndModes for Material really doesn't make much sense. I'd be reluctant to rewrite any portions of OSG dealing with the fixed function pipe, though, in light of OpenGL 3. To disable use of Material, disable lighting: setMode( GL_LIGHTING, OFF ). It helps to know OpenGL when using OSG so that you can handle such situations. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com <http://www.skew-matrix.com/> 303 859 9466
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Roche Sent: Thursday, January 31, 2008 8:01 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osg::StateAttribute::ON / OFF forosg::StateAttributeor not ? I mean that when settings ON on the Fog, then the fog is enabled but when querying the corresponding RefAttributePair there is no "ON". Rather, the "ON" ends in the associated mode (GL_FOG only I guess) bit field. this transfer of the "ON" from the attribute to the corresponding Mode surprise me a bit since as a result, it is not simple to query the "ON" state of a given attribute : for(osg::StateSet::AttributeList::iterator it = stateSet->getAttributeList().begin(); it != stateSet->getAttributeList().end(); ++it) { if((*it).second.first.get() == attribute.get()) { osg::StateAttribute::OverrideValue val = (*it).second.second; if(val & osg::StateAttribute::ON) onOffCheckB->SetValue(true); if(val & osg::StateAttribute::OVERRIDE) overrideCheckB->SetValue(true); if(val & osg::StateAttribute::PROTECTED) protectedCheckB->SetValue(true); if(val & osg::StateAttribute::INHERIT) inheritCheckB->SetValue(true); break; } } ---> In this code sample, the onOffCheckB will never have its value set to true... even when the attribute IS activated... of course we may query the ModeList instead, but this doesn't hide the OpenGL layer (ie you have to know which modes are used by such and such Atribute...) Manu. 2008/1/31, Paul Martz <[EMAIL PROTECTED]>: It's not clear to me what you're saying. Are you saying that even when you specify ON, fog is not enabled? Or are you saying that when you query the StateSet's GL_FOG mode later, you're not getting what was set? Or are you saying that when you dump the scene graph out to an .osg file, GL_FOG ON doesn't appear in the output? Please clarify. -Paul _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Roche Sent: Thursday, January 31, 2008 2:55 AM To: OSG Users Subject: [osg-users] osg::StateAttribute::ON / OFF for osg::StateAttributeor not ? Hi again ! I'm working on some kind of editor in fact, and I've noticed that when you have a StateSet, and a given StateAttribute, if you call stateSet->setAttributeAndModes(attribute,osg::StateAttribute:ON|osg::StateAt tribute::...etc,etc.. ) then, (at least for a osg::Fog attribute for example) in the RefAttributePair created, the osg::StateAttribute::ON (or OFF) is not added... My theory is that this ON/OFF setting each time goes in a given assosiated mode (as there is on trace of them in RefAttributePair constructors in StateSet.cpp) : Am I right, or making a big mistake ?? By the way, on a completely different topic, I can now confirm that the boost serialization for OSG files works pretty well :-) I followed your advise Robert and used osgIntrospection to generate the sources... and this generator is a single main.cpp file :-). As a result I have a single library capable of writing text,xml or binary OSG files indifferently (yes, we can even same image data in text and xml files !) Yet the XML format is not easily readable :-( here is a simple stateset section for example : <StateSet class_id="21" tracking_level="1" version="0" object_id="_5"> <Object> <Referenced object_id="_6"> <ThreadSafeRefUnref>1</ThreadSafeRefUnref> </Referenced> <DataVariance>1</DataVariance> <Name></Name> <UserData class_id="-1"></UserData> </Object> <AttributeList class_id="22" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item class_id="23" tracking_level="0" version="0"> <first class_id="24" tracking_level="0" version="0"> <first>8</first> <second>0</second> </first> <second class_id="25" tracking_level="0" version="0"> <first class_id="26" tracking_level="0" version="0"> <StateAttribute class_id="27" class_name="osg_Fog" tracking_level="1" version="0" object_id="_7"> <StateAttribute class_id="28" tracking_level="0" version="0"> <Object> <Referenced object_id="_8"> <ThreadSafeRefUnref>1</ThreadSafeRefUnref> </Referenced> <DataVariance>2</DataVariance> <Name></Name> <UserData class_id="-1"></UserData> </Object> <EventCallback class_id="-1"></EventCallback> <UpdateCallback class_id="-1"></UpdateCallback> </StateAttribute> <Color class_id="30" tracking_level="0" version="0"> <x>0</x> <y>0</y> <z>0</z> <w>0</w> </Color> <Density>0.80000001</Density> <End>11.8</End> <FogCoordinateSource>33874</FogCoordinateSource> <Mode>2048</Mode> <Start>-10.1</Start> </StateAttribute> </first> <second>2</second> </second> </item> </AttributeList> <BinName></BinName> <BinNumber>0</BinNumber> <EventCallback class_id="-1"></EventCallback> <ModeList class_id="32" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item class_id="33" tracking_level="0" version="0"> <first>2912</first> <second>3</second> </item> </ModeList> <RenderBinMode>0</RenderBinMode> <RenderingHint>0</RenderingHint> <TextureAttributeList class_id="34" tracking_level="0" version="0"> <count>0</count> <item_version>0</item_version> </TextureAttributeList> <TextureModeList class_id="35" tracking_level="0" version="0"> <count>0</count> <item_version>0</item_version> </TextureModeList> <UniformList class_id="36" tracking_level="0" version="0"> <count>0</count> <item_version>0</item_version> </UniformList> <UpdateCallback class_id="-1"></UpdateCallback> </StateSet> -Main issues left: --> it's useless to save the <ThreadSafeRefUnref>1</ThreadSafeRefUnref> (easily solvable) --> Enumerations don't use labels :-( --> automatically generated STL containers use standard xml tags (item, first, second, count, etc...) :-( Cheers, Manu. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
