GL_POSITION_MAP_ARB ?

GL_NORMAL_MAP_ARB is equivalent to DX8’s D3DTSS_TCI_CAMERASPACENORMAL (Use the vertex normal, transformed to camera space, as the input texture coordinates for this stage’s texture transformation.)

is there an equivalent to DX8’s D3DTSS_TCI_CAMERASPACEPOSITION ? (Use the vertex position, transformed to camera space, as the input texture coordinates for this stage’s texture transformation.)

Originally posted by opla:
[b]GL_NORMAL_MAP_ARB is equivalent to DX8’s D3DTSS_TCI_CAMERASPACENORMAL (Use the vertex normal, transformed to camera space, as the input texture coordinates for this stage’s texture transformation.)

is there an equivalent to DX8’s D3DTSS_TCI_CAMERASPACEPOSITION ? (Use the vertex position, transformed to camera space, as the input texture coordinates for this stage’s texture transformation.)[/b]

Wouldn’t that be the same as GL_EYE_LINEAR?

I just need the eye coordinates as the input texture coordinates.
So, using EYE_LINEAR, I had to cancel the operation ( p’1 p’2 p’3 p’4 ) = ( p1 p2 p3 p4 )M^-1 using the transpose of the modelview as EYE_PLANE.
would have been better with a GL_POSITION_MAP_ARB …

If you have a vertex program enabled card (GF2 with software, GF3+, Radeon 8500+, etc) you could use ARB_vertex_program and generate it yourself… shrugs

I’m using a GeForce2 Go with detonator 16.42 and I don’t plan to buy a new computer. OpenGL should not be limited to GeForce and Radeon cards anyway.

[This message has been edited by opla (edited 10-22-2002).]

I think GL_OBJECT_LINEAR is what you need.

I need the eye coordinates as the input texture coordinates.
EYE_LINEAR gives eye coordinates, but transform them with EYE_PLANE * inverse modelview.
OBJECT_LINEAR gives object coordinates. I could use the OBJECT_PLANE to transform them to eye coordinates, but it’s as complex as EYE_LINEAR anyway.
I just think that a GL_POSITION_MAP_ARB would be nice (EYE_LINEAR without the transform with EYE_PLANE * inverse modelview).

You could simply set your modelview matrix to identity while you specify the texgen planes:

glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadIdentity();

… Set up tex gen here …

glPopMatrix();

[This message has been edited by bakery2k (edited 10-22-2002).]

It’s not that easy.
My OpenGL renderer has the same design as the DirectX renderer. So I can’t use that kind of hack.

Originally posted by opla:
It’s not that easy.
My OpenGL renderer has the same design as the DirectX renderer. So I can’t use that kind of hack.

Excuse me if I don’t understand correctly. What is stopping you adding four lines of code to your gl version of the “set tex gen” function? You are already willing to set up the planes differently for OGL and DirectX.

in my renderer, the calls to texgen are stored in a display list (which can contains other code that uses the modelview matrix). So, I can’t change the modelview matrix before and after the call to the display list. And I’m not going to change the design of my renderer.
you don’t change the modelview matrix like that anyway, it’s an ugly hack. That can only cause problems later in the development (when you or another programmer expect the modelview to be the modelview and not an identity matrix).
I don’t make any assumption about how works OpenGL, because you can have surprises using a different implementation.

Sorry, maybe I didn’t explain clearly enough. The modelview matrix need only be identity at the time you are setting the texgen planes up. So, you could put the code within your display list:

//Start display list

…other display list stuff using modelview matrix…

glPushMatrix();
glLoadIdentity();
glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
glTexGenfv(GL_S, GL_EYE_PLANE, eyePlane1);
…repeat for t,r,q
glPopMatrix(); //reset modelview matrix now we have set up texgen

…other display list code using actual modelview matrix…

//End display list

>you don’t change the modelview matrix like that anyway, it’s an ugly hack.

How else would you change it?

>That can only cause problems later in the development (when you or another programmer expect the modelview to be the modelview and not an identity matrix).

Sorry, but I dont understand this. The modelview is only identity for 8 lines of code.

Sorry, maybe I didn’t explain clearly enough. The modelview matrix need only be identity at the time you are setting the texgen planes up.

I know, that why I said " I can’t change the modelview matrix before and after the call to the display list"

>you don’t change the modelview matrix like that anyway, it’s an ugly hack.

How else would you change it?

I meant you shouldn’t do that

>That can only cause problems later in the development (when you or another programmer expect the modelview to be the modelview and not an identity matrix).

Sorry, but I dont understand this. The modelview is only identity for 8 lines of code.

re-read this “the calls to texgen are stored in a display list (which can contains other code that uses the modelview matrix).”
I give the parameters before calling the display list, your hack means that the modelview would be identity for all the display list. If the modelview is used for somthing else in the display list, there’s a bug.
the contents off the display list depends of a text file (which contains a description of the desired effect, and is compiled into OpenGL code).

opla, this is not a hack, it’s the normal way to do things like this.
You push the modelview matrix, set’s it to identity, set texgen. Now the driver backs up the current identity modelview matrix. Now you restore the modelview matrix again.

The texgen doesn’t read the current modelview matrix when calculating the texcoords, it’s using the modelview matrix stored from when you set the eye planes. Thus you only need to have the modelview as identity when you set the eyeplanes, but not later on. So these lines of code will do what you want it to do without disturbing anything else.

You can make EYE_LINEAR work for any specific world transformation just fine. Either make it up in the planes you specify for S,T,R coordinate generation, or just make it up in the texture coordinate matrix.

Or you can just call glTexCoordPointer() and pass it the pointer to your vertex position, and transform to eye space with the texture coordinate matrix.

There’s so many ways of accomplishing what you want, I think the hardest problem is choosing which implementation to use :slight_smile: