Hmm.. interesting. I just added a little profiling code in my shadow system, and you know those nested IFs which check each triangle against the shadow frustrum?
Well, after doing my test I determined that in that one-light scene in my demo, there's between 1200-3000 triangles tested each frame. And on average there are 5-7 multiplies done per triangle in the plane tests.
Another test displayed the scene with no shadows at all, and it ran about 140fps. But if fake shadows were added, fake shadows being simply, projected textures, no texture rendering, the fps dropped to 90. As I turned wait for refresh off, these are true fps changes, not the result of a small change causing a wait for refresh.
Now framerate drops have to be taken with a grain of salt. At high framerates, even a small drop in speed can result ina large drop in framerate because the number of milliseconds between each frame is small.
So you divide 1000 milliseconds by both values, and then subtract one from the other. And that tells me that approximately 3 milliseconds are being spent in the code which does the projection and culling. Which is the amount of time which one frame would take to draw at 333fps. Sounds better that way, doesn't it? :-)
But that's not fast enough for me. It shouldn't be taking three milliseconds. It should be taking ONE!
I think I might have a solution though. If the average triangle is requiring 5-6 muls per frame, before being culled, then surely I can speed that up. Right now I'm testing using a shadow frustrum comprised of several planes. I wonder though, if I could trivially reject most polygons with a simpler check, like a sphere to line check, before they even get to this function.
I'll have to see if I can find a mathematically simple way to generate a containing sphere for a tri.
Well, after doing my test I determined that in that one-light scene in my demo, there's between 1200-3000 triangles tested each frame. And on average there are 5-7 multiplies done per triangle in the plane tests.
Another test displayed the scene with no shadows at all, and it ran about 140fps. But if fake shadows were added, fake shadows being simply, projected textures, no texture rendering, the fps dropped to 90. As I turned wait for refresh off, these are true fps changes, not the result of a small change causing a wait for refresh.
Now framerate drops have to be taken with a grain of salt. At high framerates, even a small drop in speed can result ina large drop in framerate because the number of milliseconds between each frame is small.
So you divide 1000 milliseconds by both values, and then subtract one from the other. And that tells me that approximately 3 milliseconds are being spent in the code which does the projection and culling. Which is the amount of time which one frame would take to draw at 333fps. Sounds better that way, doesn't it? :-)
But that's not fast enough for me. It shouldn't be taking three milliseconds. It should be taking ONE!
I think I might have a solution though. If the average triangle is requiring 5-6 muls per frame, before being culled, then surely I can speed that up. Right now I'm testing using a shadow frustrum comprised of several planes. I wonder though, if I could trivially reject most polygons with a simpler check, like a sphere to line check, before they even get to this function.
I'll have to see if I can find a mathematically simple way to generate a containing sphere for a tri.