Talk:Shadow volume

Merge request

This page should be merged with the Stencil Shadow Volumes page. —The preceding unsigned comment was added by Staz69uk (talk • contribs) 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)

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)

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)

Spelling

Tim's last name is currently spelled twice as "Heidmann" and once as "Heidemann." Could someone who knows which is correct change the article as appropriate? - Crater Creator 06:34, 25 May 2007 (UTC)

Siggraph 2002

The paper listed here as being "Siggraph 2002" by Everitt and Kilgard was not actually a Siggraph paper: [3] - Nigels (talk) 04:47, 30 May 2008 (UTC)

Games that use this

Do games other than id Tech 4 games use this method of shadowing? I havent seen this as much as Shadow maps. Can we have a list? —Preceding unsigned comment added by 99.246.160.46 (talk) 05:19, 14 March 2010 (UTC)

I recall The Chronicles of Riddick: Escape from Butcher Bay using this method. It seems to predate Doom 3, maybe it could be mentioned for pioneering its use? - 98.207.189.113 (talk) 04:56, 11 April 2011 (UTC)

That Riddick game also had soft shadows on Nvidia GPUs. Anyways... Older games used stencil shadows and some "modern" ones. A few off hand I can think of: FEAR, FEAR2, PhantomCrash, and Silent Hill(3 and 4). And as for a few engines: Unreal used to(still might), C4 Engine, Unity, and ORGE. -Gary 70.41.185.187 (talk) 05:55, 17 May 2012 (UTC)

Use of a stencil buffer for shadow projection and rendering is old -- games used it in real time in the mid to late 1990s regularly (see Quake 2). No, it was not made popular with Doom 3. Doom 3's claim to fame was that it used a single unified lighting step, instead of a set of different ways of approximating the rendering results of several different kinds of lighting that might be present in a scene frame.70.64.32.3 (talk) 03:29, 19 January 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Shadow volume. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://developer.nvidia.com/attach/6832
• Corrected formatting/usage for http://developer.nvidia.com/node/168

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 04:02, 12 May 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on Shadow volume. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://developer.nvidia.com/node/168
• Added archive https://web.archive.org/web/20070208131226/http://www.devmaster.net/articles/shadow_volumes/ to http://www.devmaster.net/articles/shadow_volumes
• Added archive https://web.archive.org/web/20070208132016/http://www.devmaster.net/articles/shadow_techniques/ to http://www.devmaster.net/articles/shadow_techniques
• Added archive https://web.archive.org/web/20031004133623/http://developer.nvidia.com/object/robust_shadow_volumes.html to http://developer.nvidia.com/object/robust_shadow_volumes.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 06:59, 4 September 2017 (UTC)

Non-stencil buffer implementation

I was looking at the article, and it looks to me that it should be pretty trivial to do a shadow volume pass, without using stencil buffer with two passes using more modern shader approach. One can use a normal "color" like buffer (with signed integer or signed float to some extent), and fragment (pixel) shader, and simple additive blending for the buffer, and doing a SINGLE rendering pass with both front and back culling disabling, and emitting 1, or -1 (depending on a normal), inside fragment shader. I guess, it is so simple, that I am sure it must be known and utilized. Would be interesting to know if this is the case, and which title / developer used it first. But I can't really find any material on the matter. 2A02:168:F609:0:4F70:D338:7795:DADF (talk) 22:11, 8 September 2019 (UTC)

Usage of shadow volume in modern game engines

Are there any examples of games engines that use shadow volumes? Aaronfranke (talk) 00:53, 16 July 2020 (UTC)

Deadlink

Hi, just wanted to let you know that the last link to the Inquirer is dead (page no longer exists). Here's the text that was obviously referred to. Since the original source is no longer available, should we include the statement below in the external references page or main text or just drop the reference?

Franco De Bonis, audio sales marketing manager at Creative Labs Ireland, told the INQUIRER: " In our earlier graphics years (1999) we developed a technique for shadowing that is optimized. Recently "id" approached us informing us that they had used this technique in the development of DoomIII and had subsequently discovered that we owned the patent on it.

" Like any company Creative owns a number of technology patents and like any company we need to ensure that our patents are protected. Simply allowing another company to knowingly use a patent you own weakens your position and future claims against infringement. We therefore had to find a legally acceptable way to allow id to use this technique without it being seen as an infringement. The goal was the same from id's perspective".

Ghorwin (talk) 06:10, 21 April 2021 (UTC)

glStencilOpSeparate

Since OpenGL 2.0, usage of the function glStencilOpSeparate allows stencil buffer shadows to take one less pass as geometry can be rendered once with the same result as a back-face and front-face pass. I am unsure of how widely used this method is, as shadow volumes as a whole seem not very common in modern renderers, but I was able to find one example on this GitHub repository at line 221 of https://github.com/WeirdRubberDuck/TSBK03-Shadow-volumes/blob/master/main.cpp (633662cee17f6e22e560bf041a6da435a2aa11f1)

Although minor, this can be considered an optimization. Fekhesk (talk) 21:52, 7 May 2023 (UTC)