 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Shadows |
|
 |
MSkinn99 Member since: 8/25/2000 From: USA |
|||
 Posted - 2/8/2001 5:48:55 PM |
||||
| Come on you guys, feel free to give me feedback on the article, that is what this forum is here for. Thanx -MSkinn99 What's done is done (Until you hit Undo)  Two wrongs don't make a right; but 3 lefts do. You'd be paranoid too if everyone was out to get you. Yet another game programming web page... |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 2/10/2001 10:37:02 AM |
||||
| The odd/even approach will not work if there are some shadow volumes _partially_ overlapped with others. thus it require an expensive process to "union" all shadowvolume before they being drawing to the stencil buffer. to avoid this "union" process, we have to use "counting in/out" of the shadowvolume. (the one used in DXSDK example). but it will massively increase the memory bandwidth requirement as a lot more stuff need to draw in the stencil buffer. clipping. it seems there is no (published, good, can be done in object/camera space) algo to properly cap the shadow volume once it is clipped by near clip plane. (I haven't found one yet). if ONLY the shadowvolume being clipped, things are much easier. the problem comes in when the object that cast shadow also _partially_ clipped by the near clip plane. Things turn more complicated when the shadow cast object is a non-convex object. so far, i get around this by disable the shadow if any of this case happened. (until I found a good algo that can solve the problem, that is) |
||||
|
||||
|
MSkinn99 Member since: 8/25/2000 From: USA |
|||
|
Posted - 2/11/2001 9:40:22 PM |
||||
| The easiest way to solve this problem is to determine whether you are going into or out of the shadow volume. You can just use the normal of the shadow volume quad to determine if you are entering or exiting the volume. If the polygon is a backface(normal away) you are exiting, otherwise you are entering. You increment for every one you enter and decrement for every one you exit. If you are in a shadow volume, you would just trigger an error if the value of the stencil buffer was less than 0 and return the stencil buffer value to 0. When all of this is done, if the stencil buffer is greater than 0, the point is in shadow. If the stencil buffer is equal to 0, then the point is not in shadow. -MSkinn99 What's done is done (Until you hit Undo) Two wrongs don't make a right; but 3 lefts do. You'd be paranoid too if everyone was out to get you. Yet another game programming web page... Edited by - MSkinn99 on February 11, 2001 9:42:16 PM |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 2/12/2001 4:43:22 AM |
||||
| hmm.. not quite the same as my problem.. determine whether the near clipplane clip teh shadow volume is rather easy, just check the "clip status" after draw the shadowvolume will do. my problem is once we found out the shadowvolume is clipped, how should we deal with it. the idea of inside or outside a shadowvolume is not correct IMHO, becasue the near clip plane is not a single position (vector), its a plane. so there is some cases the plane clip the shadow volume while the eye point (camera position) still outside the shadow volume. In other words, part of the near clip plane is inside the shadow volume and the rest is not. in such senerio, we need to "cap" the shadow volume. things turn nasty when the object which casting the shadow also clipped by the near plane, this will make it impossible to clip in an easy(fast/efficent) way. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 2/12/2001 4:46:06 AM |
||||
quote: I mean, make it hard to "cap" the shadowvolume.. doh! |
||||
|
||||
|
MSkinn99 Member since: 8/25/2000 From: USA |
|||
|
Posted - 2/12/2001 11:18:19 AM |
||||
| Don't worry about capping the volume. Just count in & out shadow planes via the normal. If the stencil buffer value ever goes below 0 just reset it because you started in the shadow volume. -MSkinn99 What's done is done (Until you hit Undo) Two wrongs don't make a right; but 3 lefts do. You'd be paranoid too if everyone was out to get you. Yet another game programming web page... |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 2/12/2001 7:55:49 PM |
||||
| then the shadow will not look correct if part of the shadowvolume clipped. because the portion that clipped will not update the stencil buffer, result to an incorrect enter/exit count in part of the screen. if the eye position and the near clipplane both "inside" the shadow, then pixel in the stencil buffer will get -1, in such case, a lot of other objects in the scene will not shadow correctly. of course, we could ignore the -1 in such case because we know the whole near clipplane is inside the shadow. but what if the clipplane is not complete inside the shadow?, we can't simply ignore the -1 in the whole screen, because some part of the screen will still update correctly by the shadowvolume's front face. |
||||
|
||||
|
MSkinn99 Member since: 8/25/2000 From: USA |
|||
|
Posted - 2/12/2001 10:01:39 PM |
||||
| First of all, if we ever got a -1, we would reset it to 0 before we were finished tracing through all of the planes. We count front back faces on a line from each point on the screen(near clip plane) to the point being drawn. Second, the stencil buffer works for every pixel on the screen, and then resets after we are done rendering. Like this: S - Shadowed L - Not Shadowed Stencil Buffer: 20110201 01011010 02010221 01211001 Screen: SLSSLSLS LSLSSLSL LSLSLSSS LSSSSLLS For every place the stencil is 0 there is no shadow, everywhere else there is a shadow, maybe more of a shadow if there is a value higher than one. YOU DON'T NEED TO CLIP THE SHADOW VOLUME! -MSkinn99 What's done is done (Until you hit Undo) Two wrongs don't make a right; but 3 lefts do. You'd be paranoid too if everyone was out to get you. Yet another game programming web page... |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 2/13/2001 8:12:29 AM |
||||
| what i mean "-1" in the above msg is reduce by one, rather than "negative one" hmm.. ok.. imagine this case: You are standing on the ground, and you can see the ground in your view. And there is a big box hanging above your head. or whatever it is, think of somthing big, or better, think its like a bridge kinda size. and the sun is shine above you and that box, in other word, you are standing _inside_ the shadowvolume. ok. so we draw this shadowvolume, since we are complete inside the SV, only the back face will draw to the stencil buffer, which means "reduce by one" in the stencil buffer. As such, it will result to "-1" (negative one) in the stencil buffer. So, following your suggestion, we reset every thing that is "-1" back to "0", ok, then after drawing the shadowvolume, the whole stencil buffer still "0" which means there is no shadow at all in the view. (as long as we don't draw other object, just to keep the discussion simple) but in the actual correct scene, shouldn't we see part of the shadow on the ground?? where is that shadow gone? |
||||
|
||||
|
AngryLlama Member since: 5/19/2000 From: USA |
|||
|
Posted - 5/1/2001 6:10:16 PM |
||||
| Ok, Can anyone share the source to Depth Buffer Shadowing in OpenGL? It would be appreciated. -Paul |
||||
|
||||
|
eigenvector Member since: 5/30/2001 From: Canada |
|||
 Posted - 5/30/2001 3:23:52 PM |
||||
| I am a little bit confused about the "shadow z-buffer" description given here. By the pseudo-code listing the author is giving, it seems like the author is suggesting a per-pixel shadow test in software. If so, then how can this possibly be the "most efficient algorithm", as the author claims? Perhaps the author meant that this test should be done in hardware, but if so, he certainly left out a lot of the details, or perhaps what he is desribing is something different than what I am thinking of. Anyhow, it is possible to do shadow mapping in hardware, using multitexturing, and the alpha test. I implemented this for a course project last month. In case the AngryLlama or anyone else is interested in seeing some code for how this works, you can take a look at my webpage for this course project at http://www.mikecline.net/514 my report is there in pdf format, and section 7 describes how the shadow test works, with some OpenGL code snippets. There is also Windows executables and an archive of the code. Edited by - eigenvector on May 30, 2001 3:33:02 PM |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 6/1/2001 11:42:22 AM |
||||
| A couple comments from one who has tried to impliment two of these methods: 1. MSSkinn, I have written a shadow volume engine and the greatest obstacle I had to face (and the one that finally caused me to move on to shadow maps) was capping. I don't understand how you think capping is irrelevant. Take for instance the case where the eye is just outside the volume but looking in the direction of the light, and the near clipping plane cuts into the volume. Here the shadow volume boundary is clipped by the near clipping plane somewhere in the middle of the screen, and therefore half the screen will miss the "enter shadow volume" which would have incrimented the stencil, this will make half the screen be the inverese of whatever it was supposed to be. 2. I saw four methods to fix this and attempted three: a. Casting a ray from the eye to the light - if it intersects the object, clear the stencil to a different value. (eye inside volume). This method doesn't handle the case I described above at all. b. projecting the rays coming off the object onto the near plane if they intersect the near plane. Kind of a "hit and slide" method. c. finding the intersection of the shadow edges and the near plane and creating a triangle strip cap on the near plane, centered at the center of the view or something. d. use the stencil buffer. Create caps on the top and bottom of the volume, and render it alone into the stencil. The resulting stencil is kind of a "near clip plane" I ended up using a, and just ignoring the case I described in 1. b just didn't work, c broke terribly when the user looked towards the sides of the volume, and d wouldn't work because of the dynamic object nature of our application. 3. Eigenvector, I checked out your code, and I think it might be the first Shadow map algorithm i can undestand! ;-) However, I must impliment shadow mapping in D3D8, and I haven't seen any D3D-related shadow mapping code anywhere... just lots of OpenGL ;-). Any idea where I might find some helpful D3D8 shadow mapping resources? Also, what do you think of the methods NVIDIA and SGI have presented for accelerating shadow mapping, such as the w/q stuff (using the hardware divide)? |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
