What are the requirements for vertex shader textures?

Started by
6 comments, last by Jackis 18 years, 7 months ago
Hullo, I need to access a texture in my vertex shader and when I try, though I don't get any errors the stuff I collect from the texture seems perfectly random. What are the requirements on a texture that you want to use in a vertex shader?
Advertisement
rtfm, rtfs ))))
Search for "Shader Model 3.0: Using Vertex Textures" whitepaper at developer.nvidia.com:

Here is an example of creating texture:

GLuint vertex_texture;
glGenTextures(1, &vertex_texture);
glBindTexture(GL_TEXTURE_2D, vertex_texture);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
GL_NEAREST_MIPMAP_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE_FLOAT32_ATI, width, height, 0,
GL_LUMINANCE, GL_FLOAT, data);

Here is an example ARB vertex program that illustrates how to perform a simple
texture lookup:

!!ARBvp1.0
OPTION NV_vertex_program3;
PARAM mvp[4] = { state.matrix.mvp };
PARAM texmat[4] = { state.matrix.texture };
PARAM scale = program.local[0];
TEMP pos, displace;
// vertex texture lookup
TEX displace, texcoord, vertex.texcoord, 2D;
// try and do as much work here as possible that isn't
// dependent on the texture lookup, to cover latency
MOV result.texcoord[0], texcoord;
MOV pos.w, 1.0;
// scale vertex along normal
MUL displace.x, displace.x, scale;
MAD pos.xyz, vertex.normal, displace.x, vertex.position;
// transform position to clip space
DP4 result.position.x, mvp[0], pos;
DP4 result.position.y, mvp[1], pos;
DP4 result.position.z, mvp[2], pos;
DP4 result.position.w, mvp[3], pos;
END;
Right, thanks.
I've already read that document though and what I was asking for was exactly what formats are possible to use, not an example of one. That document claims that only the GL_LUMINANCE_FLOAT32_ATI and GL_RGBA_FLOAT32_ATI formats are allowed, but it's almost a year old and I get exactly the same (weird) results with these modes as with GL_RGB32F_ARB. What min/mag filters and what clamping modes are allowed?
AFAIK, filtration depends on the abilities of your graphical hardware.
Better wait until more experienced vertex texture users reply you )))
Heh,
It turned out it wasn't the texture access after all. That works and something else goes wrong. Maybe someone here can see it. I send in a 2d texture of values and a 1D index into this texture. Then I have a function to create the 2d texturecoordinate from this index which looks like this:
float2 coords(int i, int texture_size){  float2 ret;  ret.x = ((i % texture_size)+0.5)/(float)texture_size;  ret.y = (((int)(i / texture_size)+0.5))/(float)texture_size;  return ret;}


It doesn't work though. When I ask for index x i get something close to x but not x. I can't see what's wrong. Anyone?
Could you please post some source code, in order to examine the problem more seriously? ))) And show, how do you "fill" you texture, which is used later for vertex texlookups, ok?
Allright, I found the problem now, it still confuses me, but I don't have time to figure it out. Something very weird happens. When running the following code in the vertex shader:

float3 coords(int i, int texture_size){  float2 ret;  ret.x = 102%texture_size;  ret.y = 102%97;  ret.z = texture_size;  return ret;}


The result is [4,5, 97]. That is ret.x and ret.y are different even though I calculate excactly the same thing into them. Cutting and pasting the coords function i posted above into my cpp program instead and passing the precalculated values as attributes to the vertex program solved the thing. Weird though. Thanks for taking the time Jackis,

Erik
Right...
The problem is in float/integer/float conversion. I guess, you know, that 3D hardware has no native support for integer values, only floating point arithmetics, that's why such a conversion are very dangerous, cause result is undefined in almost cases ))) Try to use normalized float coordinates for texture acceses, I meen, if you need some modulos, use fmod() routine (I speak in terms of Cg language), cause it gives predefined results, instead of integer calculations. That's what I suggest, may be, other persons have other points of view )))

This topic is closed to new replies.

Advertisement