Hm... You know, maybe I should reorder my plane checks. I'm thinking that it's far less likely for vertices to be above or below the top and bottom planes of the light view frustrums, and much more likely for them to be to the left or right of the sides of the view frustrums, because worlds generally are oriented horizontally.
Still, I'm sure it wouldn't improve the speed much. It's rendering those darn shadow maps which is is the major slowdown.
If I knew more people were actually using my shadow system in their games and what sorts of situations they were using them in then that would help and encourage me to optimize it more.
But so far nobody's said to me that they have any problem with the speed, except for special cases where they do crazy stuff like make every tree on a golf course cast a shadow. :-)
I think it might be possible to optimize the shadow map rendering a little more than it currently is, but I'm not sure.
What I do to opmimize that is minimize the numebr of times I need to render a new map. I do this by calculating how much the angle between the caster and light source have changed, even taking into account rotation of the caster. Unfortunately I can't optimize for animated meshes in this way.
I could possibly create a more optimal routine so it has to update the shadow map even less often, but it's hard. I think that I could cancel out the entire roll part of the equation by rotating the texture now that I think of it. That would just leave changes in pitch and yaw as causing the system to need to render a new shadow map. I think though that for most cases that would not really have much effect on the number of times the map needs to be updated.
Perhaps another solution would be blending shadow maps. To do that I would need to forward predict where I think the entity will be in the future, and then blend the two shadow maps together to smooth the motion and hide snapping from one orientation to another. But I don't see how to blend the maps with alpha without doubling the number of polygons that need to be created for the shadow mesh. The number of polygons in the shadow meshes are a source of a big speed hit too. So it's not a good idea to cast shadows onto highly detailed meshes such that a lot of the poygons in the mesh are in shadow at the same time.
I suppose it might be possible too to reduce the number of polygons which need to be created each frame for the shadows. Perhaps it would be better to simply add polygons for two frames and only clear the whole thing every other frame instead. The extra polygons would not cause any problems.
The thing is this is still an imperfect solution, and it would jsut make the whole system even MORE complicated and difficult to modify than it is already. It was so nice when all I did was a 2D clipping operation and I transformed everyhting into light space with a call to rotatemesh.
Still, I'm sure it wouldn't improve the speed much. It's rendering those darn shadow maps which is is the major slowdown.
If I knew more people were actually using my shadow system in their games and what sorts of situations they were using them in then that would help and encourage me to optimize it more.
But so far nobody's said to me that they have any problem with the speed, except for special cases where they do crazy stuff like make every tree on a golf course cast a shadow. :-)
I think it might be possible to optimize the shadow map rendering a little more than it currently is, but I'm not sure.
What I do to opmimize that is minimize the numebr of times I need to render a new map. I do this by calculating how much the angle between the caster and light source have changed, even taking into account rotation of the caster. Unfortunately I can't optimize for animated meshes in this way.
I could possibly create a more optimal routine so it has to update the shadow map even less often, but it's hard. I think that I could cancel out the entire roll part of the equation by rotating the texture now that I think of it. That would just leave changes in pitch and yaw as causing the system to need to render a new shadow map. I think though that for most cases that would not really have much effect on the number of times the map needs to be updated.
Perhaps another solution would be blending shadow maps. To do that I would need to forward predict where I think the entity will be in the future, and then blend the two shadow maps together to smooth the motion and hide snapping from one orientation to another. But I don't see how to blend the maps with alpha without doubling the number of polygons that need to be created for the shadow mesh. The number of polygons in the shadow meshes are a source of a big speed hit too. So it's not a good idea to cast shadows onto highly detailed meshes such that a lot of the poygons in the mesh are in shadow at the same time.
I suppose it might be possible too to reduce the number of polygons which need to be created each frame for the shadows. Perhaps it would be better to simply add polygons for two frames and only clear the whole thing every other frame instead. The extra polygons would not cause any problems.
The thing is this is still an imperfect solution, and it would jsut make the whole system even MORE complicated and difficult to modify than it is already. It was so nice when all I did was a 2D clipping operation and I transformed everyhting into light space with a call to rotatemesh.