This article is within the scope of WikiProject Computer graphics, a collaborative effort to improve the coverage of
computer graphics on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Computer graphicsWikipedia:WikiProject Computer graphicsTemplate:WikiProject Computer graphicscomputer graphics articles
This article is within the scope of WikiProject Video games, a collaborative effort to improve the coverage of
video games on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Video gamesWikipedia:WikiProject Video gamesTemplate:WikiProject Video gamesvideo game articles
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.
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. -
Rainwarrior22:42, 24 July 2006 (UTC)reply
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 Roets14:14, 2 September 2005 (UTC)reply
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 Lengyel06:02, 26 October 2006 (UTC)reply
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.
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?)
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.
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 Creator06:34, 25 May 2007 (UTC)reply
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)reply
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)reply
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:
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.
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:
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.
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)reply
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".
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)