Vertex Programs

OpenGL OpenGL: Basic Coding
1

I’ve got a problem with TrackMatrixNV(enum target, uint address, enum matrix, enum transform);
.
Thr last parameter - transform - could be one of the following values:IDENTITY_NV,INVERSE_NV,TRANSPOSE_NV and INVERSE_TRANSPOSE_NV.

So, what I understood:
IDENTITY_NV: Tracks the Matrix as it is e.g. (vector)a’ = (matrix)M*(vector)a
INVERSE_NV: Tracks the inverse of the matrix. e.g. (vector)a = (inverse matrix)M^-1*(vector)a. If you have eyespace coordinates you can transform them back in world-space one’s.

BUT: What does TRANSPOSE_NV and INVERSE_TRANSPOSE_NV mean (my poor english…)? And what does it? Why do you track normals with INVERSE_TRANSPOSE_NV and not with IDENTITY_NV?

Thanks
qwert

2

Transpose of a matrix is like this:

If M1 =
[a b c d]
[e f g h]
[i j k l]
[m n o p]

then M1' =
[a e i m]
[b f j n]
[c g k o]
[d h l p]

Hope that helps.

3

Thanks, that helps.

I try to understand Nutty’s spec_nvp on www.nutty.org . There he made the following transformations (all with the ModelView-Matrix): he transforms the vertex-position with GL_IDENTITY_NV. The normal is transformed with GL_INVERSE_TRANSPOSE_NV and the light with GL_INVERSE_NV.

Why this? why can’t I(he) transform everything with the GL_IDENTITY_NV?

4

Because normals don’t have to be translated such as vertex position, only the rotation part of the matrix is useful (the scaling part can be too easily “annuled” by normals renormalisation or rescaling).

@+
Cyclone

5

Ok. And if I use GL_INVERSE_TRANSPOSE_NV only the Rotation-part of the matrix will by applied? I can’t imagine that. The inverse of a Matrix A transforme a already transformed (with Matrix A) point back.

Is there a rule, that vertex are transformed with the identity, the normals with the inverse_tranpose, and the light by transpose?
I don’t get it.

6

That’s the point. You won’t transform points with the inverse transpose, you will tranform the normals with this. It takes into account, that movement doesn’t affect normals, as uniform scaling does not too.

7

Ok. I think I got it now. Thank you all

8

But what is with the Light-Poition? With the Normals it’s clear. They stand for a direction, so translation would be fatal. The Light-Position should be translated an rotated like a usual Vertex, shouldn’t it?

9

c[0-4] ModelView Matrix

“DP3 R0.x ,v[NRML] ,c[0];”
“DP3 R0.y ,v[NRML] ,c[1];”
“DP3 R0.z ,v[NRML] ,c[2];”

Wouldn´t this transform the normal only with
the 3x3 rotation part of the modelview matrix
or am i totally wrong?

so if this is correct why the transpose matrix?

10

Dont look at me, I just wrote the things!

If any of it is wrong, someone tell me, and I’ll sort them out.

Seems to work thoug…

Nutty

11

I think this should be right,too…
Same question here…

For the Light-Pos, the transformation with identity should be right, not? (No inversed Matrix)

12

It depends on what nutty has done in his program. If he uses the vertices ,transformed in eye-space (with the identity) ,I think you have to put the light also in eye-space ,but if he uses the vertices of the object in object-space I think you have to use the inverse?!?!

if I´m wrong please help me!

13

The light’s position is affected by the normal modelview matrix.

14

Let’s presume the following szenario:

First I set the viewers position with some rotation an translation: Matrix A

I draw an Object: I “push” the current matrix,do some other roatations and translations and draw (Matrix B), and “pop”.

So which Matrix will the VP receive by the drawing? A or B? if only Matrix B, how can I transforme the vertices in eye-space? How can I distinguish in the VP between object-space(Matrix B) and eyepspace (Matrix A)?

Please help!!

15

I’m tired… of course by the projection matrix…
Sorry!

16

The lighting is done in object space.

The modelview matrix takes object space into world space. Thus to convert the world space light into object space we use the inverse modelview matrix.

I think that explains it nicely.

Nutty

17

Huh? Are you talking about per-pixel lighting using the vertice’s space?

18

Ok, Nutty, that makes sense. So, for the normals we consider only the rotation, for the lighting we transform with the inverse the world-space coordinates of the light. So you got everything in object-space and may calculate lighting…

19

Michael, No. Not per pixel, just vertex lighting, done in object space. Prevents redunatant transforms of vertices to world space, doing lighting in object space, thats why I did it like that.

Nutty

20

Why do you do pervertex lighting by hand, when OpenGL and HW TnL provide it much faster I guess? Are you targetting for below GeForce? Just curious.