Sphere texture map in GLSL

OpenGL
1

Hello,

I’m going through the Orange book and implementing the examples using RenderMonkey and GLSL 150. Of course, all of RM’s GLSL examples are 120 or less, so they use a lot of the deprecated built-ins (gl_Vertex, gl_TexCoord, etc.). As it stands, I’m trying to map the Earth.jpg texture that comes with RM 1.82 to a sphere with mixed success. I’m not sure where the problem lies - if perhaps RenderMonkey just can’t support it or if I’m not compensating for the deprecated built-ins properly. Anyway, is there any good examples of sphere texture mapping for GLSL 150?

2

You could start with looking at the default effect setup by rendermonkey. This u can do by creating a new effect right clk Effect Workspace and select add default effect->opengl->textured. This will create a simple texture mapped sphere for u.
You may then convert it into version 150 once u know what the output would be.

3

Yeah, I tried that - pretty much confirmed what I was suspecting. The issue appears to be using the TexCoord attribute that RenderMonkey supplies in the stream mapping in lieu of gl_MultiTexCoord#. Something’s going on behind the scenes that I don’t quite understand…

4

Something’s going on behind the scenes that I don’t quite understand.

Which part do u dont understand?

5

Ok, since gl_MultiTexCoord# is deprecated after version 120, it’s left to the developer to provide the texture coordinates. In RenderMonkey, I assume that means using a TexCoord attribute since there’s no other way to supply unique texture coordinates per vertex.

So, I tapped the TexCoord attribute (unit 0), and the texture is tiled on the sphere (four times in the x, twice in the y) and rotated 90 degrees. Part of the problem, I’ve learned, is that rm’s TexCoord attribute swaps the x/y coordinates. So, after adjusting for that, dividing the Y coordinate by two, then offsetting it by 0.5, I’ve managed to correct a few problems, but it’s not quite there.

In any case, it’s obvious the way RM generates texture coordinates for it’s TexCoord attribute is not the way it provides them to OpenGL for it’s gl_MultiTexCoord built-in. I’m trying to figure out how to compensate for that, I guess - unless there’s something I’ve missed in a setting in RM or some other fundamental thing that I just don’t get…

6

There is no such thing as a “TexCoord attribute”. There are simply vertex attributes, which you can do whatever you want with. You give it meaning, not the language.

Maybe you should post some shader code, as what you’re talking about seems muddled.

7

I apologize for being inexact. Vertex attributes in Render Monkey are managed in the stream mapping editor. There, you specify the attribute usage, index, data type, and name. When I referred to a “texcoord attribute” I meant a vertex attribute that supplies texture coordinates. RenderMonkey (presumably) does the rest and updates these attributes automatically with each vertex.

In any case, this mechanism is how per-vertex data (that is normally supplied by the application to the shader) is supplied in RenderMonkey. Thus, if I add a position vertex attribute (named “rm_Vertex” by default), I declare it as an “in” variable in my vertex program and it updates with the vertex coordinates as each vertex is processed by the shader. Since there is an attribute available for texture coordinates, I would normally expect it to update with texture coordinates for each vertex.

So, this is where my difficulty arises. To access texture coordinates in GLSL 120 and below, I need only assign my out texture coordinate var to the GLSL built-in, gl_MultiTexCoord[0-7]. However, that built-in is deprecated beyond 120, so I need another source for texture coordinates. Hence my issue:


fragTexCoord = gl_MultiTexCoord0.xy; //works great in version 120, fails in 150
fragTexCoord = rm_TexCoord0; //fails in version 120, works somewhat in 150

I’ve chased endless threads and found nothing, which means I either don’t understand the problem or it’s so simple no one else has issues with it. :slight_smile: But it seems to me that at this point, I need to apply some sort of transform to the texture coordinate data that RenderMonkey supplies so that it provides in version 150 what gl_MultiTexCoord0 provided in version 120…

8

Hi.
Yeah I think the mapping is incorrect. You can check this by just outputting the texture coordinate as color in the fragment shader like this.

 fragColor = vec4(uv,0,1);

For normal cases, you should get a blend of colors from red, yellow, green but here I get a solid red color.

9

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.