5 ms·
Caveat: I'm not a rendering engineer (though I do work in game development), so my knowledge might be a bit out of date or imperfect. It's very clever, and lea
by yoklov 12y ago
Caveat: I'm not a rendering engineer (though I do work in game development), so my knowledge might be a bit out of date or imperfect.
It's very clever, and leads to pixel-perfect shadows. the other main technique used to do real time shadows, shadow mapping, writes them to a buffer, so if you have a larger buffer you get better shadows, and with a smaller buffer you get worse, more aliased shadows (there are techniques to make this harder to notice, though).
Shadow volumes is also typically slower, and puts (more) restrictions on your geometry than shadow mapping, so my experience is that most engines use shadow mapping.
Though, I think I remember one of the rendering engineers saying that shadow volumes is much easier to implement for small engines, and that he's disappointed it isn't more widely used, but I might just be thinking of some other less robust method of stencil-buffer shadowing.
Searching shadow mapping and shadow volumes in Google looks like it leads to good links if you're interested in learning more.
- tsemple 12y agoAnother reason stencil shadows are difficult in a production environment is that any model that casts a shadow needs to be watertight (i.e. a manifold). Models need to have to full geometry for things like hair, thin fins, and grass.
- manolus 12y agoIf a triangular surface has a hole (a cycle of one-triangle-only edges) it's manifold but not watertight.
- oppositelock 12y agoShadow volumes have a number of disadvantages. You have to create geometry for every shadow casting object and for every light source for which it casts a shadow, this is a lot of geometry and a lot of CPU overhead, so you generally used them for static lights and only shadowed moving objects that crossed the light cone. These days CPU doesn't matter as much, but back in 2000 it was a big deal. It was hard to solve the problem in a general way, and you ended up asking your modelers to tag which objects could be shadow casters, which could be shadow receivers, and which lights corresponded to the shadows. Shadow maps are faster and compounding shadows is much easier. What you do is render the subset of the scene that you want casting shadows from the point of view of each light source that you want casting shadows, and then render the entire scene once for each light, using the shadow map to kill fragments that aren't illuminated. Back in the late 90's and 2000, you could potentially have one, maybe two shadow maps. The downside is resolution, but you can play tricks with the projection matrix to bias the pixellation artifacts into more distant areas. Pre-computed shadow volumes were awesome for static lights, where you didn't have to pay the geometry compute overhead every frame, and shadow maps were awesome for things like flashlights and moving lights, since they allowed moving the shadow compute complexity to the GPU. When the Riva TNT2 came out, and you could multi-texture, shadow map performance doubled. Lighting is hard! If you have 2 shadow-map shadow casters, and one shadow volume, you're rendering the scene at least 5 times and the shadow volume twice, using the geometry processor to kill front or back sides from the point of view (can't pre-compute this). (I've been working on this stuff since the 90's. SGI was doing this stuff years before games, but it just wasn't well known because nobody could afford those damn things, it took cheap 3D commodity hardware to make this work really fun, well, minus the whole thing about it sucking to work in the games industry.)