Hello Michael,
On 01/26/2012 08:14 AM, Michael Raab wrote:
> I have some news on that. It seems that in general the material handling
> works well as expected. The problem I described constists actually of two
> problems:
> 1.) The wrong color when I switch to non-lit material on materialGroup3:
> I think that was caused by an error in OpenSG. When changing the active
> materialchunk during rendering, there is a glColor4fv call missing. So OpenGL
> takes the color of the last material when rendering a non-lit geometry...
> Please have a look at OSGMaterialChunk.cpp
> function: void MaterialChunk::changeFrom(DrawActionBase *, StateChunk *
> old_chunk, UInt32)
> There you will find the following statement:
>
> if(getColorMaterial() != GL_NONE || getBackColorMaterial() != GL_NONE)
> glColor4fv(_sfDiffuse.getValue().getValuesRGBA());
>
> Function MaterialChunk::activate() doesn't have that if condition but the
> glColor4fv call so I decided to comment that if condition out. Would you
> please verify if that is resonable in all cases? For our case that fixes the
> problem...
thanks for the analysis. There is definitely something wrong with these
lines (at the very least activate() and changeFrom() should behave the
same way ;) ).
I'd say if ColorMaterial != GL_NONE the expectation is that the geometry
has vertex colors to be used in lighting calculations (the whole point
of glColorMaterial()), so the tests actually look backwards to me.
Dirk: do you remember what the desired behavior here should be? To me it
seems sensible to use the diffuse color as current color (on geometry
with vertex colors those take precedence anyway) if ColorMaterial is
GL_NONE.
> 2.) White (over lit??) geomety: That seems not to be caused by material
> settings (as far as I can see with my debug prints). All materials seem to be
> correctly set, the OpenGL command output got from gDEBugger proves that. So
> that seems to be caused by the geometry itself. In our case the rendered
> geometry has a transformation above. I tried to merge that transformtion into
> the geometry itself and the problem seems to be solved. I'll send you a
> before/after example (including screenshots and OpenGL trace) off the list...
> But I have no idea how the transformation may damage the rendering that
> much...
Hmm, the only transforms that cause funny effects i can think of are
ones that contain negative scale (possibly only on one axis, to go from
left to right-handed coordinate systems). Is that (or something equally
"unusual") the case here?
The OpenGL traces you sent are very similar, the only difference is that
in the broken case three display lists (ids 3,4,44) are called while in
the working case just one (id 45).
Cheers,
Carsten
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
