I'm wondering how this type of texture rendering could be made in OpenGL: Image borrowed from article: Terrain Geomorphing in the Vertex Shader I've got something similiar made in GLSL, however it doesn't give any performance near what I get from the demo that's provided by the article above. The code I'm using in GLSL is incredibly slow on my graphics card, here's what it looks like: I'm happy if I get up to 12-16FPS with my GLSL code, while in the demo provided in the article I get about 80 FPS. I'm not even sure my graphics card supports the GLSL code in hardware and instead runs it in software or something, I got an ATI Xpress 200 series card, which is an onboard type of card. What I want to know is how to implement it via glTexEnv, and I've searched all over the net about glTexEnv parameters, but haven't been able to find anything that I can understand, heh... Well any help is appreciated :)

Quote:Original post by Lord Faron
You can try to precalculate gl_TexCoord[0].xy*2.0 in the vertex shader. Also check the link log - you should have info whether the shader runs in hardware or software.

Heh, Wow, never thought about checking the log :)
However the log gives me a somewhat cryptic message, but it seems it's running in software:

Link successful. The GLSL vertex shader will run in software due to the GLSL fragment shader running in software. The GLSL fragment shader will run in hardware.

Heh, so does that mean the fragment shader is running hardware or software? :/

So I guess the only way I can make this run fully in hardware is to use glTexEnv, so anyone got any ideas of how to do that?


Oh, and I've tried precalculating the multiplication, doesn't do anything tho.


edit: Removed the vertex shader and only used the fragment shader, since the vertex shader doesn't really do anything. And I got about 10 fps increase, and it says in the log that it's running in hardware. However that still just gives me about 12-30 fps. Which sux.


EDIT: OMG! I used to have one alphamap for every terrain patch, but now I made one large for the whole terrain. I also did some other small changes and woops, I got 40-50 fps!! Weee!!

Guess I won't need a glTexEnv version after all!

[Edited by - angry on October 2, 2006 4:20:11 PM]

Oh, got a question. About the multiplication in the fragment shader, do you guys think that it really can do a slow down, or would it be faster to send another texture coordinate buffer? I'm not 100% sure that the texcoord buffer will be stored in video memory even tho I got in in a vertexbuffer object, coz I think my video card uses some shared memory kinda setup, ie. using system memory. So having to send another buffer to the graphics card seems like it could be slower than just a few multiplications.. err or what you think?

You should calculate the 2nd set texture coordinates in the vertex buffer, because a single triangle can create 100's of fragments, each of which are going to have to peform that multiplication =)

You arent supplying that much data to the fragment shader, so you dont need to worry about running out of slots for it. Besides, it also means you can add more complex tiling algorithms if its in the Vertex Shader without worrying about tying up the fragment shader (For example, tiling across non x-z axis planes)

I precalculated the tiling into another texcoord buffer, I don't see any performance increase tho.

However I thought that it could be a preformance increase just to multiply the textures that are actually used by the current terrain patch. So that you skip any textures that isn't in the patch. However I'm not sure of how to do that the best way.

If I were to create a shader program for every possible combination, I would end up with 4^4 number of shaders if I restrict my program to a maximum of 4 textures. Is that okay, or is there a better way?