PDA

View Full Version : rotating lightsource

d98rolb
07-23-2000, 04:02 AM
I have a single object in origo and a lightsource. I want to rotate the object without touching the lamp. So I can see the moving shadows on the object. But the whole scene is rotating. What's wrong?
Are there any good example how to do this?

/Roland

ribblem
07-23-2000, 10:01 AM
The problem is that you're putting the light it the local model scene. The clearest way to fix this is to get the current modelview matrix right before drawing the light. Then strip this matrix down to only the rotate portion (ie set traslate portions of the matrix to 0). Now it should be really easy to get the inverse matrix. So get that inverse guy and multiply the current modelview by this "un-rotate" matrix. This will put the light in the global scene which is where you want it for this application.

Relic
07-23-2000, 10:12 PM
Yes, right, but this is a rather complex solution.
You can also set the light's position before you manipulate the matrices for the object.
The easiest way would be to specifiy the light position as long as the modelview matrix is identity.

07-24-2000, 06:17 AM
You can also use push/popmatrix to solve this

d98rolb
07-25-2000, 01:55 PM
I don't quite understand what you are talking about. But I have made some experiment on an example I found.

drawCube(int color)
{
int i;

setColor(color);

for (i = 0; i < 6; ++i) {
glNormal3fv(&cube_normals[i][0]);
glBegin(GL_POLYGON);
glVertex4fv(&cube_vertexes[i][0][0]);
glVertex4fv(&cube_vertexes[i][1][0]);
glVertex4fv(&cube_vertexes[i][2][0]);
glVertex4fv(&cube_vertexes[i][3][0]);
glEnd();
}
}
This works fine and the cube reflects the light nice. The simple cube have precalculated normals. If I remove the line glNormal3fv() the problem come back and light rotate with the cube.
I don't think I can precalculate any normals on my object. It's a mountain with dynamic numbers of triangles.

/Roland

Harry of DAIW
07-26-2000, 02:15 AM
i had a similar problem with rotating.
i just forgot glEnd() in an earlier called void. perhaps you did the same ... http://www.opengl.org/discussion_boards/ubb/smile.gif ...

DFrey
07-26-2000, 05:54 AM
Yes, for OpenGL lighting to work correctly, you must supply vertex normals. There is no way around it. You should be able to calculate the normals as you calculate the points themselves. But since you are lighting a mountain, you can probably get away with just referencing each point with respect to a single point that is inside the mountain (call it the mountain origin for example), then just add a bit of noise to each resulting "normal". Carefully choose the noise function and it could look quite decent from afar.

dorbie
07-26-2000, 06:43 AM
You can calculate normals, it's the normalized cross product of two edge vectors of the triangle. Normals will be transformed with the object.

The lighting issue is a classic one due to the combined nature of the model & view matrix. The application must position the light source at the right TIME in the transformation sequence.

So for a light in 'world' space (not eye or object) you must:

1) position the eye
2) position the light
3) position the object
4) draw the object with normals

If you do 2) before 1) or after 3) the light will move with the eye or with the object respectively.

d98rolb
07-27-2000, 04:06 AM
[QUOTE]Originally posted by dorbie:
[B]You can calculate normals, it's the normalized cross product of two edge vectors of the triangle. Normals will be transformed with the object.

I'm finished now and it worked perfect at home on my PC with Win98. I calc the normal on every surface on the mountain. But the problem is that at school they have Win NT 4.0 and the same program show nothing only black !!!!
I thought Win NT and Win98 was compatible but it was wrong...

dorbie
07-27-2000, 04:16 PM
It should be compatible.

Are you sure you are getting a context? The hardware is different so it could be the Pixel Format Descriptor selection is failing.

heck the return values for your functions which create HDC etc.