PDA

View Full Version : Shadowmaps or Stencil Volumes



soconne
08-15-2003, 09:46 PM
Which of these shadow techniques is best for games? I know they use both, but which is less cpu expensive and easier to implement on not so "new" video cards.

rgpc
08-15-2003, 11:46 PM
IMO, buffers are most likely the best way to go - but I think older cards are less likely to be able to use this technique - which would force you to use stencil. (There's also projective (?) shadows which may be preferable over stencil shadows).

Stencil shadows require a large amount of fill rate, by comparison to buffers. I've got to admit though, I haven't implemented buffers and I haven't been able to get around one issue I can see (I haven't given it much thought either).

How do you use buffers to light/shadow an entire scene? Presumably you need a shadow/depth texture for various segments of your scene (which would be made using a grid of connecting frustums from the lights point of view)? Or do you just use one really wide angle frustum (which would give you poor quality)?

jwatte
08-16-2003, 01:05 AM
There is a paper on Perspective Shadow Mapping which solves lots (but not all) of the "how to cover an entire scene" problem.

If you're on non-depth-texture hardware, but still have per-fragment tests, then you can use an ID shadow buffer, where each element (or even each triangle) has its own color, and you "pass" a fragment only if the ID you calculate when rendering is the same as in the map.

I believe shadow maps is going to be the preferred way in the future -- movie rendering has used it for ages, and if stencil was either more efficient or better looking, then they would have used that, wouldn't they? :-)

kard
08-16-2003, 02:02 AM
Originally posted by jwatte:
There is a paper on Perspective Shadow Mapping which solves lots (but not all) of the "how to cover an entire scene" problem.


Could you give us this paper's reference ?
Thanks !

JustHanging
08-16-2003, 02:15 AM
Here: http://www-sop.inria.fr/reves/publications/data/2002/SD02/PerspectiveShadowMaps.pdf

There's one big problem with them, though. When the light is behind or in front of the camera, the map will degenerate to a normal shadow map. If the light (usually sun) is above the viewer, this typically doesn't matter because you'd only see a small part of ground or sky anyways, but don't start dreaming about making sunsets with PSMs.

I've made a small demo of using shadowmaps in a small enviroment, you can download it from http://www.hut.fi/~ikuusela/demos/EngDemo.zip

The demo is made to work with relatively old computers (GF2 is just fine), it can be optimized a lot for newer hardware. Needs 32bit colors.

-Ilkka

Ysaneya
08-16-2003, 03:02 AM
I've made a small demo of using shadowmaps in a small enviroment,


Doesn't work on my P4-3Ghz + Radeon 9700. No crash nothing, the window just stays empty (as if it was not rendering anything). The title says 180 fps.

Y.

rgpc
08-16-2003, 04:17 AM
Originally posted by Ysaneya:
The title says 180 fps.


Maybe your eyes aren't fast enough. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

JustHanging
08-16-2003, 05:24 AM
Ok, I think I fixed it. Try it again. At least you should get a better fps http://www.opengl.org/discussion_boards/ubb/wink.gif

-Ilkka

JustHanging
08-16-2003, 06:46 AM
I have to add, though, that as nice and fast the shadowmaps are, they're not a very safe choice. It's often said that using shadow maps you can add shadows to your scene very easily, but reaching the quality and generality required for a quake-like game engine takes quite a lot efford.

And whatever you do, you don't really get past the fact that some detail don't get correctly lit due to aliasing. In most cases it can be worked out one way or another, but compared to pixel-perfect stencil shadows it's quite a lot of trouble. And omnidirectional lights are a real pain...

All this being said, I'll definetely go on with my shadowmap engine developement. With the dirty parts out of the way, it does look quite good.

-Ilkka

SirKnight
08-16-2003, 08:53 AM
Cool demo. It worked great for me on my P3 600MHz w/ GeForce4 Ti 4400. I only got around 22fps. But that is expected due to my slow CPU. I'm just curious, what technique do you use to make the shadows soft? Do you just render the shadow multiple times while jittering the light or something else? It looks pretty good.


-SirKnight

[This message has been edited by SirKnight (edited 08-16-2003).]

zeckensack
08-16-2003, 09:04 AM
JustHanging,
after a dialog that says "Faces: 1196, Vertice [sic]:2431, Textures: 4" your (updated) demo produces a solid grey window and a lot of access violations for me.

"Access violation at address 69315383: read of address FFFFFFFF."

One of these thingies pops up every time I task switch to the demo (message pump?).

Radeon 9500Pro, Cat 3.6, Athlon XP (yup, got SSE), and all the other good things.

[This message has been edited by zeckensack (edited 08-16-2003).]

Nutty
08-16-2003, 10:01 AM
Shadow buffers have the advantage of working with alpha masks, so things like tree foliage works, using stencil on that would be a nightmare.

Shadow buffers, would use more fillrate over stencil if a point light was inside an object tho.

Adrian
08-16-2003, 10:43 AM
Works fine for me, 60 fps on a P2 333Mhz GF3.

Some graphical glitches but pretty good.

SirKnight
08-16-2003, 12:24 PM
Oh yeah I forgot to say, the window was at 1024x768. When I made it smaller, the fps jumped up quite a bit to just at or around 100fps. http://www.opengl.org/discussion_boards/ubb/biggrin.gif


-SirKnight

madmanchan
08-16-2003, 12:32 PM
There are a number of tradeoffs between shadow maps (aka shadow buffers) vs shadow volumes.

Shadow volumes:
Pros:
- robust (using the techniques discussed in a paper by Cass Everitt and Mark Kilgard)
- per-fragment accurate hard shadows
- handles omnidirectional light sources

Cons:
- robust version requires watertight polygonal meshes (e.g. closed triangle mesh with consistent orientation)
- for dynamic models, finding silhouettes must be done on host processor (which can be costly for large models)
- not scaleable for complex scenes due to large fillrate requirements: shadow polygons tend to overlap (which leads to large stencil overdraw) and occupy large screen area. Fillrate requirements can be reduced using the EXT_depth_bounds extension.

Shadow maps:
Pros:
- Simple algorithm -> can be implemented entirely in hardware
- Works with any model that can be rendered into a z-buffer, not just polygonal ones (perhaps not a critical requirement now, but may be useful in the future)
- Fast: shadowing calculations are performed in image space (using depth comparisons), so performance is largely independent of scene complexity

Cons:
- Because shadow maps work in image space, this means we can get sampling artifacts such as aliasing (this is what Perspective Shadow Maps partially addresses).
- Another annoying sampling artifact is the "scale/bias" needed to make sure that surfaces do not incorrectly shadow themselves.
- By default, only handles directional lights (e.g. a spotlight).

Unfortunately, because of these tradeoffs, there is no easy answer to which of the shadow methods is the best. I do believe that as games incorporate more and more complex models / scenes in the future, shadow volumes will break down performance-wise (the scaleability issue) and that newer techniques based on shadow maps will become preferred.

Eric

Korval
08-16-2003, 03:05 PM
A few things are missing from that (mostly quite comprehensive) list:


- for dynamic models, finding silhouettes must be done on host processor (which can be costly for large models)


Finding silhuette edges can be done in hardware. What you do is you render the mesh with a special shader that determines whether the vertex's normal would be pointing towards or away from the light. If it points towards, do T&L as normal. If it points away, you transform the position of the vertex far away from the light. This creates the shadow volume.


- not scaleable for complex scenes due to large fillrate requirements: shadow polygons tend to overlap (which leads to large stencil overdraw) and occupy large screen area. Fillrate requirements can be reduced using the EXT_depth_bounds extension.


There's more to it than this.

Shadow volumes require 2n + 1 passes, where n is the number of lights. First, you make a pass for drawing the volumes into the stencil buffer. Then, you make a pass for using that buffer to apply light. Lastly (or first), you make an ambient pass.

Shadow maps only require n + 1 passes, assuming that your fragment processor has enough instructions to do all the per-fragment processing that you need. You need one pass per light for the shadow maps, and then you need 1 pass for the rendering of the scene itself.


- By default, only handles directional lights (e.g. a spotlight).

Using cubemaps, you can handle point lights. The problem there is that a point light requires 6 passes.

JustHanging
08-17-2003, 01:19 AM
Originally posted by SirKnight:
I'm just curious, what technique do you use to make the shadows soft?

The good old: http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008781.html

I also tried rendering the penumbras by filtering the depthmap, which wouldn't require finding silhouettes, but went back to the old method because the shadow antialiasing you get with the old method makes quite a difference.

The omnidirectional lights are handled via dual paraboloid shadow maps. Not sure if that's the best way, but it's not bad either.

zeckensack: Strange. Looks like you're missing one of the extensions I use (no, I don't check...) The reason you get the error message when task switch could be that redraw causes the error.

Adrian: What kinds of graphical glitches? Can you post a shot?

-Ilkka

Banzai
08-17-2003, 10:42 PM
What about dual paraboloid shadow mapping, which covers point lights? With this technique you can use point lights as well for shadow mapping.

NitroGL
08-17-2003, 10:46 PM
Originally posted by Banzai:
What about dual paraboloid shadow mapping, which covers point lights? With this technique you can use point lights as well for shadow mapping.

From what I've seen that doesn't work well unless you have well tesselated geometry.

Banzai
08-17-2003, 11:18 PM
Originally posted by NitroGL:
From what I've seen that doesn't work well unless you have well tesselated geometry.
Yes, but the fact is that you need the well tesselated geometry only during the shadow map generation phase. After that you can draw the scene with lower tesselation. And as the shadow map generation produces a depth map only (no need for textures or lighting), the rendering should be very fast.

JustHanging
08-18-2003, 12:24 AM
Originally posted by Banzai:
What about dual paraboloid shadow mapping, which covers point lights? With this technique you can use point lights as well for shadow mapping.

That's what I'm doing in that demo, all the lights are omnidirectional. I tesselate the static geometry seperately for each light and store the tesselation with the lights. The tesselation algorithm makes sure that all edges in the projected image are shorter than a certain treshold. This creates a tight tesselation near the light, but distant polygons get tesselated hardly at all. As a side product this tesselation removes the need of a normalization cubemap in diffuse calculations and allows me to do proper specular (eye and light vectors normalized per-vertex) without serious artifacts.

I compared this technique with uniform tesselation, and found the per-light tesselation much faster with similar image quality. Of course it does take some memory to store seperate geometry for each light. Tesselating geometry on the fly is quite expensive too, but you only have to do it for moving lights, and if there are several lights moving at the same time, it's usually enough to retesselate one light per frame. This way you can pretty well maintain realtime rates in most scenes.

-Ilkka

Korval
08-18-2003, 01:09 AM
That's what I'm doing in that demo, all the lights are omnidirectional. I tesselate the static geometry seperately for each light and store the tesselation with the lights. The tesselation algorithm makes sure that all edges in the projected image are shorter than a certain treshold. This creates a tight tesselation near the light, but distant polygons get tesselated hardly at all.

Wouldn't it be faster (and certainly easier) to use a cube-map? Granted, that's 6 renderings of the scene rather than 2, but that tesselation, especially for geometry with complex transforms (skinning, etc), can't be particularly fast.

You wouldn't have to stream vertex data too; it could just live on the card. That way, you reduce your send time. That, coupled with not tesselating might make up the difference. Then again, it might not.

Also, you can decide only to render certain faces of the cube map, depending on where the camera is. In many cases, this allows you to render only, say, 3 faces of the cube (usually if the light isn't directly in-view).

JustHanging
08-18-2003, 01:37 AM
Yes, you may be right. But the per-light tesselation can be surprisingly loose, besides there are advantages to the tesselation too, like I said in the previous post. For me these advantages are rather important, as I target GF2 class hardware and they allow me to render diffuse bump with shadows and attenuation in 1 pass (excluding shadowmap updates). And I'm not even sure if good specular could be done without.

Also, when compared to cubemaps, you get less render target switches and you have to render only a very small part of the scene twice when updating the map. With cubemaps almost everything lies partially on a cube face border.

Stuff like people don't need tesselation. Actually they don't even need paraboloid projections, the mapping can be approximated by perspective projections.

But, like I said, I don't know which is better.

-Ilkka

Madoc
08-18-2003, 01:58 AM
Originally posted by madmanchan:
Shadow volumes:
Cons:
- robust version requires watertight polygonal meshes (e.g. closed triangle mesh with consistent orientation)
- for dynamic models, finding silhouettes must be done on host processor (which can be costly for large models)
- not scaleable for complex scenes due to large fillrate requirements: shadow polygons tend to overlap (which leads to large stencil overdraw) and occupy large screen area. Fillrate requirements can be reduced using the EXT_depth_bounds extension.


You don't actually need watertight or manifold models, this is a common misconception about stencil shadows. You just need to handle open edges and the like.

Saying that it's simply not scaleable to complex scenes is a bit vague. It's a huge amount of work, but there really is a *lot* you can do to reduce fill requirements. If you are really careful about what you draw and how, you can maintain very good performance. There is also a lot of off-line preprocessing you can do for static content to this effect.

If you're looking for something quick and simple you can't have high-performance stencil shadows, granted.

Adrian
08-18-2003, 01:26 PM
Adrian: What kinds of graphical glitches? Can you post a shot?


I don't have screencapture software on this machine.

After moving the light around I get an unshadowed line between the edge of the curb and the shadow from the curb. This happens on a GF3 and GF5.

I also just got access violation errors when I left it running.

[This message has been edited by Adrian (edited 08-19-2003).]

AdrianD
08-18-2003, 08:05 PM
Originally posted by Adrian:
I don't have screencapture software on this machine. [...]


when you press strl+printscreen, windows copies the full destop including all open windows into the clipboard.
So when you have Photoshop (or any other painting-app, thats supports copy&paste from other apps) all you have to do to get a screenshot is:
press ctrl+printscreen, open photoshop, press ctrl+n (creating new document),press ctrl+v (paste the screenshot). thats all.

Adrian
08-18-2003, 11:46 PM
press ctrl+printscreen

Thanks, I'd forgotten that. http://www.adrian.lark.btinternet.co.uk/PSM.JPG

JustHanging
08-19-2003, 12:50 AM
Ok, I see. Thanks. It's a bias problem. I increased the bias quite a bit before uploading the new version, because I was having some problems with my laptop.

Which reminds of one more problem with shadowmaps, the actual amount of bias needed seems to depend on the hardware even if you're running with same pixel format. This is propably because some differences in rasterization.

-Ilkka

Csiki
08-19-2003, 03:16 AM
Originally posted by JustHanging:
Ok, I see. Thanks. It's a bias problem. I increased the bias quite a bit before uploading the new version, because I was having some problems with my laptop.

Which reminds of one more problem with shadowmaps, the actual amount of bias needed seems to depend on the hardware even if you're running with same pixel format. This is propably because some differences in rasterization.

-Ilkka

That's why I don't like this shadow method...
It is able to set up a bias that is good in all cases?

Tom Nuydens
08-19-2003, 04:15 AM
Are you rendering only backfaces into your shadow map? That should prevent a lot of the biasing problems (provided that all your meshes are closed).

-- Tom

AdrianD
08-19-2003, 05:03 AM
another method commonly used with shadwomaps to prevent aliasing artefacts is:
when rendering shadowmaps, render the meshes with slighltly shrinked geometry. (just like the shells for fur rendering, but in the different direction...)
this way, many selfshadowing artifacts with shadowmaps can be avoided.

dorbie
08-19-2003, 07:11 AM
Has anyone formulated this whacky double projection at a decent speed on hardware?

I still think there are issues with that paper when you consider some scenarios with objects near and distant from the viwer. *Soft* shadows in hardware are still a problem and are actually defeated to an extent by this double projection approach.

Some reasons image based shadows are popular in software rendering are IMHO, its very fast for fixed lights, its built into the tools, renderman etc loves it, and you can tweak the soft shadow filtering which also simulates (to a limited degree) the perspective effects of soft shadow penumbras, it's EASY to implement, the filtering in software image based shadows can be excellent and include adjusted fltering for lightspace Z cheaply (the cheap soft filtering is the biggest issue IMHO), software can have obscenely large textures to overcome the most objectionable issues and a shadow querry costs you a few cache misses & cheap math vs a full shadow test on the entire scene so the slower your traditional occlusion determination the more attractive the image based approach. I suspect it's also useful to get something you can reproduce consistently across a range of rendering systems.

I actually like image based shadows, but well filtered depth map shadows aren't there yet at decent speed (need to revisit this with shaders & multiple programmable taps tested against r). Other image based shadow maps give much better results in hardware, can support translucency etc but lack self occlusion or any kind of complex scenario support without software.

I think you can mix & match most of the above and right now you need to, there is no best approach.

JustHanging
08-20-2003, 04:37 AM
Originally posted by Csiki:
[BIt is able to set up a bias that is good in all cases?
[/B]

No, not really. For most scenes, it's possible to adjust the bias so that there are no artifacts, but id does depend on the scene, and obviously on the hardware too. I guess the program can be made to test different biases on load-time, so it can adjust itself to a particular hardware, though.

I'm using frontfaces for the shadow maps. The backface technique causes anoying artifacts where objects meet the ground, kind of like the ones in Adrian's screenshot, except that they're everywhere. Besides, I'm rendering quake 3 maps at the moment, which means I have to prepare for worst possible geometry.

-Ilkka

ToolTech
08-20-2003, 08:42 AM
I use a combination.

I use image depth map to generate the shadow volume out of the depth maps. When we get superbuffers it will be very easy to do stencil shadow volumes out of shadow maps with high speeds.

With stencil shadows it is very easy to do soft shadows.

If you use stencil shadows it is pretty easy to do light map projection in you stencil volume based on Image based lighting source...

/Anders

dorbie
08-20-2003, 09:52 AM
I guess different people have different definitions of acceptable perfromance.

Nakoruru
08-20-2003, 11:23 AM
Someone claimed that shadow maps require n + 1 passes, where n is the number of lights. I think this is mistaken. They require n/s + 1 passes, where s is the number of lights you can program into a single pixel shader. A great advantage of shadow maps is that you can concievably do the entire lighting model with multiple lights in a single pass if you have enough instructions. This simply is not possible with stencil shadows, and is te number one reason I believe that stencils are a temporary stop gap until hardware makes shadow maps practical.

It is the same principles that applied to the transition to the z-buffer. Even though z-buffers were too slow to begin with, their generality and linear scaling eventually won the day.

There was a thread about a year ago, and there was much more resistance to my arguments than there appears to be now. It's great to see that more people are starting to agree that shadow maps are the future ^_^

davepermen
08-20-2003, 11:37 AM
hehe, i remember that thread http://www.opengl.org/discussion_boards/ubb/biggrin.gif

we had a lot of fights.

my main reason against shadow volumes today is, there is no real proper way. still not.

shadowmaps just.. work. not precious, not high quality, but at least correct. and with time, higher quality and higher precicion will come (we still have quite good quality..).

shadowvolumes are still great, though. never forget an algorithm, you can find use of it one day, at some completely different place..

i currently think of using them for guess what? volumetric shadows! well, real volumetric visible ones, in my raytracer..

one day..

they are a geometrical solution, thats wrong anyways. espencially as the algo does not generate the at least correct geometrical solution http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Nakoruru
08-20-2003, 12:27 PM
Hmm, I made a mistake about how many passes shadow maps take. I forgot that you have to render the scene from the perspective of each light, and that could be seen as a 'pass', and that is probably what the original poster meant.

It probably would not be difficult to optimize rendering shadow maps so that you do not have to rerender them every frame.

I've been deep into Gameboy Advance programming the past year, so I have not kept up with OpenGL and the forum like I used to. ^_^

EDIT: daveperman, I have reread the thread, and see why you remember. You helped to curb my enthusiam quite a bit by splashing me with the cold water of facts I had not considered. ^_^



[This message has been edited by Nakoruru (edited 08-20-2003).]

Nakoruru
08-20-2003, 12:42 PM
Hmm, I made a mistake about how many passes shadow maps take. I forgot that you have to render the scene from the perspective of each light, and that could be seen as a 'pass', and that is probably what the original poster meant.

It is not difficult to optimize rendering shadow maps so that you do not have to rerender them every frame however.

I've been deep into Gameboy Advance programming the past year, so I have not kept up with OpenGL and the forum like I used to. ^_^

EDIT: daveperman, I have reread the thread, and see why you remember. You helped to curb my enthusiam quite a bit by splashing me with the cold water of facts I had not considered. ^_^
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007009.html



[This message has been edited by Nakoruru (edited 08-20-2003).]

rgpc
08-20-2003, 03:56 PM
Originally posted by Nakoruru:
Hmm, I made a mistake about how many passes shadow maps take. I forgot that you have to render the scene from the perspective of each light, and that could be seen as a 'pass', and that is probably what the original poster meant.


But you can probably get away with using a much lower resolution so your passes, in terms of fill rate, would be more efficient (theoretically).

What I don't understand is, if you have to do n + 1 passes, how does that differ from stencil volumes? (Other than your passes being more efficient in terms of fill rate used)

Korval
08-20-2003, 04:45 PM
But you can probably get away with using a much lower resolution so your passes, in terms of fill rate, would be more efficient (theoretically).

Droping polygon resolution doesn't change the fillrate much; the same number of pixels is being filled. Granted, you're not fillrate bound when you're rendering a shadowmap; you're probably T&L or transfer bound.


What I don't understand is, if you have to do n + 1 passes, how does that differ from stencil volumes? (Other than your passes being more efficient in terms of fill rate used)

To do stencil shadows, you have to do the following. First, you lay down the ambient light into the color buffer (a pass). Then, for each light, you render the shadow volumes into the stencil buffer (a pass). Then, you render the entire scene, using a shader that performs the lighting computation for that one light (a pass). Because the shadowing is done via a stencil buffer, and you can only have one stencil buffer bound at a time, you can only render a pass for one light at a time. Hence: 2n + 1.

Shadow maps require a pass for each light to render into the shadow map. Then, it requires 1 pass to render the entire shadowed scene, assuming your shader can be long enough (and have enough resources) to accomidate the number of lights you're trying to compute. Hence: n + 1.

dorbie
08-20-2003, 09:06 PM
Yes, then there are the unmentioned overheads of clearing the stencil buffer between lights vs copying the shadow textures to the texture buffer (or render to texture overhead which can be slower).

Other details like shadow textures handling colored translucency, not self occlusion & complex occlusion, depending on whether you have depth map textures or not and of course the huge differences that can mean for soft penumbra filtering and antialiased shadow texture rendering.

In practice (and depending on your hardware and the complexity of your lighting equation), the lighting pass can take more than one pass per light, moreover texture units become precious and texture shadows can take a (full) texture unit resource from every pass in a multipass just for a single light (this again depends on your shader system & hardware).

It's best to plan this stuff with specifics after getting a good grasp of the algorithms, hopefully with some target platformin mind (if you're lucky), it's pretty complex and summaries ultimately break down in the face of varied circumstances. There really are just too many variables and too many options (hardware too varied and flexible) and scene scenarios too diverse to simply say A is better than B, or even this method takes these resources and that takes these resources.

There are all sorts of tricks and combined scenarios you can use to roll all of these tricks together and get the best of all worlds at the expense of complexity or a texture here or there.

ToolTech
08-20-2003, 11:44 PM
Can you get the stencil value from a fragment shader ? Could this be possible in the future ?

JustHanging
08-21-2003, 01:02 AM
Tooltech, can you explain how your technique is superior to shadow maps? I don't mean to underestimate it, I've read from several sources that it's a smart thing to do, I just don't get it.

What's the point of doing complex things (like comp.vision or displacement mapping) to get the damn thing rendered into the stencil buffer when you could just project it on a surface as an ordinary shadow map. The reason is usually said one freed texture unit, but I seriously doubt it's a win, especially when you can project attenuation and penumbras with that same unit anyways.

-Ilkka

dorbie
08-21-2003, 01:47 AM
Correction [to this post's first version], Tooltech is talking about something else. I suppose the promise of Tooltech's idea is hardware extraction of the silhouette and lightspace penumbra generation. If you perform a morphological operation on the depth image, or on the image space vector extraction you end up with penumbra edges for multiple stencil volumes. Something I think he's looked at before. OTOH you end up undermining the omnidirectionality of the volume projection.

Hmm another big advantage is your volume forms a beam tree that is a near optimal single surface, and you end up with no extraneous overlap and can avoid stencil overflow, infact you only need one bit of stencil with inc and dec wrapping.

A huge disadvantage is it would suffer from z precision requiring offsets like other conventional depth image based approaches, and ofcourse resolution issues even if the edge is straight & smooth the projected volume cannot exceed the rendered image in detail or accuracy. Aliasing in fine distant details would defeat volume extraction.


[This message has been edited by dorbie (edited 08-21-2003).]

dorbie
08-21-2003, 02:05 AM
Tooltech, the stencil value is used in the non programmable framebuffer operations and cannot be read from the destination buffer in the fragment program. In fact in general the destination buffer cannot be read unless you explicitly write code to supply it via some kind of auxiliary storage, i.e. pbuffered texture this is intentional to keep hardware fast (in current hardware designs).

Edit, with previous post I realized that with tooltech's depth image extraction he has a uniquely isosurface shadow volume due to image extraction so things like stencil correctly storing penumbra count even with convex geometry casting in the penumbra zone are feasible.


[This message has been edited by dorbie (edited 08-21-2003).]

dorbie
08-21-2003, 03:01 AM
P.S. FWIW I wind up concluding that it's currently impractical unless you're talking about static lights & static portions of the scene, but good luck. Even for static scenes I think offline processing could obviously produce the better equivalent product without the precision issues.

rgpc
08-21-2003, 03:12 AM
Originally posted by Korval:
Droping polygon resolution doesn't change the fillrate much

I wouldn't expect it would, however dropping the resolution rather than the polygon count would decrease the impact on fill rate.

And I see the difference between the two in terms of passes now. I didn't count the setup of the stencil buffer.

ToolTech
08-21-2003, 11:10 AM
Great Dorbie. Finally someone understand !

Combine the umbra/penumbra modified stencil volumues with a projective additive lightmap created from a IBL source and you get very good lights.

Also..

Imagine to replace all common geometries like tris etc with IBR images that gets unpacked on GFX hw in real time into geometry and then create depth images from these and you get IBR + shadows + IBL !

hmm. demo is comming soon..

davepermen
08-22-2003, 05:00 AM
Originally posted by Nakoruru:
Hmm, I made a mistake about how many passes shadow maps take. I forgot that you have to render the scene from the perspective of each light, and that could be seen as a 'pass', and that is probably what the original poster meant.

It is not difficult to optimize rendering shadow maps so that you do not have to rerender them every frame however.

I've been deep into Gameboy Advance programming the past year, so I have not kept up with OpenGL and the forum like I used to. ^_^

EDIT: daveperman, I have reread the thread, and see why you remember. You helped to curb my enthusiam quite a bit by splashing me with the cold water of facts I had not considered. ^_^
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007009.html

just reread the good old thread.. hehe

and.. did we got any further?

i'd still like to see a rastericer wich rasterices a triangle onto a cubemap instead of only a 2dmap.. hehe..

then again, i'm happily raytracing..


oh, one thing: no, i didn't got an nv30 as i stated in this post. and yes, todays hw is still too primitive to do real raytracing http://www.opengl.org/discussion_boards/ubb/frown.gif