I spent a good five hours last night researching all manner of shadow mapping techniques, and from my initial query of Cascade Shadows I finally rested on the technique called Parallel Split Shadow Mapping (PSSM). Countless white papers, plenty of anecdotal evidence, many blogs, few demos and even less source code.
During my time I learned a whole heap about the horrors that can strike at a typical shadow mapping render. Self shadowing issues, filtering issues, performance and memory considerations, compatibility, the list literally goes on and on.
After trying to dig out running examples from the InterWeb I finally found the ideal example sitting on my own PC inside the June 2010 SDK called CascadeShadowMapping11. Sure it's DirectX 11, but I am familiar with the SDK and the HLSL variant and was able to trace through what was going on.
I then started augmenting my prototype to include the technique, but soon came to a full stop about 2PM today. Here is where I got to:
Coding the technique from the DBP and Shader code was fine, but two reasons brought me to a halt. Firstly, I ran out of commands, such as producing an offset orthographic matrix and producing a depth only camera. Secondly, I realised that I did not want to create a huge amount of cameras to achieve the effect as at some point it had to integrate nicely into the main engine which has many cameras spoken for.
Changing Gears
Given the above situation, I have decided to switch away from the DBP side and dive directly into the DLL side. That is, write the entire chunk of code responsible for shadow mapping inside the DLL so I can write it in pure C++. Not only will the results be faster, it will be easier to debug and trace though and I will be able to cut and paste some code from the DirectX SDK example to speed up my implementation of the various elements required to achieve great outdoor shadows.
I will bear in mind that the same code will be used for dynamic omni-directional point light shadows, but I think we will all agree that the first major milestone is to have a nice outdoor scene with great shadows cast from the sun that treats every object as both caster and receiver.
Signing Off
It will be exciting to see this up and running, but now I have to dive deeply into some old school DirectX 9 coding. Time to refresh my knowledge about how to create render targets, perform 3D math and talk to my shaders. The good part about this approach is that when I next run the map editor, all I need to do is replace a shader then 'switch the sun shadows on' :)
Let's hope we don't have to wait too long for the sun to appear in Wales! :-)
ReplyDeleteSounds a great approach Lee.. Good luck.
ReplyDeleteGood to see that the rendering will now be done in pure C++. This will really speed up performance and you can do whatever you need for the directx stuff and "simply" run normal DBP Code above it.
ReplyDeleteI can see the real possibilities of that...
I'm the same opinion as Richard, the sun fast appear to has in Wales! :D
Good to see Dark Goblin contributing to these discussions.
ReplyDeleteHe has attempted dynamic shadows in FPSC a number of times and I'm sure he will be very pleased to see it finally being done properly.
I have an unfair advantage over Dark Goblin in that I can dismantle the engine, turn it upside down and change all the rules :) Just spent four hours converting an endless stream of DX11 XNA 3D math to DX9 so some cut and paste code will work. Just finished, phew! Now I have to put in the DX9 versions of all the rendering gubbins...I am actually quite pleased the Welsh Sun has gone in for a bit, it's quite cool in my office around midnight ;)
ReplyDeleteThe more I see of FPSCR, the more the possibilities start flooding into my mind for what we can do with it :D
ReplyDelete