My video card reports being able to support ~3300 dynamic lights. However, after adding my 8th light, no other lights from then on are shown (though smgr->getDynamicLights() reports the right amount). I've been searching through the source and the forums (which is mad more difficult by the fact that the number "8" appears in DirectX), but I can't see anything where the maximum amount of lights is set to 8.
Is there anything I'm doing wrong?
Only 8 Dynamic Lights?
Okay, well, now that I've shown off my obvious newbness, what is the standard workaround? Create a bunch of lights and only "enable" the ones that are within "range" as you move through your scene or do usually end up having a few large white lights and just being creative w/ materials? I know there's a bit of creative interpretation here--and that the "answer" is probably a combination of both--but just curious...
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
IIRC light management is a planned feature in Irrlicht, in way that it allows you to define as many as you like and only chooses the 8 nearest to the model being rendered. But such a solution has its limits of course.
So long, do the management on your own, the way you proposed it is sound for the beginning, but you should consider using static lighting, for instance using lightmaps. This way you can prerender light, which is much more beautyful than dynamic lighting can ever be, but can only be applied to static elements in the scene and can't change at runtime. You then need to place dynamic light cleverly, so that dynamic elements (chars, monsters, etc) are lit accordingly in statically lit places. Turning these lights on/off during runtime is a feasable task.
Getting an atmospheric lighting is something one has to try out and tweak. It depends much on what you are exactly doing for a project. A cute jump'n run is lit differently from a horror game and outdoor lighting is different from indoor lighting.
So long, do the management on your own, the way you proposed it is sound for the beginning, but you should consider using static lighting, for instance using lightmaps. This way you can prerender light, which is much more beautyful than dynamic lighting can ever be, but can only be applied to static elements in the scene and can't change at runtime. You then need to place dynamic light cleverly, so that dynamic elements (chars, monsters, etc) are lit accordingly in statically lit places. Turning these lights on/off during runtime is a feasable task.
Getting an atmospheric lighting is something one has to try out and tweak. It depends much on what you are exactly doing for a project. A cute jump'n run is lit differently from a horror game and outdoor lighting is different from indoor lighting.
Re: Only 8 Dynamic Lights?
cubicool wrote:My video card reports being able to support ~3300 dynamic lights.
What kind of card is that? Without the use of shaders I thought it would be possible to use up to 8 hardware lights, but ~3300?I think it's possible to use such an amount of dynamic lights with the use of shaders which you have to implement by yourself.
Regards - Xaron
Last edited by Xaron on Sat Feb 04, 2006 11:09 am, edited 1 time in total.
I'm lightmapping my scene and then I might use that light manager idea to light my characters to make them match the surroundings (8 closest lights ect).
Also, how do you write a light shader? is it vertex or fragment? what does it have to do? (input and output, types, how difficult to write ect.)
Also, how do you write a light shader? is it vertex or fragment? what does it have to do? (input and output, types, how difficult to write ect.)
pushpork
-
Baal Cadar
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Light shaders only really make sense as fragment shaders, because vertex lighting is already done in fixed function and there is little room for improvement here and it won't get much prettier, since it would be still interpolated over the faces of the mesh. But vertex shaders are used to deliver certain informations to the pixel shader, so they are used in support to the fragment shader that then does the actual lighting.
Fragment shaders are able to do per pixel lighting, meaning to solve the lighting equation for each pixel seperatly. Most newer cards can do per pixel lighting in fixed function too.
You use a shader, if you want to have something the standard Blinn/Phong lighting model can't do. Normal mapping, or subsurface scattering (for things like skin or milk) and generally to simulate special material properties.
To write a shader is very simple language wise. But you have to know what you're doing of course. Meaning, you need to know how lighting works (Blinn/Phong lighting model, BRDF are good keywords for looking this up)
Without a *very good* grasp of the mathematics behind 3d and behind lighting I wouldn't bother really.
Input depends on the shader. It usually is one ore more interpolated texture coordinates, in GLSL material informations too and of course output of the vertex shader.
Output of a fragment shader is the colour of the pixel currently computed and sometimes a depth value.
A very good GLSL shader tutorial is this one: http://www.lighthouse3d.com/opengl/glsl/index.php?intro
It also has a few simple per pixel lighting examples and explains them thoroughly.
Fragment shaders are able to do per pixel lighting, meaning to solve the lighting equation for each pixel seperatly. Most newer cards can do per pixel lighting in fixed function too.
You use a shader, if you want to have something the standard Blinn/Phong lighting model can't do. Normal mapping, or subsurface scattering (for things like skin or milk) and generally to simulate special material properties.
To write a shader is very simple language wise. But you have to know what you're doing of course. Meaning, you need to know how lighting works (Blinn/Phong lighting model, BRDF are good keywords for looking this up)
Without a *very good* grasp of the mathematics behind 3d and behind lighting I wouldn't bother really.
Input depends on the shader. It usually is one ore more interpolated texture coordinates, in GLSL material informations too and of course output of the vertex shader.
Output of a fragment shader is the colour of the pixel currently computed and sometimes a depth value.
A very good GLSL shader tutorial is this one: http://www.lighthouse3d.com/opengl/glsl/index.php?intro
It also has a few simple per pixel lighting examples and explains them thoroughly.