Sswift's Shadow System....

Blitz3D Forums/Blitz3D Userlibs/Sswift's Shadow System....

ICECAP(Posted 2006) [#1]
Ok, i am in the process of adding shadows to one of my consepts. I am getting around 150fps before i implement sswift's shadow system but after i add it in i get around 26.
I tried running it on a top of the line system and a medium-to-crap system and it runs at the same fps on both machines.
In my project i have framelimiting code but it doesnt seem to matter if i take it out or not it still seems to take off around 125 frames.
Anyone else had this? And anyone else fixed it?


Pongo(Posted 2006) [#2]
I think we might need a bit more info to give an answer for this. I use Sswift's system and I have not seem that sort of performance hit.

What resolution are you making the shadow maps? Are you using soft shadows? Soft shadows can kill things quickly. How large are the meshes involved? (poly count?)


sswift(Posted 2006) [#3]
To improve speed:

1. Reduce shadow resolution. You shouldn't need to go lower than 128x128 though.

2. Disable shadow blurring. At 128x128 they'll be blurry enough.

3. Use fewer shadows by reducing the number of lights, or the number of casters, or reducing the light radius so fewer objects get hit by each light.

4. Split your level into multiple smaller meshes, and split off portions which don't need to recieve shadows. This is probably the most important thing. If you have a terrain with all sorts of foliage for example, not only should that terrain be broken up into smaller sections, but those trees and ferns don't really need to recieve shadows, and allowing them to can kill your framerate.

The reason splitting your level up will speed up the shadow system is because the shadow system first checks a bounding sphere for the object to see if the shadow frustrum is intersecting it. If it isn't all the polygons in that object can be discarded immediately. If on the other hand your level is one big solid object, then all 65,000 polygons in it have to be checked against the shadow frustums. And even though I optimized the hell out of that, that's still way too much work to do.

In most cases, you should have your level split up anyway, because you're throwing away a lot of framerate if you don't.

One last thing to make sure of. Make sure you are only running the shadow system once per render! Mark's demos used updates at fixed intervals, and ran the inner loop multiple times per renderworld if neccessary. But it is a total waste of time to update the shadows inside those loops. You only have to update the shadows once before you render each frame.


ICECAP(Posted 2006) [#4]
Thanks sswift,
I have found that the terrain mesh is the problem... sitting at 130,000polys. :D
So i will have a go at splitting it up.
Thanks for the advice.


OJay(Posted 2006) [#5]
using swifts system for terrain-shadows is suboptimal...because you can use pointlights only, there will be a lot of issues, if used with a sunlight...

or did i miss an update? \o/


sswift(Posted 2006) [#6]
Ojay:
Did you try putting the light really far away from the terrain, and then enabling shadows only on objects which are close to the player? I don't see why that should not work.


OJay(Posted 2006) [#7]
yep tried that. the problems: shadows get VERY blurry (even with res. 1024, because the caster gets very small on the shadow-tex) and the receiving (visible) terrainmeshes are having still too much polygons to check for...


sswift(Posted 2006) [#8]
"shadows get VERY blurry (even with res. 1024, because the caster gets very small on the shadow-tex)"

That doesn't make sense. The shadow frusum is sized to fit the caster. It shouldn't matter how far away the light is from the caster.

Either there's a bug in the shadow system, or you did something funny.


OJay(Posted 2006) [#9]
hm, cant post code, 'cause removed the system from the terrain-engine already, but i dont think i did something 'funny' o_o

1. create a pivot at approx. 1000x500x1000
2. make a light caster out of it
3. add terraintiles to shadow_receivers
4. add all staticobjects to shadow_casters
5. call update_shadows every loop.

thats it. nothing fancy about it :/ (of course in the mainloop i did some optimizations e.g. remove non-visible tiles/objects from receivers/casters using delete_shadow_receiver/caster...)

if i find time, ill try to reproduce a small demo out of it...

ps: 1.20 is the current version i got over here. is it the latest release?


sswift(Posted 2006) [#10]
Yes, 120 is the latest version.

Nothing you said there sounds wrong, so I don't know what to tell ya!

I guess I should ask this... Were your objects parented to anything? Did you add the parent as well as the children? When you cast shadows from an object, all children are included in the shadow, which increases the radius, and can potentially reduce the resolution of the shadow.


Dreamora(Posted 2006) [#11]
120 is the latest?

Uhh then I must have lost that when my mailsystem crashed, still 115 here.