Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » How to use glLight?

This thread is locked; no one can reply to it. rss feed Print
How to use glLight?
Kitty Cat
Member #2,815
October 2002
avatar

Basically, what the topic says. I have the basics down.. enable GL_LIGHTx for active lights, enable GL_LIGHTING to enable lighting, etc.. but I'm having trouble implementing the lights. I'm using them because my game uses dynamic light by (as I"ve said before) updating the lightmap in VRAM in realtime. Since the lightmap is 8 times smaller than the rest of the world (a 256x256 poly would have a 16x16 lightmap), this works fine. However, this doesn't light the 3d models.. and creating a lightmap for each poly face of a model becomes quite infeasible. So I figured I'd use vertex lighting (the vertices are close enough that this would give respectible results). I've search around and came upon glLight, which I'm trying to learn.

First, I'd prefer to have a from-camera light. So no matter which direction I look at an object from, it seems to have a small light reflection facing the camera (diffuse lighting, I think?). I might have that working actually, but I'd like to hear if there's a normal way to do this. I'd also want point lighting.. I have the color, world-space position, radius, and intensity of the light but I have no idea how to get it to work.

Can anyone help?

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

gillius
Member #119
April 2000

You can give a light a constant value such that the value is added to every object regardless of position. The "global" light is typically like this so that there is not a spot that is completely 100% black. I believe the parameter is called the "ambient light level" for a light. Point lights are OK, but directional lights are faster if you are lighting a whole world/level with it. For lighting small areas, games typically don't use hardware lights, from what I understand. If hardware lights are used, typically one or two directional lights provide everything. Dynamic light sources are done with lightmaps and in software, as you said you were doing now, with entire models getting the same light level. This was done mainly for speed. When cards got faster I believe there was never a move to hardware lights like GL_LIGHT but instead we moved right to stencil shadows. My practical knowledge in this area is a little weaker than I'd like though so some of the information may be a little off.

Gillius
Gillius's Programming -- https://gillius.org/

Krzysztof Kluczek
Member #4,191
January 2004
avatar

You could check my LD48 entry (see my sig). It used single OpenGL light placed at camera position, which resulted in overall nice vein effect. :)

Also if you are doing dynamic lighting, consider using 3D textures. I found this trick in Carmack's .plan files, and it seems to be nice idea. Set up 32x32x32 3D intensity texture, fill it with precalculated light data and turn on clamping. Then mapping x/y/z to s/t/r can be done with simple translate/scale operations (probably in vertex program). :)

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

The "global" light is typically like this so that there is not a spot that is completely 100% black. I believe the parameter is called the "ambient light level" for a light.

Yeah, but I'm trying to avoid this since it would probably make the models look out of place. If I have a small light point eminating from the camera, the models still make look a touch out of place, but the lighting is more dynamic so it fits into the rest of the scene better IMO.

Quote:

When cards got faster I believe there was never a move to hardware lights like GL_LIGHT but instead we moved right to stencil shadows.

I've been wondering what I could/should use the stencil buffer for. I figured I'd use it to draw the sky(box).. Draw the polys that are supposed to expose the sky on the stencil buffer only then draw the sky using the stencil buffer as a mask. Is that a good use for it, or should it be used for something else?

Quote:

Also if you are doing dynamic lighting, consider using 3D textures. I found this trick in Carmack's .plan files, and it seems to be nice idea. Set up 32x32x32 3D intensity texture, fill it with precalculated light data and turn on clamping. Then mapping x/y/z to s/t/r can be done with simple translate/scale operations (probably in vertex program). :)

That sounds like a pretty neat idea, actually. I may have to try that.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

gillius
Member #119
April 2000

The stencil buffer is for drawing shadows. I never thought about using it for a skybox. I suppose it could be used that way, but I'm not sure it would improve efficiency because I'm guessing you are wanting to draw all world polys to the stencil then draw the skybox.

Gillius
Gillius's Programming -- https://gillius.org/

Korval
Member #1,538
September 2001
avatar

Quote:

I figured I'd use it to draw the sky(box).. Draw the polys that are supposed to expose the sky on the stencil buffer only then draw the sky using the stencil buffer as a mask. Is that a good use for it, or should it be used for something else?

First, what does this gain you, in terms of skybox rendering, that the regular depth-test won't?

Second, why feel the need to use the stencil buffer at all? Unless you're going to employ an algorithm that specifically needs it, just leve the stencil alone. It's not wasting anything.

Quote:

The stencil buffer is for drawing shadows.

No, the stencil buffer is for using stencil tests. One of the things you can do with stencil tests is shadowing, but that is by no means the only thing you can do with it.

Krzysztof Kluczek
Member #4,191
January 2004
avatar

Quote:

First, what does this gain you, in terms of skybox rendering, that the regular depth-test won't?

I second this. Stencil test is done in about the same stage as depth test, so this won't give you any speed boost. If you'd like to render skyboxes faster you could try rendering sky polygons themselves using cube map texture, although I'm not sure if it's better solution. Just an idea. :)

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

First, what does this gain you, in terms of skybox rendering, that the regular depth-test won't?

It depends. If the skybox is a static cube, not much.. as long as you can gaurantee a Z depth that's far enough away that it won't cut into the level. However, if the skybox is actually just a seperate viewpoint of another area of the level (ala Unreal?) the depth test won't work. You'd need to render the full skybox first, or else find a way to mask out the actual level so drawing the skybox won't overwrite it (this is what I'd use the stencil buffer for).

However, the idea of stencil shadows is intriguing, but following this: CarmackOnStencilShadows.txt I can't see how to do it since it seems you need the depth buffer to render from the light's point of view, while you're using it for the camera's.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Krzysztof Kluczek
Member #4,191
January 2004
avatar

No, you just use light position to create shadow volume - a mesh that encloses area which should be in shadow. Depth buffer has to contain geometry from camera point of view. Comparing depth values of shadow volume and map/rendered objects geometry you can decide which pixels lie in shadow volume and leave non-zero stencil values for them. :)

Entire stencil shadows mechanism is nicely described on Gamasutra. :)
http://www.gamasutra.com/features/20021011/lengyel_01.htm

EDIT: btw. Guaranteeing enough Z-distance shouldn't cause much problem since you can move far clipping plane almost to infinity without much loss on Z-buffer accuracy (although more distant positions will have smaller accuracy). :)

Oscar Giner
Member #2,207
April 2002
avatar

Quote:

It depends. If the skybox is a static cube, not much.. as long as you can gaurantee a Z depth that's far enough away that it won't cut into the level.

Just disable depth write. Draw the skybox the first in your scene, no mather the size, and enable depth write again.

Bob
Free Market Evangelist
September 2000
avatar

Quote:

Draw the skybox the first in your scene, no mather the size, and enable depth write again.

And waste all that fillrate?
Nah, draw the skybox last. Setting the depth of the skybox so it's far enough isn't too hard.

--
- Bob
[ -- All my signature links are 404 -- ]

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

Just disable depth write. Draw the skybox the first in your scene, no mather the size, and enable depth write again.

If you disable depth writing, then the scene that the skybox is won't be properly depth-sorted. No, if you want to do it that way, you have to enable depth-writing, draw the skybox, clear the depth buffer, then draw the normal scene, skipping the sky polys. However as Bob said that's a huge waste. I'd prefer to draw the entire level, stenciling the polys that show the sky instead of rendering them, clear the depth buffer, then draw the sky using the stencil buffer as a mask. However that would prevent the use of the stencil buffer for other operations.. though I currently don't have anything else to use it for.

EDIT:
Hmm.. this looks quite interesting/promising: Shadows, Reflections, Lighting, Textures. Easy with OpenGL!

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Korval
Member #1,538
September 2001
avatar

If your skybox isn't a skybox, but geometry at "infinity", then just render it first, clear the z-buffer, and render your regular geometry.

Use of the stencil buffer is a good way to kill a number of depth optimizations.

Quote:

Hmm.. this looks quite interesting/promising: Shadows, Reflections, Lighting, Textures. Easy with OpenGL!

That's some rediculously old stuff. The shadows are projected, the reflections are just the common method of doing planar reflections (ie, render the object under the plane and simply use an alpha blend to draw the plane).

Kitty Cat
Member #2,815
October 2002
avatar

I'm not using the reflections. Yet, anyway. But it was quite easy to implement and works quite good so far. Now, obviously because of its age there's obviously a better way nowadays, for which I'm open to suggestions. Using that article, I was able to throw this together in about 10 to 20 minutes:
http://kcat.strangesoft.net/screenshot.png

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

gillius
Member #119
April 2000

I see lightmaps!

Gillius
Gillius's Programming -- https://gillius.org/

Kitty Cat
Member #2,815
October 2002
avatar

Yes you do!

I've decided to scratch that idea. Bob mentioned it wouldn't scale too well (the more surfaces a shadow strikes and the more lights there are, the more matrices that need to be built) and I suppose I can kinda see that. I was just impressed with how easilly I could incorperated it into my existing code and how good the results were.

I've been researching more ways to handle this, and I've found this (which with my luck is probably the same thing ::) http://developer.nvidia.com/object/robust_shadow_volumes.html It's proving to be quite difficult to understand and implement though.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Go to: