Quickie: Shadow maps speed independent of polycount?

[JF_Aidan_Pryde]

Shadow volumes / Stencil:
Scales (some polynomial) to additional geometry?
Scales (some polynomial) to additional lights?

Shadow maps on the other hand:
Additional geometry has no effect on speed? (Since it's simply a render to texture from the light's perspective)
Scales (some polynomial) to lights then?

Sorry for the crummy post, need an answer fast.
(If someone can fill in what order that polynomial is, I'd be eternally grateful!)

 

[Simon F]

Shadow volumes / Stencil:
Scales (some polynomial) to additional geometry?
Scales (some polynomial) to additional lights?

Shadow maps on the other hand:
Additional geometry has no effect on speed? (Since it's simply a render to texture from the light's perspective)
Scales (some polynomial) to lights then?

Off the top of my head, I'd say both methods would be linear - but that doesn't mean a great deal in the scheme of things since there could be orders of magnitude difference in the "constant factor" term.

Geometry does have an effect on the shadow map as you have to generate the shadow map from geometry in the first place!


Fill rate issues are a more important issue in terms of performance (shadow maps should use less fill rate) just accuracy is in terms of quality (shadow volumes will generally be far more accurate).

 

[GameCat]

Simon F is right, it isn't that stencil shadows have higher aymptotic complexity, but a higher constant cost.

To get any sort of reasonable geometry load with stencil shadows you have to find silhouette edges on the cpu. This means they don't scale very well with complex scenes featuring lot's of triangles. Even if you could generate the silhouettes on the GPU, a simple render triangles to texture and write out depth (shadow maps) pass would probably be faster since it's so simple.

In addition, the fillrate hit of shadow maps is much more sensible. With stencil shadows you can end up spending a lot of fillrate on just determining where the shadows lie since you draw lots of overlapping "invisible" triangles.

Of course, shadow maps is not a panacea, there are plenty of precision and aliasing issues compared to stencil shadows for example. But the simplicity of the algorithm, the fact that it maps so well to 3d hw and that you can get fairly high quality soft shadows both fairly cheaply and with a simple technique means they are probably the better choice for the future.

Sure the maps will eat lots of memory and people will say it's not "elegant", but the same things can be said about the z-buffer. It still scales better than anything else if you want to do it in hardware.

It's really a shame that ATI hasn't got native PCF in their current hw.

 

[JF_Aidan_Pryde]

Thanks Simon, Gamecat.
I think I get it.

I made the mistake of thinking that when shadow maps are generated from the perspective of the light, it's like hitting 'screenshot' to the pbuffer. I forgot that to render that one frame, you have to go through the whole transform, setup procedure!

Random though, pixar uses shadow maps right?

 

[Hyp-X]

Shadow volumes / Stencil:
Scales (some polynomial) to additional geometry?

That's a complicated issue.
The largest performance consumer with shadow volumes tend to be the fillrate hit of rendering the volumes themselves.

Take a sphere for example. The fillrate requirement will be constant no matter how many polygons does the sphere consist off.

Now displace some vertices of the sphere and the shadow volume fillrate goes up (sometimes insanely so!), even though there's no change in the vertex/poly count.

So the answer is it scales with geometry complexity.
Where complexity is something that is hard to quantify.

Scales (some polynomial) to additional lights?

Linearly.

Shadow maps on the other hand:
Additional geometry has no effect on speed? (Since it's simply a render to texture from the light's perspective)

Yes it's simply a render to texture from the light's perspective.
And as such geometry has the same effect as with normal rendering.

When rendering the polygons you either vertex processing or pixel processing limited, which can change during the scene rendering.

Scales (some polynomial) to lights then?

Linearly.

 

[3dcgi]

I don't know about pixar, but a lot of non-realtime renderers use shadow maps. Another thing about shadow volumes is they contain irregularly sized triangles. I.e. long and skinny. This might be a non-optimal shape for the setup engine, thus further reducing fill rate.

 

[Simon F]

Another thing about shadow volumes is they contain irregularly sized triangles. I.e. long and skinny. This might be a non-optimal shape for the setup engine, thus further reducing fill rate.

I don't think it'd worry the set up engine but, yes, reduced fill rate may be an issue. On Dreamcast we used to recommend chopping them in ~1/2 along their length. It produced more polys, of course, but sped up the rendering. I'm not sure the same would apply to Kyro though as it handled these cases much better.

 

[Laa-Yosh]

I don't know about pixar, but a lot of non-realtime renderers use shadow maps.

Pixar had support for shadow maps only, until the introduction of PRMan 11 last autumn. So practically all movie effects used shafow maps.

Shadow maps always required extensive tweaking by lighting TDs though...