k, how do you get the light to move with the level? simple question, im sure you know what im talking about
k, how do you get the light to move with the level? simple question, im sure you know what im talking about
Code:#if _emo #define stereo_type_i_dislike #endif
set the position everytime the viewpoint changes. (ie: put this in your render loop)
glLightfv(GL_LIGHT0, GL_POSITION, lightPosition);
To Bluehead's sig: yes I do, fluently.
To Jverkoey: ha. i dont
now, back on topic..
i know i did it completely wrong, i took a really random guess...
how do you actually update the light's position?Code:glTranslatef(-xmov,ymov,zmov); GLfloat LightPosition[]= { xmov, ymov, -zmov, 1.0f }; glLightfv(GL_LIGHT1, GL_POSITION, LightPosition);
Code:#if _emo #define stereo_type_i_dislike #endif
edit: hold up, im not so sure i understand the question anymore. Can you explain what your trying to do?
Looks like he is moving a light inside of his level. I personally don't recommend this type of dynamic lighting because the overhead is huge. This effect is usually only needed when the source of the light originates at the player or camera position. Normally this is simulating the player holding a flashlight of some type.
Other than that, it's just a waste of GPU.
He didn't ask about the validity of dynamic lighting and I always thought vertex lighting was fast enough to be trivial.
Well how do you update the variables you send to glLight*? Perhaps you should just call glLight3f instead of glLight3fv.how do you actually update the light's position?
edit:
erm, my bad, glLight3f isn't a function, it's just glLightf
Last edited by Darkness; 04-04-2005 at 04:31 PM.
See you in 13
Well, this "Camera" had to be made by moving the whole entire level opposite from the user's input
and, when i just put in a light, it stays there. so the 'level' is moving around hte light
Code:#if _emo #define stereo_type_i_dislike #endif
So you are telling me a few things:
-You are moving the world around the camera to simulate looking around
-The light's position is supposed to remain in the same spot, relative to the rest of the world
So, for every vertex of the world, you are applying a transformation to it so that it looks like you are looking around. How do you do the same to the light's position?
edit:
to quote something from the link I posted (go down to params, and then the GL_POSITION part of it):
The position is transformed by the modelview matrix when glLight is called (just as if it were a point), and it is stored in eye coordinates. If the w component of the position is 0.0, the light is treated as a directional source. Diffuse and specular lighting calculations take the lights direction, but not its actual position, into account, and attenuation is disabled. Otherwise, diffuse and specular lighting calculations are based on the actual location of the light in eye coordinates, and attenuation is enabled. The default position is (0,0,1,0); thus, the default light source is directional, parallel to, and in the direction of the z axis.
Last edited by Darkness; 04-04-2005 at 07:21 PM.
See you in 13
You guys make it sound like i'm doing it in some alienated way
is there an actual way to move the CAMERA, instead of the whole world?
Code:#if _emo #define stereo_type_i_dislike #endif
Have a series of glTranslatef and glRotatef functions or use gluLookAt at the beginning of your code, and then use a series of glPushMatrix(); and glPopMatrix(); to render your objects.
No, but you can trick yourself into believing you are by using gluLookAt. But ultimately you are moving the world around a fixed eyepoint.Originally Posted by bluehead
Last edited by Darkness; 04-05-2005 at 06:10 AM.
See you in 13
Lighting is never trivial. Even dot3 lighting incurs 3 muls for every computation of the dot product. On the GPU this is not a big deal, but within GL or DX it is. Most cards have a max number of lights because the computations are squared per light added to the world. Many games accomplish lighting with 1 or 2 dynamic actual lights and the rest are light-mapped textures or other texture tricks that simulate light. Most of the light in games is static, not dynamicHe didn't ask about the validity of dynamic lighting and I always thought vertex lighting was fast enough to be trivial.
You are thinking about things in the wrong way. When you drive down the road, what does the outside scenery do and the road do in relation to your car?? It moves towards you right? So when you look at your dashboard, your gearshifter, the seats, etc., they are all seemingly motionless- even though you know they are moving. But from the car's point of view, and from yours, the world is moving, not the car.is there an actual way to move the CAMERA, instead of the whole world?
It's the same in 3D graphics. You must move the world relative to the camera. Essentially what you are doing is saying ok the camera is at x,y,z - so let's make x,y,z the center of the world or the origin of it. So you translate everything relative to the origin which essentially places the camera at 0,0,0 in the world. In fact, it is always at 0,0,0 and this makes the calculations much easier since everything is relative to the camera.
In 3D graphics you must 'bring the world to the viewer or camera' instead of actually move the camera. Notice that you still do actually change the coordinates of the camera.
Camera.Pos+=Camera.LookVector*Camera.Speed;
But then also notice that you translate by the opposite amount which brings the camera again to the center of the world and brings all the world coordinates of all objects into camera space where everything is relative to the camera.
This makes z depth and z ordering much simpler because we always know that the camera is the center of the world. So an object with a z value of 100 is 100 world units away from the camera, no matter what the actual world camera position may be.
*slaps forehead* didn't your mom ever tell you not to worry about speed until you've got a working implementation?Lighting is never trivial. Even dot3 lighting incurs 3 muls for every computation of the dot product. On the GPU this is not a big deal, but within GL or DX it is. Most cards have a max number of lights because the computations are squared per light added to the world. Many games accomplish lighting with 1 or 2 dynamic actual lights and the rest are light-mapped textures or other texture tricks that simulate light. Most of the light in games is static, not dynamic
See you in 13
>>*slaps forehead* didn't your mom ever tell you not to worry about speed until you've got a working implementation?
why?? so you can have a working implementation with poor performance and realize "Crap, i designed this wrong from the start. Now i need to start over from scratch"
The "Code now, optimize later" approach just doesnt cut it IMHO, you need to carefully consider design decisions before implementing anything.