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?
Originally posted by esc:
linky?
simple googole for “realtime radiosity”
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
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.
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…
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… 
-Ilkka
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
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
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.
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?
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?
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 
Charles
Originally posted by hyvelbank:
[b]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?[/b]
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).
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
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.
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.
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.
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.
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.
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 =)