Hi Manu, In an ideal world, w.r.t treating everything uniformly, all OpenGL/OSG attributes and modes would have a 1:1 mapping, but alas OpenGL and OSG as consequence don't follow this rule, some attributes have multiple modes associated with them, some have none at all.
Robert. On Thu, Jan 31, 2008 at 5:10 PM, Emmanuel Roche <[EMAIL PROTECTED]> wrote: > Yes sure, I could disable lighting in that simple case (Yet I'm not even > sure of it, I have no real example in mind but suppose I have an other > sibling attribute also depending on GL_LIGHTING... ). But as a matter of > fact, I'm trying to write an OSG editor based on osgIntrospection, and my > real point is that such minor problems unfortunately break the whole > philosophy of the introspection framework (ie you cannot handle every > StateAttribute in an uniform way...). > > Thanks for your replies! > > > > Manu. > > 2008/1/31, Paul Martz <[EMAIL PROTECTED]>: > > > > > > 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 > > 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::StateAttribute::...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 > > > [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 > > > > > > > _______________________________________________ > 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
