[RESOLVED] BL Shadow render fix
by Ivan Mandzhukov · in Torque 3D Professional · 10/19/2009 (1:50 pm) · 6 replies
After a few testing i decided to create a new thread ,moved to resolved.
decalManager.cpp
find:
decalManager.cpp
find:
getContainer()->buildPolyList( box, decalData->clippingMasks, &clipper );replace with:
getContainer()->buildRenderedPolyList( box, decalData->clippingMasks, &clipper );
#2
buildRenderedPolyList collects render mesh information in a specified area.
This solved the shadow,that renders over the collision mesh in BL.
The shadow in advanced lightning uses very different render approach,that's why you don't see anything fixed.
I think we are commenting on different things.
10/20/2009 (10:44 am)
buildPolyList collects collision mesh information in a specified area.buildRenderedPolyList collects render mesh information in a specified area.
This solved the shadow,that renders over the collision mesh in BL.
The shadow in advanced lightning uses very different render approach,that's why you don't see anything fixed.
I think we are commenting on different things.
#3
And player's shadow rendering is far better with your fix.
But on my computer, it causes a very big slowdown when I WALK. No slowdown when I'm near the left fence and I rotate my player. Only when I walk (front or rear).
Slowdown doesn't occur in blank room.
Nicolas Buquet
www.buquet-net.com/cv/
10/20/2009 (11:40 am)
I see the fix, as on my Mac, I can only test BL.And player's shadow rendering is far better with your fix.
But on my computer, it causes a very big slowdown when I WALK. No slowdown when I'm near the left fence and I rotate my player. Only when I walk (front or rear).
Slowdown doesn't occur in blank room.
Nicolas Buquet
www.buquet-net.com/cv/
#4
buildRenderedPolyList pulls a ready calculated information,so it is not responsible for the slowdown.
I believe it is due to some hlsl filtering then.
10/20/2009 (12:17 pm)
I tested this on 3 PCs and i didn't get any slowdowns so far.buildRenderedPolyList pulls a ready calculated information,so it is not responsible for the slowdown.
I believe it is due to some hlsl filtering then.
#5
If your scene is even moderately complex, I believe it would be faster to render the projected shadows by casting them on unclipped geometry. There'd be a penalty since there would be a lot more overdraw, but in most cases I believe if would be better than having the CPU calculate expensive geometric boolean operations on every frame.
I don't know exactly which changes it would require in T3D, but I remember "hacking" TGEA to do this in a past project, by using a heavily modified version of the DTS-on-DTS shader (had to make it as simple as possible to minimize the added fillrate cost of literally performing depth-shadowing on the entire screen).
10/20/2009 (12:17 pm)
Of course it will slow down. It is collecting renderable polygons and clipping them to create the decal geometry, on every frame. Such technique is only usable for casting shadows on very low polygon geometry, thus why it was casting on collision geometry by default.If your scene is even moderately complex, I believe it would be faster to render the projected shadows by casting them on unclipped geometry. There'd be a penalty since there would be a lot more overdraw, but in most cases I believe if would be better than having the CPU calculate expensive geometric boolean operations on every frame.
I don't know exactly which changes it would require in T3D, but I remember "hacking" TGEA to do this in a past project, by using a heavily modified version of the DTS-on-DTS shader (had to make it as simple as possible to minimize the added fillrate cost of literally performing depth-shadowing on the entire screen).
#6
First you can select per-TSStatic what geometry to use for decals vs. collision. So you can pick what is appropriate in your case.
Second we have some general optimizations to decal geometry generation which gets back alot of performance for shadow decals.
Still you could run into trouble in some cases.
@Manoel - Yea... its another way we could have approched it. Less CPU time clipping polys at the cost of more draw calls and GPU performance. It would also allow self shadowing.
If we decided to make BL more full featured in a future version of T3D it would be something i would seriously consider.
10/21/2009 (2:38 am)
We have some more features and optimizations on this in 1.1.First you can select per-TSStatic what geometry to use for decals vs. collision. So you can pick what is appropriate in your case.
Second we have some general optimizations to decal geometry generation which gets back alot of performance for shadow decals.
Still you could run into trouble in some cases.
@Manoel - Yea... its another way we could have approched it. Less CPU time clipping polys at the cost of more draw calls and GPU performance. It would also allow self shadowing.
If we decided to make BL more full featured in a future version of T3D it would be something i would seriously consider.
Torque 3D Owner Nicolas Buquet
In DEBUG and RELEASE mode, on a macBook Pro 2.6 GHz, 8600M GT 512 MB.
It doesn't appear with the buildPolyList version.
Nicolas Buquet
www.buquet-net.com/cv/