 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| The Theory of Stencil Shadow Volumes |
|
 |
Taharez GDNet+ Member since: 6/18/2000 From: Stockholm, Sweden |
|||
 Posted - 12/3/2002 5:11:23 AM |
||||
| This is exactly the type of articles I'd like to see more of; explaining a specific common feature with pros and cons for differrent methods of implemention. I've never done shadows myself, but now I'll definatly put it up as a future project :D A question for the gurus, considering the negative aspects of both the mentioned techniques, how feasible is it to create a system that switches between the two depending on situation? |
||||
|
||||
|
elis-cool Member since: 1/11/2002 From: Palmerston north, New Zealand |
|||
 Posted - 12/3/2002 5:23:06 AM |
||||
| Yeah definatly a great article. |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
|
Posted - 12/3/2002 5:44:58 AM |
||||
| Thanks for the kind words. A hybrid of the two technique is very much the ingredients of an efficient AND robust implementation. Yes it is very feasible to do such a hybrid. The switch would not be noticeable at all since both technique depends on per fragment stencil testing. It would speed up ur implementation a lot. As its quite obvious, the article is getting longer, wordier and i'm bogged down with too many paragraphs trying explain some of the concepts. I wanted this to be a "gateway" or "startup guide" for ppl to start implementing shadow volumes and its not meant to be totally exhaustive. Hence, i decided to omit the details of such a hybrid implementation as it would probably need many more paragraphs to explain exhaustively. Refer to Eric Lengyel's article at gamasutra network, it describes the near-clip volume and scissor rectangle in great details while i gave only passing comment. Sorry about that. ______________________________________________ (MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting() http://www.geocities.com/codeman_net/ |
||||
|
||||
|
Taharez GDNet+ Member since: 6/18/2000 From: Stockholm, Sweden |
|||
|
Posted - 12/3/2002 1:16:16 PM |
||||
I thought your article was very nice as it is, I just got curious about the idea of combining the two, absolutly no critique intended. As I said I'm a total noob with shadows, so thanks for the reply  |
||||
|
||||
|
Mark J Kilgard Member since: 12/4/2002 From: USA |
|||
|
Posted - 12/4/2002 4:05:26 AM |
||||
| This is a good article, but it makes a few technical claims that I'd like to comment on. Anyone interested in this topic should review Eric Lengyel's article on shadow volumes on gamaustra.com; Eric does a great job covering the related math topics very well. This article says: > Future GPUs would be expected to support two-sided stencil testing, which will allow us to render the front and back faces of shadow volumes together. This would effectively halve our fill rate cost of rendering the shadow volume. This is not true. The number of pixels rasterized and updated is EXACTLY the same with two-sided stencil testing (ie, using OpenGL's EXT_stencil_two_side extension) as the number of pixels rasterized and updated with two stenciled shadow volume passes, one culling back-faces, the other culling front-faces. What is halfed is the polygon setup overhead, vertex transformation overhead, and transfer overhead from sending the shadow volume geometry twice through the graphics pipeline. If rasterization was the limiting factor, two-sided stencil testing would be no faster than rendering two passes with appropriate face culling. But in fact, rasterization is not completely the limiting factor. There is application and driver overhead from sending the geometry twice and there are often sequences of multiple culled polygons that can allow the rasterizer to go idle. Also, transform overhead can be an issue if all the polygons are sent as indendent primitives. The article also recommends sending degenerate triangles inserted between polygon edges. Yes, this allows you to leverage vertex programs for the possible silhouette edge detection, but is also quite inefficient compared to performing possible silhouette edge detection on the CPU. Consider that a model with N polygons requires 3*N potentially degenerate triangles to be added to the rendering. Since most of these triangles are degenerate, that's a LOT of wasted work. A good rule of thumb is that the number of possible silhouette edges is roughly proprotional to sqrt(N). Sending 3*N polygons to avoid sending O(sqrt(N)) polygons is a bad algorithmic trade-off. I suspect the performance, particularly if you have multiple lights, will be better doign possible silhouette edge detection on a fast CPU rather than attempting to do it with vertex programs on the GPU. For the record, Doom3 performs possible silhouette edge detection on the CPU. There are still some clever ways to use vertex programs but they are better used as an assist rather than attempting to perform the entire possible silhouette edge detection by inserting degenerate triangles. Hopefully, Cass Everitt or I (probably Cass) will be presenting these techniques at GDC. - Mark Kilgard NVIDIA Corporation |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
|
Posted - 12/4/2002 4:44:40 AM |
||||
| Hi Mark, Thanks for pointing out the mistakes and providing the extra info. Are there any place where i can get hold of specs/info regarding next gen hardware (e.g. nv30) on the internet? The fill rate savings on double stenciling went into my head when i read an article at ExtremeTech many months back, but i have no alternative source to answer my questions. Sorry about that. Yes, using degenerate geometries is probably not recommended when the occluder polycount is high and there are multiple shadow casting light sources. However, i have not got hold of any statistical data on what is the "breaking point" polycount or number of lights before vertex program implementation lags behind cpu-based calculations. For my own tests, which are usually low poly models used in games, vertex program implementations are always better. But, i wholly agreed with your view that vertex program implementation would lose out when we up the number of lights. Wow, ur info about Doom3 doing silhouette calculation on the cpu stunned me. The fact that John is moving towards "more passes" and "less triangles pushing" made me suspect that he would be doing all the silhouette calculations on the programmable pipeline for newer cards... Yes, i would be looking forward to Cass and your work at the GDC. Your past presentations have been a great source of technical knowledge to me. - Hun Yen Kwoon [edited by - flipstar on December 9, 2002 8:50:56 AM] |
||||
|
||||
 |
Myopic Rhino Staff Member since: The dawn of time
From: Temecula, CA, United States |
|||
 Posted - 12/4/2002 1:49:41 PM |
||||
Hey Mark, nice to see you post here.  Dave "Myopic Rhino" Astle Executive Producer and COO, GameDev.net Game Programmer, Avalanche Software Author, OpenGL Game Programming "Leaking and bleeding... that's what happens when you don't relax" |
||||
|
||||
|
Mark J Kilgard Member since: 12/4/2002 From: USA |
|||
|
Posted - 12/4/2002 7:56:32 PM |
||||
| Yen Kwoon, Hun, > Are there any place where i can get hold of specs/info regarding next gen hardware (e.g. nv30) on the internet? Yes, for information about OpenGL support for the NVIDIA CineFX Architecture (NV30), check out the nv30specs.pdf document at http://developer.nvidia.com/view.asp?IO=nvidia_opengl_specs It includes the EXT_stencil_two_side specification and other extensions. Note that the latest NVIDIA drivers for GeForce GPUs include a special emulation mode so you can write applications in expectation of NV30 today. Keep in mind that the emulated features are performed in software so are quite slow. This includes the EXT_stencil_two_side functionality. Also, learn about the Cg language. It is the easiest way to take advantage of NV30. Because the Cg language is fully compatible with Microsoft's HLSL language that comes with DirectX 9, Cg is a great multi-API, multi-platform tool for taking advantage of NV30. > For my own tests, which are usually low poly models used in games, vertex program implementations are always better. I agree that for low polygon count models, using degenerate triangles may be just as fast. But once you start having higher polygon count models, that not likely to hold up. And you magnify the inefficiency when you have lots of lights. The idea is "cool" because you totally offload the silhouette determination from the CPU onto the GPU. Ultimately, game developers should evaluate either approach based on performance. - Mark Kilgard NVIDIA Corporation |
||||
|
||||
|
Darrell L Member since: 9/29/2002 |
|||
|
Posted - 12/4/2002 9:48:22 PM |
||||
| This article couldn't be more timely for myself. I've waded through all the material I could get my hands on concerning these techniques. But this article, IMHO, did a better job of presenting all "gotchas" that must be considered. Thank you Yen Kwoon, Hun and GameDev.net. |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
|
Posted - 12/4/2002 10:27:35 PM |
||||
| Thanks for the response. Yes, there are a lot of papers on this topic but its like a big puddle of mud to wade thru. Hopefully i have provided a basic introduction to implementing shadow volume esp. using D3D api. But do take note of Mark's assessment on the potential inefficiency of vertex shader implementation. I'm in the process of confirming that myself. Lengyel's article is a must read as the mathematical derivations are pretty general and porting it to D3D is not a problem. Hopefully i can find the time to update the article with newer information and maybe even implementation issues using DX9. Thats provided Dave would want to update it. *hint* - Hun Yen Kwoon [edited by - flipstar on December 9, 2002 8:51:29 AM] |
||||
|
||||
|
Myopic Rhino Staff Member since: The dawn of time
From: Temecula, CA, United States |
|||
|
Posted - 12/4/2002 11:44:42 PM |
||||
quote:Yep. Dave "Myopic Rhino" Astle Executive Producer and COO, GameDev.net Game Programmer, Avalanche Software Author, OpenGL Game Programming "Leaking and bleeding... that's what happens when you don't relax" |
||||
|
||||
 |
ChrisE Member since: 7/15/1999 From: London, Canada |
|||
|
Posted - 12/7/2002 1:40:59 PM |
||||
| "One example of such hybrid implementation is the Power Render X [16] game engine that generates shadows using shadow volumes and then fade out the shadows with respect to distance from the occluder by using the occluder's shadow maps." I would like to correct this statement. PR-X does not use any shadow maps in the current engine. They were used in early prototypes but were replaced by shadow volumes. The hardware support for shadow maps just isn't there yet. ATI and Matrox cards still don't support it, and shadow maps had some serious jaggy problems. PR-X does combine shadow volumes with projected textures and uses 3D textures for attenuation. The rendering techniques are almost identical to Doom3 as far as I can tell. Chris www.powerrender.com |
||||
|
||||
|
AxoDosS Member since: 4/18/2002 From: Stockholm, Sweden |
|||
|
Posted - 12/7/2002 3:03:05 PM |
||||
| How does Doom 3 "fade" the shadows so that when they are in a light you dont see the shadows (get brighter)? Another thing. From the screen shots it looks like if Doom 3 only uses projective lights. Maybe they render the shadows to the stencil buffer then pass in the light and clear the stencil (or add some value) where the light hits a shadow. In other words: 1. draw shadow volumes 2. draw light volume and for each point that is equal to 1 replace it to 0. Or do they use some other method, I do not know of? Im just a noob asking =) [edited by - axodoss on December 7, 2002 3:04:32 PM] |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
|
Posted - 12/9/2002 8:48:29 AM |
||||
quote: Yes, i mixed up the prototype's implementation. It will be corrected. *Hint to Dave* - Hun Yen Kwoon Some graphics company... [edited by - flipstar on December 10, 2002 10:17:33 AM] |
||||
|
||||
|
ChrisE Member since: 7/15/1999 From: London, Canada |
|||
|
Posted - 12/10/2002 3:26:50 PM |
||||
| "How does Doom 3 "fade" the shadows" Use per pixel attenuation with textures, and add light masked by shadows, rather than darken areas in the shadow. It's not the shadows that fade, since pixels in a shadow aren't drawn at all. |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
|
Posted - 12/11/2002 12:37:58 AM |
||||
quote: Makes perfect sense. Scene gets shadowed without redundant fillrate-wasting. - Hun Yen Kwoon Some graphics company... |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
 Posted - 1/23/2003 9:23:18 PM |
||||
| Hi all, I have an updated copy of the article with me. It contains certain minor technical changes and if anyone of you wants it, just drop me a mail. There will also be a much more extensive article on the subject in the upcoming ShaderX2 book. Of course, shader implementation will be explained fully. - Hun Yen Kwoon [edited by - flipstar on January 25, 2003 12:01:36 PM] |
||||
|
||||
|
flipstar Member since: 8/23/2002 From: Singapore, Singapore |
|||
|
Posted - 5/7/2003 6:07:56 AM |
||||
| Hi all, Thanks to Dave, the online article at GameDev had been updated. So dun mail me for the latest article anymore!! Any comments are still welcomed thro. - Hun Yen Kwoon |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
