Modulative texture shadows are done, they now work with directional lights and spot lights, and have some nice fade-out features meaning that the shadows fade out in the distance for directional lights, and fade out around the edges of the spotlight range for spotlights - the latter is really important since the clamping on the shadow texture would cause horrible ‘smears’ to appear on other geometry when casters hit the edge of the texture.
Texture shadows are fundamentally working, as you can see from this forum topic. I still have to sort out the blending so that it’s not just black & white but composited on top of the existing shadow receivers. Also, the positioning of the projector / render to texture camera is not automatic yet, I’ll have to sort that out. GL projection appears to be upside down right now, which looks like a texture matrix issue.
The last few days have been a bit fragmented, I’ve added a few additional optimisations like being able to make shadows turn off at a given distance, and I’ve implemented the D3D versions of projective textures. Ogre could actually do projective textures before, it was just a little awkward. Now you can just attach a Frustum object to the texture unit, and it does it all for you, which is pretty slick.
It’s been a good couple of days 😀 temas indeed did fix the GL modulative shadows issue. And I woke up this morning with one of those ‘perfect clarity’ moments, where I just knew what the cause of the remaining 2 GL shadow bugs were. REM sleep, I owe you one. The tough part was going through the whole day at work knowing what it was, but not being able to test it until I got home.
Well, I fixed the GL light state problem, and temas seems to be close to fixing the manual blend problem so we’re getting there on GL shadow support. The outstanding issues (and these are GL only, D3D does not experience them) are: Animated meshes have problems with shadow extrusion. — Both software and hardware skinned meshes have extrusion artefacts with more than 1 submesh (test case: ninja.mesh). Software blended meshes with one submesh work fine
Today I implemented additive lighting & shadows, ie a more realistic (and more expensive) technique where multiple lights and their shadows can be combined more realistically. You can see my initial results in this screenshot. Basically we have to split or categorise every pass into an ambient, per-light or decal pass, and build up the lighting in the scene by rendering the ambient passes, then rendering per light whilst masking out shadowed areas, then render the textures over the top.
Heh, I guess that’ll teach me to speak too soon. I was so sure my new shadow culling system was working last Tuesday, but in fact there was a bug which caused shadows to be prematurely culled. I spent ages tracking it down, thinking it was in the cull volume building, so I added debug volumes and tried lots of things - in the end it was a simple error in Frustum::getWorldCorners which I hadn’t noticed before because it had no discernable effect on previous usages of it.
Wow, something actually went quicker than I expected for a change! 😀Tonight I polished off the shadow caster elimination code I’ve had in my head for a while - previously the location of shadow casters was pretty basic - since obviously objects which are not in the camera’s frustum can still cast shadows into the view there is an issue of how you efficiently locate all objects which can be casting visible shadows.
I finally nailed some of the more annoying problems I’ve had on my TODO list - it turns out the lack of shadows when hardware skinning (which actually caused GL to crash in the driver - yuck), were due to a feature I put in, but forgot about. :/ I wanted to suppress the update of a shadow buffer to the hardware version when only doing the software vertex blend because of the shadow, because otherwise you would unnecessarily upload the buffer twice.
Manual meshes were not prepping for volume constructions properly, and there were some issues with prepping meshes which used shared vertex buffers for multiple components. These are now fixed. I still have a number of issues with animated meshes which I’m sure are related - that is the hardware skinning disappearing shadow problem, and the D3D9-fullscreen-software-blend glitch, neither of which I’ve been ableto explain despite detailed tracing through the code. I have also found that if I prepare an animated mesh for volume construction more than once, I get random crashes a few frames later, which suggests there is a buffer overrun somewhere.