Real-Time Soft Shadow Volumes

Full source code and binaries available for our soft shadow volume demo at
http://www.borgenstam.com/noname/
and http://www.ce.chalmers.se/staff/tomasm/soft/

Cool!

Just wish there was some bigger levels, i.e. more than a couple of boxes. Would be nice to see the performance in a Quake type map.

Anyway, nice of you to include source.

/Chris

The simplicity of the scenes are of course modifiable. See http://www.borgenstam.com/noname/ for information on the map format. There are several mesh files in the binary distribution that can be used both as static and dynamic objects.
Any 3ds file can be converted to msh format, and then used in the demo as a shadow caster and/or reciever.

Nice work!

I get quite a variation in frame rates though, from 100fps down to 2fps when there is a lot of shadow in view.

I have an GFX5900u and AMD XP2000+, Win XP.

Currently there are some performance issues with the nvidia version.

We have had similar problems with ati, which turned out to be driver related, and it is now solved.

Hopefully the problem with the nvidia version will be solved so owners of nvidia cards can experience soft shadow volumes in full real-time as well.

Very cool demo. I have a GeForce FX 5600U and yes there are definately some issues with performance there. Using hard shadows I got a constant fps but using soft it went as low as 1.5 near the stacked boxes. One thing I would suggest that would help performance on the nvidia version would be to drop ARB_fp and use NV_fp. So this way you can make use of the lower precision data types, and the FX cards are more happy with its own extension anyway.

-SirKnight

The demo crashes on my machine (it tries to read from null pointer) - AthlonXP, ATI 9500Pro, WinXP SP1, Cat 3.10

Edit: I tried to recompile it, but ode/ode.h is missing.

-Lev

[This message has been edited by Lev (edited 01-08-2004).]

Minimum requirements for the ati version is: ati 9700. Unconfirmed sources say that it might work on mobility 9600.

To build the demo, you have to build ode in single precision mode. Download ode from http://www.q12.org/ode/

[This message has been edited by hyvelbank (edited 01-09-2004).]

Unfortunately there is not enough time to implement nv versions. After Februrary we will leave our office, and with that the access to the graphics cards.
However, if anyone is interested doing the nv versions, please do so and let us know.

9500 is the same card as 9700, except speed. If it runs on a 9700 it should run on any 9500+.

Edit: I just tried it on a 9800 Pro (at work) on a w2k with Cat 3.9 drivers. It runs, but the shadows are not soft and it runs only at 5 fps. I also tried it on a FX 5800 Ultra, and it runs correctly, though with great slowdowns when looking ak the shadows.

-Lev

Originally posted by hyvelbank:
[b]Minimum requirements for the ati version is: ati 9700. Unconfirmed sources say that it might work on mobility 9600.

To build the demo, you have to build ode in single precision mode. Download ode from http://www.q12.org/ode/

[This message has been edited by Lev (edited 01-09-2004).]

The driver related problem was present in Cat 3.9, and most of the earlier versions. Try Cat version 3.10, they have fixed the problem in this latest version.

When it comes to the null pointer you mentioned earlier, we have no clue what it might be. It sounds like there is a missing extension. Does the command prompt in the background say anything?

Hm I must catch the admin to update the w2k to cat 3.10, but then I’ll try it.

Crash related: when I’m back home I’ll get ODE and I’ll try to debug it. It crashes before the console window appears if I remember correctly (not sure though - I’ll post more details when I’m back home)

Regards
-Lev

Originally posted by Lev:
9500 is the same card as 9700, except speed. If it runs on a 9700 it should run on any 9500+.

you’re right, and it works very smooth on the 9500+.

It crashes after printing this line:

Creating v-buffer render target.

-Lev

I can’t compile the project using VS.NET 2003 due to some really strange errors in MS STL headers.

-Lev

[This message has been edited by Lev (edited 01-09-2004).]

Cool!

Would it be usable in a “real” enviroment like tenebrae? (Both speed and especially robustness are issues here…)(http://tenebrae.sourceforge.net/)
Soft shadows are one of the features users ask us about a lot

Charles

Originally posted by Pentagram:
Would it be usable in a “real” enviroment like tenebrae? (Both speed and especially robustness are issues here…)

if the nvidia version reaches the same performance as the ati, speed should not be a problem. Since the algorithm is based on standard shadow volumes, I don’t think robustness should be a problem.
The ultrashadow optimizations can be used, and increase performance.
It is worth mentioning that in the demo, we do not use any culling except back-face culling.

tons of bugs. its a fun thing, but if you test teh other test-i.map files, you’ll see tons of bugs. spherical shadows built by boxes, shadow poping if you get at an edge of the shadow volume extrusion, shadow volumes wrong created if a box is directly on the lightsource (it simply doesn’t shadow), and even some clipping issues with some shadows…

tons of bugs, all related to standard shadow volume bugs.

its nice to play with, and looks rather cool. but the most fun is simply the ODE in

Yes, these are the limitations of the algorithm. We refer to the papers ( http://www.ce.chalmers.se/staff/tomasm/ ).

Since we use the light center as an approximation when calculating the silhouette, boxes get spherical shadows. This is also why the shadows pop. One way to solve it is to split the (rectangular) light sources into several smaller light sources.

And yes, the case when the light is close to the object should be handled.

This demo isn’t perfect, but hopefully it can serve as a reference to those who wish to implement soft shadow volumes in their own projects. Enjoy, and May Your Shadows Be Soft!

Me see Box. Me Throw Box. Me Enjoy.

Originally posted by hyvelbank:
Me see Box. Me Throw Box. Me Enjoy.[/b]

that sais it all, not?

i just never believe that these shadow-technologies will be the future. a working algo should work by default, not with tons of workarounds…

its bether than hardshadows, though… on the other hand, i have real softshadow demos seen, wich had none of those bugs… they don’t work with shadow-volumes, nor really with rastericer-logic (though, they use rastericer-hw), to accomplish the task…