When you Generate, Bind and glTexImage3D a texture, where is it in texture space? Is it dependant on the current text gl_texture matrix?
What are its co-ordinate bounds assuming the identity matrix is loaded? 0,0,0 to 1,1,1 if clamped?
If the texture is not the same size in all directions the do the bounds still go from 0,0,0 to 1,1,1?
A texture has no coordinates of its own.
your texture coordinates are an attribute more or less of your vertex. each vertex has an associated texture coordinate which tells OpenGL from where to sample the texture. The texture is interpolated from one vertex to the next based on the texture coordinates supplied to it by the corresponding vertex.
Agreed…
However if you are using glTexGenfv then where is the texture?
All glTexGen does is create those texture coordinates for you depending on the enumeration you send it (GL_REFLECTION_MAP, etc…).
these are normally created by OpenGL given the vertex position and the ‘eye vector’ (the vector from the observer to the vertex).
I think you’re thinking of the texture as being defined in some space somewhere, which it’s not.
Yes, the texgen parameters specify the space that’s what _OBJECT and _EYE means. Although the OBJECT plane equations are transformed through the modelview matrix when specified.
If the texture is not the same size in all directions the do the bounds still go from 0,0,0 to 1,1,1?
Yes.
By the way, while the texture itself does not define a space, I usually refer to it as “texture space”.
Yes, this post says just the opposite of what said up to now, let me explain.
First, this is a term I use myself. I find rather good with it and I know it’s not the best name around to indicate this space. It still sounds quite nice to say “texture space coordinates lies in [0…1] range at lookup”.
In fact, texture space is not really called that way. Some old bump-map papers used to refer to it when explaining how to build the normal vectors with various names.
What are its co-ordinate bounds assuming the identity matrix is loaded? 0,0,0 to 1,1,1 if clamped?
Coordinates as defined by the vertex attribute are different thing than lookup coordinates.
The coordinate itself can be of any value, no limitations on it at all.
When the VP loads the attributes, it applies the xform matrix on it (it really should but in fact most VPs will assume IDENTITY and spare some cycles). The output of this is another coordinate vector. It has unlimited range. Well, all the obvious precision issues apply however.
When the lookup operation takes place, the texture objects applies WRAP, CLAMP (or other similar operation) to the vector and performs the real lookup. In fact this reduces the coordinate vector to have all components in [0…1] range. There’s a good reason to do that.
This post needs to be really interpreted. It’s probably not a good one. Take it with some salt.
Originally posted by dorbie:
Yes, the texgen parameters specify the space that’s what _OBJECT and _EYE means. Although the OBJECT plane equations are transformed through the modelview matrix when specified.
Dorbie,
Maybe I misinterpreted your post.
Both eye and object planes operate on vertices which are transformed through the modelview matrix. But aren’t the EYE plane equations transformed through the inverse modelview matrix when specified, and the object planes kept the way are specified?
Nico
Yes you’re right Nico I mixed them up, which of course makes perfect sense, in the object_linear case you texgen in object space irrespective of the matrix, in the eye_linear matrix case you have the potential to texgen in eye space or transformed to ‘world’ space (or some other space) depending on what was on the modelview matrix stack when you sent the plane equation.
My bad.