- The shadows are done by rendering a depth pass into an atlas of cascades. The light matrix for each is computed and stored in a constant buffer. Later, during the lighting pass of the deferred renderer, the shadow map is referenced. The implementation runs a PCF kernel over the shadow evaluation for each fragment, for both of the cascades that it straddles. The results are then linearly interpolated to give a nice smooth border between cascades. Refer to MJP's blog for more info on the algorithm.
- For HDR, I tried a bunch of different tone mapping filters and couldn't get it to look right. When I switched to the Uncharted 2 method, however, it just clicked. I really like how it preserves contrast and avoids the ugly middle gray tone.
- FXAA was easy to drop in. I can see how it's a hack though. I'm still noticing tons of temporal aliasing (obviously, since the algorithm is purely spacial), as well as some aliasing within textures. Given what it has to work with, though, I think it does a decent job. I'm really interested in seeing how TXAA looks/performs.
- My goodness, if you have never used a physically based BRDF like Cook-Torrance, and are still in the dark ages of Blinn-Phong for everything, please give it a try. There is such a difference. Cook-Torrance is a microfacet based BRDF that uses analytical approximations based on probability to compute self-occlusion within a surface, as well as proper Fresnel reflection. There are other physically based models that I'm sure are great too--I'm still learning about them--but Cook-Torrance is impressive.
- I also dropped in a procedural sky that I found off of one of MJP's samples. The annoying thing about having a pure black background with HDR is that is interprets it as absolute deep space black, causing overexposure of everything in the frame.
In terms of the tank, I'm still having to work with a hacked up distance joint chain to keep the wheels in sync with each other. Basically, for every neighboring wheel on a given side, I link them at the 0 degree and 90 degree mark, like so:
That way, there's always a (near) tangential torque applied to the wheel, avoiding lockups or instability. I found out today that you can jack up the iteration count for the solver on a constraint-by-constraint basis. Since the distance constraints are pretty cheap, I set a high value and didn't notice a performance hit. This tightened up the simulation quite a bit, which is a relief. I did the same thing for the tank barrel, since the forces rotating it to face the camera were causing it to jumble around loosely. Not exactly tank-like behavior if you ask me.
I also implemented an over-the-shoulder third person camera. You can orbit around the tank, within reasonably constrained angles, and the turret/barrel will follow you. I got to do lots of fun 3D math calculating the angles for the turret and barrel within their respective local frames. Currently the camera doesn't do any ray casting to detect/collide with objects, but that's on the radar. That's going to be a bit of a tough issue, since camera collision can be a nightmare for the player, especially if it's contorting itself into corners of the level rather than just fading out objects. I'll have to look into how other commercial games are handling it.
I'm finally understanding how to use matrices to transform between spaces, and perform projections via the dot product. I bought a book the other day on how commercial physics engines work, and I'm slated to take Calc III and Differential Equations this coming school year. I'm actually excited to learn all this stuff! It's been frustrating looking into the bowels of Bullet Physics and not having a clue how the solvers work. Hopefully by the end of the year I'll understand it much better.
I believe the next task I will conquer is getting the tank to fire something! I'll probably release another demo sometime around then. Until then, lots of screenshots!
Remove ads and support GameDev.net for only $3. Learn more: The New GDNet+: No Ads!