Originally posted by V-man: This might be a stupid question but what is the defined behavior of normalize?
Not a stupid question. Normalizing a zero length vector is undefined.
I’m looking at the documentation (even of several shading languages) and all are ambiguous here. I thought I’d get bailed out on inversesqrt( 0.0 ), but no…
Which to use (texture2D or texture2Dproj) and when?
Perhaps the best way to think of it is this way:
If you know your q component is always 1.0, you might as well do the non-projective fetch. And you often do know this. For example, in fixed function if you are providing texture coordinates with glMultiTexCoord2f[v] or glMultiTexCoord3f[v], you are not using texgen, and your texture matrix is identity.
Otherwise, it still depends. What does your algorithm require? A projective or non-projective fetch?
I think your pseudo code for normalize is correct.
vec4 thing;
normalize(thing);
is done like so
r *= invsqrt(dot4(thing, thing));
so one has to be careful on the type of “thing”.
=============================================
I guess I was mistaken about ARB_fragment_program.
If tex coord is (x, y, 0, 1) then
TEX and TXP give the same results.
I’m talking about plain 2D texturing a la glTexCoord2f
I could have sweared TEX and TXP didn’t give the same result when I was learning that stuff… hmmm
and it looks like it’s the same with texture2D and texture2DProj
So the effect of the projection matrix is taken into account automatically I suppose.
Just to be clear, I’m talking about perspective correct texturing here.
Originally posted by V-man: normalize(vec4 thing) = thing/length or maybe
normalize(vec4 thing) = vec4(vec3(thing)/length_of_vec3, 1.0)
I haven’t read up in the spec, but it should definitely be the first one. It just makes more sense, plus that normalizing a four-component vector is useful functionality that there’s no reason to leave out from the spec. The second normalizing behavior can be done anyway with vec4(normalize(thing.xyz), 1.0);