Talk:Shadow volume

From Wikipedia, the free encyclopedia

[edit] Merge request

This page should be merged with the Stencil Shadow Volumes page. —The preceding unsigned comment was added by Staz69uk (talkcontribs) 23:41, 29 May 2005.

Disagree. Stencil shadow volume is only one kind of shadow volumes (among some other implementations available). --Fredrik Orderud 13:24, 27 July 2005 (UTC)
MERGE I also think we should merge this with the Shadow volume article. However, it should be done by someone who has a clear understanding of the subject matter. —The preceding unsigned comment was added by Ayavaron (talk • contribs) 20:26, 24 July 2006 (UTC) (From Talk:Stencil shadow volume)
I've done the merge. Most of the article that was here duplicated material that was done better on the stencil volume page. The most common implementation of shadow volumes is with stencils, and it is better to group the articles together on one coherent page rather than to have one stub point to another. - Rainwarrior 22:42, 24 July 2006 (UTC)

Merge completed from Stencil shadow volume and Carmack's Reverse, by Rainwarrior 22:59, 24 July 2006 (UTC)

[edit] The diagram could be better

We should have one diagram with the scene containing the 4 objects and a second diagram with the shadow volume (in this case it would be 3 disjoint shapes). The eye position should not be shown because the shadow volume is independant of it. -- Nic Roets 14:14, 2 September 2005 (UTC)

[edit] Editing 25 October 2006

I've copied this message from my user talk page, as I think the discussion properly belongs here:

In response to the comments in your recent edits:
1. there is such thing as non-polygon shadow volumes, 2. w=0 doesn't work on a lot of hardware, 3. capping is required in all methods for robustness, not just depth fail.
All three of these statements are incorrect. No one draws shadow volumes in any practical situation without polygonal data, w=0 works on all hardware (if you don't understand why, then I'll explain), and capping is only necessary when using depth fail (ibid). See my Gamasutra article or my book for details. Also, why did you delete many of the facts that I added to the article? Eric Lengyel 06:02, 26 October 2006 (UTC)

1. If by practical you mean "realtime", I would agree, but there are other applications than realtime. I've seen shadow mapping used in raytracing applications, which are definitely not limited to polygonal surfaces. ([1] and [2], for instance)

2. I thought I've seen cases where polygons were discarded (rather than properly clipped) in the case where w=0, but I could be mistaken. I'll take your word for it that it works on all hardware, but I'll have to take a closer look at it myself. If you'd like to explain it, I'd welcome the explanation, as I don't know how clipping of coordinates with w=0 works at the hardware level. (I know how to accomplish it, mathematically speaking, but it was my belief that at least some hardware doesn't handle it properly because I thought I'd seen problems with it.)

3. If you don't put a front-cap on a depth pass shadow volume, you get the well known problem where the camera is inside shadow. Why would capping be unnecessary for depth pass?

I don't think I removed much of your added information. In many cases I rearranged sentences to make them shorter, but I don't really think of this as removing any thing. In other cases I thought you had removed simpler explanations in favour of more technical (closer to the implementation details) ones, and in those cases I tried to restore some of the original explanation and integrate into it those details you had added.

As for outright removals, I removed the term "shadow acne", because the term isn't applicable to shadow volumes (it should probably be mentioned at shadow mapping though). I also removed the reference to a specific GeForce card, as that kind of technical detail isn't very useful.

-- Rainwarrior 06:38, 26 October 2006 (UTC)

1. Since the shadow volume algorithm is based on rasterization into a stencil buffer, non-polygonal geometry doesn't really apply. I've never heard of anyone trying to use shadow volumes with any other kind of surfaces, but if you can find a reference, I'd be intrigued.
2. The important thing to realize is that w=0 in object space only. After multiplying a vector (x,y,z,0) by the projection matrix, the w-coordinate is no longer zero, so the hardware has no problem with it.
3. The depth-fail technique is not meant to be used 100% of the time for a single scene. What you do is detect whether it's possible for the shadow of a particular geometry to intersect the near plane. If it is possible, then you use depth-fail with capping. Otherwise you use depth-pass without capping (and caps wouldn't make any difference in this case). This provides the best of both worlds (speed vs. robustness), while only trading speed for robustness when absolutely necessary.
As for shadow acne, I was just making a comparison between the different artifacts observed with shadow volumes and shadow maps. But you removed the description of artifacts pertaining to shadow volumes as well. (Why?)
Eric Lengyel 07:12, 30 October 2006 (UTC)
1. Well, I gave two references above. There are possible speed increases when applying the shadow volume concept to raytracing applications. There are many different ways to go about the shadow volume problem (even if limited to a stencil buffer implementation), and I don't think this article should go too far into the details for that reason (there's too much to cover, and it all overlaps). We've got plenty of external links to articles like yours which do a fine job for a reader looking for that specific kind of information. (The external links section could use more thorough descriptions of the links.)
2. Yes, that makes sense, and after taking a closer look at the behavior of my graphics card, points at infinity seem to clip reasonably as well. (And after reading your article, I find the infinite-frustum idea very interesting. I was surprised by the idea that extending it to infinity wouldn't affect depth resolution very much.) I had misremembered something else when I made my earlier comment, I suppose. Despite this, though, I still think the change I made was reasonable there. I'll explain in a moment.
3. I may have been using the word "cap" to refer to the plane that covers the exposed open edge of the hollow volume at either clipping plane. In the case of either depth fail or depth pass, this kind of "cap" produces a volume that is closed at the end where it is to be counted. Your implementation with an infinite-frustum makes the capping problem tricky for depth-pass, and I find your suggestion of a switch between both modes quite interesting.
I think, though, that this gets away from the shadow volume concept and is instead about optimization of the implementation. W=0 puts part of the extrusion calculation into an existing part of the rendering pipeline, and the infinite-frustum accomodates that. The switching between depth pass and fail tests avoids the cost of capping. These are all optimizations; they're not really part of the shadow volume concept itself. You seem to have a lot of experience with optimizing these things for hardware, and this particular implementation seems to me to be very good, but I don't think these details belong inline with the wikipedia article because they aren't inherantly part of the shadow volume problem (and as I've said, there are many ways to use shadow volumes, some subtly different, some very different). I would propose a separate section in the article with the heading "optimization" which deals with these particular details, rather than trying to turn this particular article into a how-to for one particular implementation.
4. Ah, I had removed the phrase "they often suffer from faceting artifacts along the silhouettes of shadow-casting models". I might not have noticed it when I was altering things. I don't think the statement itself is very explanatory, though. What artifacts? Why? It requires more than a passing reference to be understood. If we had that statement with a "see below" and discussed this artifact problem in the article, it would have a lot more meaning.
-Rainwarrior 17:31, 30 October 2006 (UTC)