k, how do you get the light to move with the level? simple question, im sure you know what im talking about
Printable View
k, how do you get the light to move with the level? simple question, im sure you know what im talking about
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);
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.Quote:
how do you actually update the light's position?
edit:
erm, my bad, glLight3f isn't a function, it's just glLightf
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
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):
Quote:
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.
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?
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.Quote:
Originally Posted by bluehead
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 dynamicQuote:
He 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.Quote:
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?Quote:
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
>>*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.
That's fine and dandy, if you know how to implement these things. If you're still learning, the worst thing you can do is worry about speed when you don't know the concepts. Everybody that I know of working on large successful projects follows the code first optimize later scheme. What happens when you try writing a large project while trying to 'optimize' first? This:
Quote:
Originally Posted by Bubba
Me, on the other hand, the last project I abandoned was huge (as in I haven't been coding in the last year), at over 20,000 lines of code (C-Metrics) but it was modular, easy to follow and edit by others, and I was satisfied with its layout (it took care of a plethor of things including 3D rendering based on binary and quad spatial partitioning, culling, sphere and box physics, basic realtime lighting, basic static lighting, and hooks for vertex buffer objects and fragment/vertex shaders), and I wrote it entirely on the 'code first, optimize later' mechanism. I guess I don't need to mention the doom3 alpha basically wouldn't run on even the fastest computers, suggesting they also followed the code first optimize later scheme.
But, we all ultimately find what works best for our individual needs.
>>What happens when you try writing a large project while trying to 'optimize' first?
I didnt say optimize first. I said design first. You can always go back and optimize later, but if you start with a poor design there's not much point.
What happens when I try writting a large project? The current project I hack on at work has about 2.5 million lines of code. We desing first, then implement, it works great ;)
>>Me, on the other hand, the last project I abandoned was huge (as in I haven't been coding in the last year), at over 20,000 lines of code
well, i guess that depends on your definition of *huge*.
Of course you are going to have a design first.
You seemed to imply basing your design around optimizations. Hence my comment about worrying about the slowness of real time lighting when the OP doesn't even know how to properly position a light. If you worry about optimizations when you are making a design, it typically goes bad, simple as that.
What 3D company do you work for and what types of 3D applications do you work on?
This will get you into a mess in a hurry.Quote:
*slaps forehead* didn't your mom ever tell you not to worry about speed until you've got a working implementation?
Since you feel at liberty to discuss things about my engine I will explain. The architecture needs to be changed so that I can load everything from disk instead of create it on the fly from mathematical geometry. It also needs to be changed so that one render function can render the entire world. Right now it is using an object-based render setup where each object is responsible for rendering itself.Quote:
Quote:
Originally Posted by Bubba
In fact I'm going to totally re-do the entire engine because I'm not happy with the current architecture and I'm not happy with the current code base.
It needs a complete facelift and rather than try to edit existing code, I'm going to change the whole setup.
But after spending 4 hours messing with MFC and having it totally erase my work because MS can't program anything remotely stable, I'm not really into coding right now. Heck I might just erase the whole frieking XSpace and start over.
There are several things you must optimize in Direct3D programming:
1. Only call SetTexture() when it is absolutely necessary.
2. Change render states as few times per frame as possible.
3. Only call SetTransform() when it is absolutely necessary.
4. Render all primitives in huge batches.
5. Use one huge global vertex buffer that contains the entire scene, also with triangle-strips applied to areas that they can be, and render the entire scene from that buffer.
Many of these seem simple but they are not...but they are the key to gaining a lot of performance under Direct3D. The SDK has many more optimizations as well like geometry caching and other hard to implement schemes.
I will tell you that if you just jump out and code you will code yourself into a corner. You must design and you must at least have something in mind about what performance you want or you will never get it. You know how hard it is to change a rendering system from object-based to then using a global vertex buffer and having everything in it? Extremely difficult. It would have been better to design a global vertex buffer and render from it from the beginning - again design is important, but design with a purpose and with a goal.
You can't just throw some DX code together and expect it to work and be applicable in all cases. It just doesn't work like that. Sure, it might work, but it's not extensible, it's not fast, and it creates more problems than it solves.
>>What 3D company do you work for and what types of 3D applications do you work on?
3D graphic programming is my hobby. My programming at work has nothing to do with graphics.
And I'm the biggest loser of em all because I don't even program for a living. I do all this stuff for 'fun'
Sick eh.
I did this for about four years solidly (i.e my high school years). I got really good at it and had the intention of being a game programmer, then I just decided I don't want it or school and now I'm joining the military :)
heh
the great thing is. I've been programming since 6th grade. But i was too stupid to understand the concepts of any of the newer, more advanced things (like opengl/window programming) so i never got to it.
i program as a hobby, too, but some money motivation would be great... once i get older, of course.
so, quickly back on topic for a second
~would the light move the same as the whole world does? as, following the glTranslate i use for the world? or do i have to do it differantly
Yes, you apply the same transformation to the light as you do to the world :) We made a lot of posts to get that simple point across, lol
edit:
yeah, a lot of the math stuff in GL is pretty hard. And windows programming, well, it takes a lot of arcane winapi crap just to get a friggin window up that you can draw to.
Gah, if the WinAPI wasn't so freaking intimidating to make that window I'de bet you money that there would be more OpenGL programmers.
Personally I do programs in three steps:
1) Draw my design plans
2) Assign a weight to each module of my design
3) Rearrange / change the type of module I'm using to make the smallest total weight.
Coding doesn't fall into this since when I code I do both implementation and first/second phase optimizations when I code. All other optimizations I would need / would benefit from are usually from me skimming over my mistakes I try not to make next time. Usually programming this way has always been better for me personally, time, money, and confusion wise.