PDA

View Full Version : Real-Time Soft Shadow Volumes



hyvelbank
01-08-2004, 05:07 AM
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/

esc
01-08-2004, 08:39 AM
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

hyvelbank
01-08-2004, 10:38 AM
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.

Adrian
01-08-2004, 10:46 AM
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.

hyvelbank
01-08-2004, 10:57 AM
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.

SirKnight
01-08-2004, 12:49 PM
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. http://www.opengl.org/discussion_boards/ubb/biggrin.gif


-SirKnight

Lev
01-08-2004, 01:05 PM
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).]

hyvelbank
01-08-2004, 10:59 PM
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).]

hyvelbank
01-08-2004, 11:02 PM
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.

Lev
01-09-2004, 12:38 AM
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).]

hyvelbank
01-09-2004, 12:58 AM
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?

Lev
01-09-2004, 01:24 AM
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

AdrianD
01-09-2004, 02:15 AM
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+.

Lev
01-09-2004, 07:50 AM
It crashes after printing this line:

Creating v-buffer render target.

-Lev

Lev
01-09-2004, 09:01 AM
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).]

Pentagram
01-09-2004, 01:45 PM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Charles

hyvelbank
01-09-2004, 11:06 PM
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.

davepermen
01-10-2004, 05:01 AM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif

hyvelbank
01-10-2004, 06:02 AM
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!

http://www.opengl.org/discussion_boards/ubb/biggrin.gif Me see Box. Me Throw Box. Me Enjoy.

davepermen
01-10-2004, 06:15 AM
Originally posted by hyvelbank:
http://www.opengl.org/discussion_boards/ubb/biggrin.gif Me see Box. Me Throw Box. Me Enjoy.[/B]
that sais it all, not? http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif 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..

esc
01-10-2004, 07:13 AM
Originally posted by davepermen:
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..

linky?

AdrianD
01-10-2004, 07:31 AM
Originally posted by esc:
linky?

simple googole for "realtime radiosity" http://www.opengl.org/discussion_boards/ubb/wink.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif

JustHanging
01-10-2004, 08:59 AM
Originally posted by davepermen:
i just never believe that these shadow-technologies will be the future. a working algo should work by default, not with tons of workarounds..


Disagreed. In the end two things matter, image quality and speed. I haven't seen the demo, but the problems you list don't seem so serious except for shadow popping, which is related to geometric undersampling and is present in any accurate shadowing algorithm.

This technique has the big advantage of accurately handling the sharp parts of the shadows, which many GI schemes fail in, as do the shadowmap based techniques. It's like multiple stencil volumes except faster (I hope...?) and no banding.

I too would like to know which demos/techniques you're talking about. My search for realtime radiosity revealed nothing particularily impressive, all the scenes were extremely simple and the shadows were very blurred even where they should be sharp. Other advantages of radiosity are clear, but I don't think it's usable usable in real projects yet.

-Ilkka

davepermen
01-10-2004, 09:27 AM
there is no working shadow volume demo without poping on the shadow-throwing geometry. show me one

the problems in this demo are based on shadow volume problems entierly. the main problem, the unpredictability of how long a certain frame will take, is the worst. shadow volumes have no worst case, nor best cases. they are not estimatable.

i'm not allowed to talk about what i've seen. it's not my work. if you find info about it yourself, great, if not.. well.. just wait and see.

btw, the artefacts that happen due the popping result in soft-thown shadows on a fullscreen wall coming and going if you move the light just a tiny bit. very visible, very ugly.

same for the sphere-box-shadows.

and performance is not really that great.


i'm not saying the work itself is not good. en contraire, it really is. but its based as an extension to a flawed algorithm, and so it only extends those flaws.

davepermen
01-10-2004, 09:29 AM
Originally posted by JustHanging:
Disagreed. In the end two things matter, image quality and speed.

and animation quality, and predictability of speed.

image quality for a single frame is great, for animations it sucks due to popping

speed is very dependent on what is how placed, where wich shadow goes, and can be high, and low.. its not well scalable, another issue.

for future games based on shadow volumes, min fps will be very important to measure, too..

JustHanging
01-11-2004, 04:30 AM
Originally posted by davepermen:
and animation quality, and predictability of speed.

True, and also a good point about the scalability. I'd add the bad use of temporal coherency to the list myself. I'm not a huge shadow volume fan myself (I use shadow maps in my current engine to get fast soft shadows), but they're very hard to beat in a real situation when it comes to quality.

Like I said, the popping artifacts are common to any shadowing algorithm, and it's a bit unfair to project it on stencil shadows just because they're the only current solution to reach the accuracy where it becomes visible. There's also a number of solutions for this problem for stencil shadows on paper, altough they may have not made it to the demos.

The unpredictable speed is a bad thing, but in a many situations, with all the optimizations thrown in, the stencil shadows perform just fine. I wouldn't try shadowing a forest with them, but in a typical indoor scene the worst case happens hardly ever, unless you're a fan of vertical blinds.

It's not good, but it may be the best there is. With the exception of the very good lightmaps+projected shadow textures approach... http://www.opengl.org/discussion_boards/ubb/smile.gif

-Ilkka

davepermen
01-11-2004, 05:37 AM
problem is, the shadow volume poppings result in big popping-bugs in the softshadow demo.

and the popping itself is about a non-issue in any other shadowing-algorithm, so no, you're wrong.

i'm btw not talking about the popping issues on the shadow-throwing mesh ITSELF. that is a problem of polygonal meshes by default, yes.

i'm talking on resulting issues on the popping of the shadow-volume mesh wich changes with big steps in these situations, and the resulting soft shadow projected onto walls and all get huge poppings then.

this is an issue of the fact that the technique shown here is based on shadowvolumes, wich have these bugs. workaround? possible..

but there are correct shadowing-algorithms. they work correct by default, even with transparent-textured objects..

shadowmaps are one of these

JustHanging
01-11-2004, 09:58 PM
Ok, I get what you mean now. I guess I should've watched the demo, but I can't. Speaking of which, hyvelbank, do you think it's possible to implement your technique on lower end cards like GF3 or so?

Shadowmaps work correct by default? Not really, but let's not go there, everyone knows there's no ideal solution...

-Ilkka

davepermen
01-12-2004, 01:15 AM
well, shadowmaps only problem are resolution and precicion.. they are the rastericing-counterpart of how (sharp) shadows are made in raytracers. and there, they work perfect.

shadow volumes are geometry dependent. this is inherently WRONG, and, as geometry only approximates what we want to show, the resulting issues result in tons of artefacts..

i possibly fraps you the popping.. lets see what i can do.

davepermen
01-12-2004, 01:29 AM
Okay, done..

Look at the backwall, and at the light, how "much" I move it.
http://davepermen.homeip.net/Shared/ShadowBugs.avi

I don't know, but for me, this is an artefact, and its quite visible.

What do you think about it?

hyvelbank
01-12-2004, 02:13 AM
We are curious. Which shadowmap-based technique with soft shadows does not use the center of the light source as an approximation in the way the soft shadow volume technique does?

Links? Papers?

Pentagram
01-12-2004, 02:31 AM
I ran the demo now, but it's just slow (and soft shadows aren't even enabled) (how do I do that? I didn't find a key list)
I ran the Direct-X version but it's already very slow for just a single knight, so that rules out any use in a real situation currently. Also the speed seems to go down considerably if I increase the light size is that because of the wedges becoming bigger and thus requiring more pixels with the pixel shader? Or are you approximating the lights by multiple smaller lights above a cerain size?
I also recently started beleving more in the shadowmapped approach but that's probably because I did to much stencil shadows http://www.opengl.org/discussion_boards/ubb/wink.gif

Charles

davepermen
01-12-2004, 02:48 AM
Originally posted by hyvelbank:
We are curious. Which shadowmap-based technique with soft shadows does not use the center of the light source as an approximation in the way the soft shadow volume technique does?

Links? Papers?

two ways: eighter generate several shadowmaps, or use a complete different algo, a.k.a. surface-to-light instead of light-to-surface. this is what the one i talked about above uses.. (sort of backward raytracing).

JustHanging
01-12-2004, 03:20 AM
Thanks for going through the trouble with the avi. Looks nasty.

Which kind of scene is the surface->light algo working on? Cause any such algo has to draw the scene tons of times, right? So I wouldn't expect it to work on anything complicated unless you sacrifice the high-frequency parts of the lighting.

-Ilkka

hyvelbank
01-12-2004, 03:36 AM
You do not happen to have run across any real-time demos of the techniques you have mentioned?

Using several samples on the light source would have the same effect as using multiple shadow maps.

The emphasis on the version of the algorithm we have used is real-time. More precision can be implemented, on the sacrifice of performance.

Shadow maps use the same approximation with the light source center. Adding more shadow maps has the same effect as adding more shadow volumes.

davepermen
01-12-2004, 03:50 AM
But adding more shadowmaps is definitely cheaper to do in terms of fillrate. As you talk about the care about realtime performance.
The other one, yes, there is a realtime demo existing. It's not as fast as yours, but then again, its a more complex scene, it is correctly shaded, and it can have full gi solutions. Those slow it down even more, of course. But still, the algo is not biased, en contraire to yours, wich is. But the main feature (except the main feature that it does create correct shadows), is the fact that it performs rather constant in speed. And its scalable.

hyvelbank
01-12-2004, 04:37 AM
Where can we find this real-time demo? It would be nice to create similar scenes etc. and compare the algorithms in our thesis.
We would very much appreciate a direct link.

davepermen
01-12-2004, 04:43 AM
It's not under my control. The one who is is informed about the topic, and thinks about when and how to release some information. Will it be a demo, or some movies, or some pictures, we'll see.

You'll get informed as soon as i know more official information.

Adrian
01-12-2004, 07:04 AM
I'm not releasing a public demo for the time being but there are some animations and images here http://www.mars3d.com/NewRad/

At a resolution of 800x600 the framerate is about 8fps on an AMD XP2000+, GF5900Ultra. At 512x384 it is 15fps. The engine is CPU limited.

hyvelbank, e-mail me if you're still interested and I will send you a demo. My address is in my profile.

esc
01-12-2004, 07:26 AM
It seems to me that there isn't _one_ solution for realtime shadows, and that hybrid is the way to go. Maybe 2-3 different algos for different situations, of which Soft Shadow Volumes may be one...

The challenge then would be to make them look like one algorithm. Even if they're maps, volumes, or light-maps.

Wish I could spend more time on finding such a solution... However, gotta code GUI into my engine now, where shadows are REALLY simple =)

JustHanging
01-12-2004, 10:17 AM
Adrian, your screenshots look rather good. Can it handle small lightsources? Or small objects, how does it look on people, for example? Is this the same technique you used before in your realtime radiosity stuff?

-Ilkka

Adrian
01-12-2004, 11:23 AM
Originally posted by JustHanging:
Adrian, your screenshots look rather good. Can it handle small lightsources? Or small objects, how does it look on people, for example? Is this the same technique you used before in your realtime radiosity stuff?

-Ilkka

Given enough fillrate it can handle small light sources. It depends on the size of the room its lighting as well as its own size. I could cheat and display a smaller light then is actually emitting the light. I'm not sure how noticeable that would be in practice. Ultimately this limitation will go away with faster hardware.

The lighting/shadowing resolution is 1/4 of the screen resolution so lighting on small objects may not look that good. Again with faster hardware the lighting/shadowing resolution can be increased and the problem will disappear. Small objects will not be 'missed' though.

I haven't tried the engine with character models yet, it should handle it fine although the relatively high poly counts may be a problem. This is the last major hurdle.

btw the chunky voxel style of the architecture in the level is down to the level editor and not a limitation of the engine.

Yes it is the same technique that I have previosuly shown here except it now has specular/gloss mapping, cylinders/cones and its faster.

You correctly identified the algorithm's weakenesses http://www.opengl.org/discussion_boards/ubb/smile.gif but they can be overcome with more processing power and little change to the code.

chrispy
01-13-2004, 09:54 AM
Adrian you should check this paper out!
http://www.graphics.cornell.edu/pubs/2003/BWG03.html

You have to reduce the number of hemicubes rendered with clever interpolation. Nothing comes close to this technique. It achieves anti-aliasing and it can sample only 2% of a frame. (great exploitation of temporal coherence) Although only with static scenes.

I would be interested whether your current interpolation comes close to this one. How much hemicubes do you make per frame?

Chrispy

[This message has been edited by chrispy (edited 01-13-2004).]

Adrian
01-13-2004, 02:10 PM
Thanks for the link, interpolation is indeed a very important part of the engine. Their method looks very impressive.

My interpolation algorithm isnt as clever as that but it does the job. At 800x600 I render 8000-15000 hemicubes. So 12000/(800x600) = 2.5%. There is no use of temporal coherence, everything can move and the sample ratio remains stable. The interpolation algo deals with object edges on a per pixel basis but it deals with shadow edges on a 16 pixel(4x4) basis. That can be changed but obviously it effects performance. Because the shadows are soft the lower res is not noticeable.

This image used about 12000 samples http://www.mars3d.com/NewRad/Images/RadSample1.jpg
The sample distribution can be seen here http://www.mars3d.com/NewRad/Images/RadSample2.jpg

chrispy
01-14-2004, 07:32 AM
Without any edges you sample every 16th pixel. That's 6.25%. Looking at the picture it looks like it has around 10% samples. How did you calculate 2.5%?

The shadows in the paper look impressive but it only works for a few lights, so it isn't important. The biggest improvement in this method can be seen on the left of Figure1, compared to your sampling distr.
(I guess with lots of edges it can be a 2x-5x speedup)

On a side note: Bruce Walter has been converted to the Monte Carlo faith (as I have been). Stratified sampling is better than regular sampling, but the difference is not always easy to see, so it is sometimes not worth the effort.

Chrispy

Adrian
01-14-2004, 10:23 AM
Except for object edges the *maximum* sample rate is 1 sample for every 4x4(16)pixels. The minimum sample rate is 1 sample for every 16x16(256) pixels. So in a best case scenario, i.e. looking at a single flat wall with no shadows, the number of samples at a res of 800x600 would be 800x600/256 = 1875 = 0.4%

The red dots in the second image are 4x4 pixels in size and represent a single sample.

So at a resolution of 800x600 the maximum lighting/shadowing resolution is 200x150. I then may sample at a lower resolution depending on several factors including rate of change of light intensity,normal angle and the difference between the view and surface angle.

I deal with object edges seperately and sample where necessary to make sure there is no light interpolation across edges.

The 2.5% figure was calculated by taking the number of samples used, as reported by the application, and dividing it by the number of pixels. The number of samples equalled 12,000, the number of pixels was 480,000, so the sample rate = 12000/480000 = 2.5%.

[This message has been edited by Adrian (edited 01-14-2004).]

hyvelbank
01-27-2004, 06:34 AM
A new version of the soft shadow volume demo has been released!
Changes;
- "easier to follow" fragment programs,
- improved fp for spherical light sources,
- supports both nvidia and ati cards,
- resolution settings,

Download full source code and binaries at http://www.borgenstam.com/noname/ and http://www.ce.chalmers.se/staff/tomasm/soft/

All feedback is appreciated.

tEd
01-28-2004, 02:26 AM
v3 doesn't work anymore on ati. No shadows and some weird light flickering

hyvelbank
01-28-2004, 10:54 AM
Originally posted by tEd:
v3 doesn't work anymore on ati. No shadows and some weird light flickering



Please report the driver version you are using + card. Cat 3.2 still works best.

tEd
01-28-2004, 11:51 AM
i'm using cat4.1 with 9800pro but i have the same problem with cat3.2 for that matter. The old version works fine with cat4.1.

here a screenshot(cat3.2)
http://www.gaeugf.ch/ted/shadow.jpg

the lighting on the wall goes always on,off(flickering)

edit/ i tried every driver from cat3.2 to 4.1, the same thing on all.



[This message has been edited by tEd (edited 01-28-2004).]

hyvelbank
01-29-2004, 02:40 AM
Found it!

Seems like the "save settings" button forgets the lines

[BufferRatio]
horisontal = 1.0
vertical = 1.0

in the settings.ini file. We'll fix this asap.

For now, simply add the lines to the file (or edit the sources to ignore the buffer ratio variables when calculating the offscreen buffer size in World.cpp).

If you no longer trust the gui http://www.opengl.org/discussion_boards/ubb/smile.gif , you can use the settings.ini to change resolution and mouse options.

tEd
01-29-2004, 03:07 AM
yeah thanks it works now.