Hello Pablo,

Pablo Carneiro Elias wrote:
> I've recently ported from OSG1.8 to 2.0 and I got little problem using 
> two textures simultaneously. The problem is possibly related to some 
> stack overflow / underflow as OSG itself report to me:

yes, but it is an OpenGL stack (either for matrices or state I would 
guess), not the program stack. These messages basically come from 
glGetError().

> WARNING: 
> (/usr/local/sdk/OpenSG-2.0-src/Source/System/State/Base/OSGMaterialChunk.cpp,355):
>  
> material:changed:precheck failed: stack underflow (0x504)
> 
> ... then 'overflow'message keep coming forever...

[SNIP - code]

> The visual effect of the problem is that some other textures in the 
> scene ( which are drawn using OpenSG directly inside a custom OSG node 
                                ^^^^^^
Do you mean OpenGL ? Assuming it for the rest of the mail.

> created by myself ) get wrong.

are you careful to restore all state you change in that core? Otherwise 
OpenSG will be confused, since it does not know about state changes 
inside your own core. Do you use glPushMatrix/glPopMatrix or 
glPushAttrib/glPopAttrib ?

> If I remove the two marked lines, everything works....
> 
> I've checked the tutorials and the textures are set exactly like this 
> (text obj followed by its env chunk).

yes, the code you posted looks ok.

> The alpha texture shown in the code above is used only to perform some 
> blend of a alpha texel and the ocean texture and then set the visibility 
> of the ocean texture from 0 (not visible) to 1 (full).
> 
> This used to work on OSG 1.8 just fine, but the env object was not 
> necessary as the Env mode (GL_REPLACE, etc ...) could be set in the 
> texture chunk itself.

yes, the TextureChunk has been split to separate the "texture data" from 
the way it is applied to an object.

> And clue?

hm, the problem with the checks for glGetError are that you only get a 
message at the first check after the problem has occurred, not right 
away when it does.
Can you run your program under bugle and see if you can locate which 
OpenGL operation fails ?

        Cheers,
                Carsten


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to