[osg-users] FW: issue about getting the material properties from the current state in rendering info

[Gianluca Natale]

Thanks Sebastian,
I'm simply trying to get the alpha value of the diffuse component of the material properties, because I have to pass it to an underlying
graphic library that I use for rendering that custom drawable.

BTW, I further investigated.
In the following function:

State::captureCurrentState(StateSet& stateset)

The _attributeMap actually contains as MATERIAL attribute exactly the pointer to the osg::Material property that I created.
But in the attribute stack it appears as the 'last_applied_attribute', and 'changed' is set to true.
For all other attributes the pointers stored in 'last_applied_attribute' are correct as well, but 'changed' is set to false.
Also, in that AttributeStack the member attributeVec contains just one element, that is not the correct one (it points to a different osg::Material).
While for all the other attributes, which have 'changed' set to false, last_applied_attribute coincides with the first element in attributeVec.

I don't know anything of that code, but I don't understand why osg::Material appears to be changed, while other attributes not.
Or should I use a different API to get the current osg::Material? I found this in State header file:

        /** Get the current specified attribute, return NULL if one has not yet been applied.*/
        const StateAttribute* getLastAppliedAttribute(StateAttribute::Type type, unsigned int member=0) const;

So, it looks like the current value of an attribute is actually the last applied!?! That is how the API is described.
So, what captureCurrentState should do instead?

Thanks,
Gianluca Natale


From: osg-users [mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Sebastian Messerschmidt
Sent: martedì 23 giugno 2015 18:15
To: OpenSceneGraph Users; Osg Users
Subject: Re: [osg-users] issue about getting the material properties from the current state in rendering info


Am 23.06.2015 18:05, schrieb Gianluca Natale:
Hi all,
I'm using OSG 3.0.1.
I have an issue when I try to retrieve the material properties from the rendering info, in my custom drawable.

To be clearer:
I have a custom drawable, for which I implemented a

myDrawable::drawImplementation(osg::RenderInfo& osgRenderInfo).

When I try to get the material properties inside that function, by following code:

osg::StateSet  drwbStateSet;
osg::State *state = osgRenderInfo.getState();
state->captureCurrentState(drwbStateSet);

the returned material properties is invalid.
Specifically, I put a breakpoint in following function:

StateSet::setAttribute(StateAttribute *attribute, StateAttribute::OverrideValue value)

that is called inside captureCurrentState.
When the attribute is an osg::Material, the _ptr is different from the one allocated when the material has been set, in the state set associated to a parent node of that drawable.
Furthermore, _userDataContainer is 0x0000000000000000, so no valid osg::Material is returned in the captured state set.
User data defaults to nullptr. So if you're not setting it up that is expected.
As you don't explain why you are trying to inspect state during draw it is hard to guess what you are after.
I simply guess that your state is set up somewhere further up in the stategraph (i.e. in one of the parents) and that state is set up lazy.
Maybe Robert can give some insights here.



Any idea of the possible cause of the issue? Where did I go wrong?
BTW, all other attributes (polygon offset, polygon mode, etc...) are returned correctly.
Are you sure you are setting up an osg::Material state attribute somewhere?

Thanks,
Gianluca Natale





_______________________________________________

osg-users mailing list

osg-users at lists.openscenegraph.org<mailto:osg-users at lists.openscenegraph.org>

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150623/0b76fd5b/attachment-0003.htm>