Hi Daniel,
On 6/22/06, Daniel Trstenjak <[EMAIL PROTECTED]> wrote:
On Thu, Jun 22, 2006 at 11:40:17AM +0100, Robert Osfield wrote:
> I think the "correct" solution is to refactor osg::Material so that
> the colour material is implementated seperately in its own
> osg::ColorMaterial class.
The osg::ColorMaterial should only hold the information
for which material component (ambient, diffuse, specular, emission)
the color should be used.
The color comes from the color array of the geometry.
Yes this is what I'm thinking of.
The problem we have is that we want to use a osg::Material
for the specular, ambient and emission components of the material
and a color array in the geometry for the diffuse component of the material.
OpenGL allows this.
This should be possible, just set the
material->setColorMode(DIFFUSE);
In this case we have a osg:Material with _colorMode=OFF.
But we can't enable the GL_COLOR_MATERIAL in the StateSet separate
because the osg::ModeStack for GL_COLOR_MATERIAL was invalidated
by the calls to glEnable/glDisable by osg::Material::apply(State&).
You don't want to enable/disable GL_COLOR_MATERIAL seperate. Just use
stateset->setAttribute(material)
Rather than
stateset->setAttributeAndModes(material,..)
> However, there is this issue of backwards compatibility to be warry of.
In which case would my modifications cause a incompatibility ?
If anything needs to change in the current Material its probably to
remove the GL_COLOR_MATERIAL mention completely to avoid it being
inappropriately applied.
I think your mods wouldn't be appropriate as they introduce
inconsistencies, either GL_COLOR_MATERIAL is managed internally
osg::Material and nobody else modifies this mode, or
osg::ColorMaterial is entirely seperate.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
