What kind of lighting should I use?
Author
I'm starting a new game project that is totally based around light. There will be crystals, mirrors, lights, and light beams all over the place. I immediately think of deferred rendering because I hear it works well with lots of lights. Since I've never done a graphics engine with lighting and shaders before, I figure it'd be best to ask before I get shoulder-deep in the wrong method.
Thanks!
Deferred rendering is generally more efficient for large numbers of lights and decouples shading from lighting to some extent which can make for a simpler engine. The two major disadvantages are limited flexibility in the types of shading effects you can achieve (any material/shading effects dependent on lighting, like anisotropic materials, are difficult to achieve with deferred shading) and inability to handle translucency.
Many of the examples of light related effects you give are not really anything to do with 'lighting' in a graphics engine. Crystals (reflection/refraction), mirrors (reflection) and light beams (volumetric effects) are not effects that are really dependent on how your engine handles lights. In the case of refraction and volumetric effects you will almost certainly need to use forward rendering for those elements of your scene since most possible ways of achieving them won't work in a pure deferred renderer. Most games that use deferred rendering are really 'hybrid' renderers since they use forward rendering for elements of the scene that can't really be done by a deferred renderer.
Many of the examples of light related effects you give are not really anything to do with 'lighting' in a graphics engine. Crystals (reflection/refraction), mirrors (reflection) and light beams (volumetric effects) are not effects that are really dependent on how your engine handles lights. In the case of refraction and volumetric effects you will almost certainly need to use forward rendering for those elements of your scene since most possible ways of achieving them won't work in a pure deferred renderer. Most games that use deferred rendering are really 'hybrid' renderers since they use forward rendering for elements of the scene that can't really be done by a deferred renderer.
Author
Alright, so I should look into doing both. Which should I implement first? Consider things like volumetric lights and refraction can be faked ( actual geometry for the light beams, and refraction done in game logic ) should I do the deferred renderer first?
Light beam geometry will need to be translucent so can't be done with a deferred renderer. Refraction as a material effect is usually done by rendering the non-refractive parts of the scene and then using the back buffer as a texture when rendering the refractive elements with the UVs distorted to fake a refraction effect. That also means forward rendering. If you're talking about refraction as a gameplay element (a light beam being bent by a prism say) then that's not really a graphical effect at all and doesn't really depend on your renderer but translucent laser/light beams will likely need to be forward rendered.
Even if you decide a deferred renderer is appropriate for the majority of the opaque objects in your scene you're going to need a forward renderer for the scene elements that can't be handled by a deferred renderer so I'd suggest starting with the forward renderer.
Even if you decide a deferred renderer is appropriate for the majority of the opaque objects in your scene you're going to need a forward renderer for the scene elements that can't be handled by a deferred renderer so I'd suggest starting with the forward renderer.
Author
How hard is it to combine the two? And what, if any performance hit will there be with both? Also, what precisely makes transparencies not work with deferred rendering?
A gbuffer is essentially flat, in that it has no concept of 3D, or of layers.
Take a simple example of a transparent sphere in a room.
You draw your room into the gbuffer first, and then you draw the sphere into it second, the sphere's attributes (normals, specular attributes, etc) overwrite those of the parts of the walls it occludes. Since it's transparent you still need the attributes of the wall behind for your scene to appear correctly.
There are two approaches to getting around this, the most common is to deferred everything you can, apply your lighting and whatever else, then forward render any transparent objects into the scene afterwards (you may need to restore your depth buffer for this to work correctly).
Another approach is called deep deferred shading, where you have a gbuffer which has a concept of layers, about 2 or 3, so you can store transparent objects within it. Although this vastly increases the memory cost, but it is an idea worth at least thinking about, there is a demo here.
Take a simple example of a transparent sphere in a room.
You draw your room into the gbuffer first, and then you draw the sphere into it second, the sphere's attributes (normals, specular attributes, etc) overwrite those of the parts of the walls it occludes. Since it's transparent you still need the attributes of the wall behind for your scene to appear correctly.
There are two approaches to getting around this, the most common is to deferred everything you can, apply your lighting and whatever else, then forward render any transparent objects into the scene afterwards (you may need to restore your depth buffer for this to work correctly).
Another approach is called deep deferred shading, where you have a gbuffer which has a concept of layers, about 2 or 3, so you can store transparent objects within it. Although this vastly increases the memory cost, but it is an idea worth at least thinking about, there is a demo here.
Author
Kind of sucky. I have a couple other questions: What kind of shadowing is used with deferred rendering usually? Also, what limitations do I have with dx9 and dx10? My program will need to run on dx9.
Your choice of shadowing algorithm is pretty much independent of your choice between a forward or deferred renderer. Pretty much everyone uses shadow maps these days, stencil shadows are rarely used any more. There are many variants on the basic shadow mapping algorithm that attempt to work around some of the problems of the basic shadow mapping approach but they're all compatible with either forward or deferred renderers.
Another issue with deferred rendering that I didn't mention is that it is not really compatible with multi sample anti-aliasing. DX10 allows you to independently read from the separate sub-samples in an anti-aliased buffer which means you can work around some of the issues but with DX9 you can't really use MSAA with a deferred renderer.
Another issue with deferred rendering that I didn't mention is that it is not really compatible with multi sample anti-aliasing. DX10 allows you to independently read from the separate sub-samples in an anti-aliased buffer which means you can work around some of the issues but with DX9 you can't really use MSAA with a deferred renderer.
Author
Is there a method of shadowing that works will with a lot of point lights? From what I'm seeing, it becomes very costly to do shadow maps with point lights.
Quote:
Is there a method of shadowing that works will with a lot of point lights? From what I'm seeing, it becomes very costly to do shadow maps with point lights.
Dynamic shadows are still a very hardware hungry topic. If you want to use many pointlights, all with shadows and decent fps, then you have to stick to some pre calculated approach (lightmaps).
Well, having shadows for all lights would be perfect, but on the other hand, it is sometimes enough to have many point lights (10-50) and just one or two "fake" shadows. This will not be "correct" but it is still good looking, and good looking is more important in a game than physical correctness :)
Many modern games has only one or two shadow casting light sources (i.e. sun in an outdoor scene) and many shadowless pointlights (muzzle fire, explosions).
CG movie makers work with fake shadows too(if I'm correct, there's an article about lighting in monster ag in GPU GEMS 1).
--
Ashaman
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
