Jump to content
  • Advertisement
Sign in to follow this  
Erik Sintorn

What are the requirements for vertex shader textures?

This topic is 4820 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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;

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
AFAIK, filtration depends on the abilities of your graphical hardware.
Better wait until more experienced vertex texture users reply you )))

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 )))

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!