Compatibility state

[hlewin]

Is there another document out besides http://www.opengl.org/registry/doc/G...pec.4.30.6.pdf that describes the uniforms of the compatibility Profile?
I do not find informations that would be necessary to duplicate the fixed-function functionality that the gl provides in the section about compatibility state variables.
At least quick-reading the document linked above as well as the gl-4.0 compatibility spec leave a lot of questions:
Where can be looked up if - for example - lighting is enabled for which lights (or are the Settings simply zeroed out?)?
Which variables hold Information about which texture target is bound to which texture unit? Where are the samplers?

Are those informations hidden in the documents and not listed in the summaries or aren't they contained at all?

[malexander]

Look in section 7.5.1 of the GLSL 1.5 spec, it lists all the compatibility state. It hasn't changed from 1.5 to 4.3, unless you're using a core profile, in which case it's been removed

If you need to know the default settings, check out the man pages for various GL functions that set them (glLight, glMaterial, etc).

[hlewin]

That really does not see different when compared to the document linked above. How can for example texture-mapping be applied using only the compatibility-state? It must be in there as open-gl 1.X can do texture mapping.

[malexander]

Texture mapping doesn't have any built-in GLSL uniform compatibility state. You have to bind textures to units just as in the fixed function state. Then, assign the unit number to the uniform corresponding to the texture sampler in the shader, and then use a texture() method to sample the texture using that sampler.

   // program:
   glUseProgram( prog_id );
   glUniform1i("diffuse_tex", 0);
   glActiveTexture(0);
   glBindTexture( GL_TEXTURE_2D, diffTex );
 
   // shader:
   uniform sampler2D diffuse_tex;
 
   void main()
   {
        vec4 col;
        vec2 texcoord;
        texcoord =  [tex coords from vertex shader, likely];
        col = texture( diffuse_tex, texcoord);
   }

[hlewin]

That's what I read from the spec. And I wonder about it. The compatibility-profile-state should encompass any state-variable that is needed to achieve the functionality described by the opengl-legacy functions: One cannot replace the default-functionality-shaders without loss of functionality with only the Information given in the profile-spec.

[malexander]

What kind of texturing are you trying to do? I haven't run into a situation where I wasn't able to do something in shaders that fixed function could do. I make my own uniforms and pass the information I need to the shader through them (such as 'uniform int enable_diffuse_map'). Some of the old texture environment is convenient, but fairly straightforward to code in a shader. Plus you get a lot more flexibility than the old texture combiners.

[hlewin]

For example if I want to Exchange the underlying vertex- and Fragment-processing of a program that was written for the legacy functionality. It uses texture-mapping and all other kinds of functionality but does NOT use shaders of any kind. That should be possible without losing any functionality.
EDIT: I do not need any help implementing texture-mapping etc. in shaders using the functionality in place in the newer Versions. It is I am confused over the specification of the compat-profile. A program using legacy-functionality that is worked on cannot easily replace old fixed-functionality in parts with the Profile as it seems. That would be a lousy specification. It should be possible to write shaders that duplicate the fixed-functionality of OpenGL in a 1:1 Fashion and do not Need any changes in the application code.

[malexander]

My shot-in-the-dark guess is the the texture state isn't part of the GLSL uniform state because it was either too complex or no one used it.

[Alfonse Reinheart]

Is there another document out besides http://www.opengl.org/registry/doc/G...pec.4.30.6.pdf that describes the uniforms of the compatibility Profile?

That's the GLSL specification. This defines what GLSL is; if it's not in there, it doesn't exist (or there's a spec bug).

It should be possible to write shaders that duplicate the fixed-functionality of OpenGL in a 1:1 Fashion and do not Need any changes in the application code.

What you're talking about is the glTexEnv state. That's not available because what you're wanting to do is not what the compatibility stuff is for.

The purpose of the compatibility state tracking is to allow users to slowly transition part of their code to the new methodology. It was never the intent to be able to do so with no changes, only relatively few. glTexEnv, for example, is considered too intimately associated with the fragment processing scheme to use. Plus, back when people actually used the state tracking stuff, you would have to have a fragment shader that looked like this:

vec4 texVal0 = texture2D(tex0, gl_MultiTexCoord[0]);
if(gl_TexEnv[0].func == gl_TexEnvCombine)
{
}
else if(gl_TexEnv[0].func == gl_TexEnvADD)
{
}
...

This could would be unacceptably slow on modern machines. On machines of the GL 2.0 era, it simply wouldn't compile.

glTexEnv is the equivalent to modifying your shader's source code, not merely setting a parameter. Thus, it's state is not tracked.

[hlewin]

When talking about the compatibility-profile I would not care about performance issues when it comes down to mimique all defined behaviour in a shader. I would merely point out that the compatibility-state-variables should expose enough information to theoretically replace all defined fixed-pipeline-behaviour with shaders that do the same stuff.
This is where I do not get your reading

The purpose of the compatibility state tracking is to allow users to slowly transition part of their code to the new methodology.

Having informations about which texture-units are enabled, exposing sampler variables for these unit, informations about lights that are enabled, all that are things I would have expected to be in the profile. WIth that information one can easily
precede blocks of legacy-rendering code with a useProgram-statement and maybe enhance the visual-experience.
I really do not know what the big point of the core-profile is. If an attribute is specifed with vertexAttrib or texCoord and thus named myVertexAttrib or gl_MultiTexCoords in the shader - what is the big difference? If you had to state the core principles of the new methodology, what would it be?
This is why I would call

It was never the intent to be able to do so with no changes, only relatively few.

that a poor design decision.