Game Development Community

PSSMLightShadowMap::_calcSplitPos - Split code that was commented out

by Joshua Halls (Xerves) · in Torque 3D Professional · 12/02/2009 (2:30 pm) · 5 replies

Not really sure why that isn't being used for the 4 splits. It looks so much better than the current method. As mentioned in the comment it doesn't do a good job with 3/2/1, but that is easy enough to use the current code for those. If you have a video card that can handle a 2048 texture size on those shadows it looks pretty good from close/far and the last cut doesn't look all distorted. If you have source access you might try putting that code in and checking it out for yourself.

About the author

Part of the team that works on The Repopulation, a SciFi based MMO using a heavily modified version of the Torque MMO Kit - T3D. I also take care of the T3D version of the Torque MMO Kit.


#1
12/02/2009 (7:10 pm)
Thats my code and comment... i'll be removing both for 1.1 final. The PSSM split scheme using the log weight is working great now with the changes Brian made to the split selection in the shader code.

For kicks i re-enabled it for the desert map and its much worse than the log weight tuned splits which bring in the detail closer to the camera.
#2
12/02/2009 (7:51 pm)
This in the Alpha or the changes made recently? I still have a TON of issues in the last cut no matter what changes are made. Getting the up close shadows to look good is fairly easy, the distant ones always seem to be the issue.
#3
12/03/2009 (10:20 pm)

The distant shadows will always be lower resolution and you have to sacrifice some resolution in the near/middle to get more resolution at distance. Or go to more splits... i think Cysis used 5 or 6.

Also if your not aware of it... give this a shot in the console:

$AL::PSSMDebugRender = 1;

That should render the splits in colors, so you can see what your doing when tuning the log wieght.

Here is a maybe crazy idea... what if we just exposed all 4 split distances directly... in meters? Seems like it would allow for exact tuning, but would maybe be harder for people to adjust.
#4
12/03/2009 (10:29 pm)
Kind of did that already for 3 splits. Problem is it pushes in and out some of the splits and does taking a bit of tweeking. Perhaps you guys could figure out a cleaner way of doing it than my brute force attempt :-).

I still have an issue with the last cut though as I cannot seem to get any kind of proper values on it and it is horribly fuzzy/shaky. If you check the box for terrainOnly it typically gets rid of the cut so you don't have the problem, but then you don't have enough distance and have to push it out further making up close blury again :-(.

That code that was commented out does pretty good for all 4 cuts for some reason or another. Up close with a high enough texture size it looks ok (could be better), but the distant ones even on the last cut look good. You can really see the last cut if it is projected onto something vertical like a building. Our trees do that quite a bit and I could post a screenshot if it would help explain the issue.
#5
12/03/2009 (11:37 pm)
Ok, I think I understand all of this now after I got over what the logWeight magical math was doing. I would actually vote for doing breaks by the distance and putting in that color option in as a debug option straight into the GUI. Also if possible put in up to 6 cuts. Might not be the best for peformance, but would look better for demos/screenshots and for those who have the latest and greatest.