Shadow Mesh For Player

[Ishtvan]

Maybe everyone knew this already, but I just found out today that the player shadow can cause a major hit to FPS. That makes sense when you think about it, since the player is probably our most highpoly model and it's currently calculating the shadow for every single face of it.

 

I tried this experiment: Go to torchtest.map, light three lights, move them close together. You now have three overlapping lights. Stand infront of them, with g_showplayershadow set to 0. I get 60 FPS. Then I turn g_showplayershadow on, and get 15-20 FPS! That makes quite a difference.

 

Just to see what kind of hit we take for calculating the shadow from 3 lights on any item vs. no shadow casting items, I spawned a crate in the same place I was standing (with my own shadow off), and that didn't cause a noticeable drop. So I think we could really benefit from having a shadow mesh on the player, and all AI. It could make a huge difference in performance, since a lot of maps end up having a few shadow-casting lights overlapping, unavoidably.

[Domarius]

Making shadow meshes for all models (including the player) is something on the drawing board anyway isn't it?

[Ishtvan]

Hopefully. It would be nice to get it done soon, since it will let us get over that performance bottleneck and figure out what the next one is. Also probably better to do it soon if it requires redoing rigging & animating work. I know it's not usually fun to redo stuff, but this seems called for.

[ascottk]

Hopefully. It would be nice to get it done soon, since it will let us get over that performance bottleneck and figure out what the next one is. Also probably better to do it soon if it requires redoing rigging & animating work. I know it's not usually fun to redo stuff, but this seems called for.

The AI's mesh itself doesn't need reregging & the animations don't need to be touched but the shadow meshes do need to be rigged (after getting a suitable low poly conversion).

[Springheel]

SD also did some tests that suggested that shadow meshes wouldn't really save THAT much fps anyway, didn't he? We do plan on adding them later, as an otpimising thing, but I don't think they're critical right now.

[SneaksieDave]

Yep here: http://forums.thedarkmod.com/index.php?showtopic=5211

 

I was going to link it, but didn't want to steer anyone away from a desire to make some shadow meshes. Looks like there's probably a 30% increase? Every bit helps.

[Ishtvan]

Yep here: http://forums.thedarkmod.com/index.php?showtopic=5211

 

I was going to link it, but didn't want to steer anyone away from a desire to make some shadow meshes. Looks like there's probably a 30% increase? Every bit helps.

In this case with just the player it was a 300% increase going from player shadow to no player shadow. I can't explain why, but it could have something to do with the fact that our player is the most highpoly of our AI. I forget what the exact numbers were, but I remember Odd saying it was pretty high since there's only one of them.

 

In Dave's test, the fact that it was 16 FPS with no shadows means that some other things are definitely going on in both with/without shadow cases, so shadows are not the bottleneck in that case, but it is definitely limiting us if shadows alone can drop the FPS from 60 to 20. For example, in the stoptime case, where pretty much only rendering is happening, FPS goes from 45 to 60 based on shadows. That is significant and argues for putting in shadow meshes.

 

What I'm trying to say is, shadows can potentially drop FPS from 60 to 20, with nothing else going on. In Dave's tests, there may be some other bottleneck putting us at 16 FPS max, but that doesn't mean we shouldn't fix the shadows. Let's say we hypothetically fix the other bottleneck (whatever it is). If we don't fix shadows, and they also limit us at 20 FPS, we'll only see FPS go to 20 with shadows when we fix the other limit, and you could say "oh, I guess that fix didn't have much effect," and be wrong, because we just went from limited by something else to limited by shadow calculations. But if we fixed both the other issue and shadows, FPS would go from 12 to 60... it takes fixing both.

 

We have to try and fix all of these issues one by one, because otherwise we could spend forever trying to guess which one is most important, if we never fix the ones we think are less important. They're all acting together to limit FPS. If shadows by themselves can cap FPS at 20 in my test, or 45 in Dave's rendering-only test, that means it should be fixed IMO, so that now our FPS can potentially go up much higher as we identify other problems and test them. [EDIT: If it's in the SDK we can of course profile it, but can't really do that for stuff in the render engine]

 

I'm not trying to belittle Dave's test, I think it's a good thing to try turning shadows on and off, it's a good way to gauge the effect of the shadow calculations. However, I would argue that the fact that it capped us out at 45 FPS with all other processes stopped is a strong argument for shadow meshes.

[sparhawk]

I think shadow meshes are definitely worht to be doing, as shadow calculation definitely needs additional renderpasses. And when we have multiple AIs on screen and all the other stuff going on, then it will have some effect. But this can best be shown with realistic maps. As long as we only use small testmaps then the effects may be indeed insignifcant.

 

What I wonder though is, if a shadow mesh is used, then wouldn't it be animated as well? AFAIK it would work like this. If a model doesn't have a shadow mesh the actual model is to be rendered from the perspective of the lightsource. So there is only one animation going on, but multiple rendering. If a shadow mesh exists, then it would have to be also animated, so that the animation is performed on the main model, and probalby the same animation is to be applied to the shadow mesh as well, before the shadow can be calculated. Is this understanding correct? If so, it means that for static models the shadow mesh would definitely have an advantage. For animated models, it might depend on the complexity of the model wether a shadow mesh pays off or not. I'm just guessing here, so I might be wrong, but I don't see how the shadow would otherwise match the pose of the actual model.

[Ishtvan]

What I wonder though is, if a shadow mesh is used, then wouldn't it be animated as well? AFAIK it would work like this. If a model doesn't have a shadow mesh the actual model is to be rendered from the perspective of the lightsource. So there is only one animation going on, but multiple rendering. If a shadow mesh exists, then it would have to be also animated, so that the animation is performed on the main model, and probalby the same animation is to be applied to the shadow mesh as well, before the shadow can be calculated. Is this understanding correct? If so, it means that for static models the shadow mesh would definitely have an advantage. For animated models, it might depend on the complexity of the model wether a shadow mesh pays off or not. I'm just guessing here, so I might be wrong, but I don't see how the shadow would otherwise match the pose of the actual model.

That sounds reasonable. I don't know if the shadow calc. actually requires another GPU render from the perspective of the light, or how it does it. About the animating though, I don't think the shadow mesh will require any additional joints, so you wouldn't be adding more joints to animate, you would only be adding more geometry to keep oriented with the joints (basically multiply all the verts by a quat that the animator generates for the joint at that point in time?). I don't know what that translates to in performance. You might be right that it could be worse in some cases.

[OrbWeaver]

That sounds reasonable. I don't know if the shadow calc. actually requires another GPU render from the perspective of the light, or how it does it.

 

It requires two additional passes per light (although they are only writing to the stencil buffer, no fragment shaders or anything), plus the CPU-based shadow volume calculation. That's why there is such a performance impact.

 

About the animating though, I don't think the shadow mesh will require any additional joints, so you wouldn't be adding more joints to animate, you would only be adding more geometry to keep oriented with the joints (basically multiply all the verts by a quat that the animator generates for the joint at that point in time?). I don't know what that translates to in performance. You might be right that it could be worse in some cases.

 

Indeed, you are just adding more geometry to the mesh. Sparhawk is correct though that they could be a performance impact in using this additional geometry; whether this outweighs the performance gain of simplified shadow calculation is something that can only be determined through testing.

[Springheel]

Just to be clear, we ARE planning on doing shadow-meshes for the AI (and presumably the player as well, even though we're not officially supporting the player shadow), for TDM 1.0. I'm not questioning the need for it, I'm just saying we don't need to do it this instant.

[ascottk]

The shadowmesh's rigging doesn't need to be as fancy as the the regular meshes & it's pretty easy to add other meshes to an existing rig. In Maya, select the origin jpint & go to the bindpose* (*=numbered pose) tab in the attribute editor. Uncheck "Bind Pose" then it'll be ready to accept a new mesh for rigging.

 

To get the mesh to low poly, I found VIZup & it does a great job of reducing polys. It does a better job than Maya or Max. Here's VIZup 1.8 I put on ftp (the last freeware version, vrml (*.wrl) only). Deep exploration can convert these just fine.

http://208.49.149.118/TheDarkMod/vizup.exe

[ascottk]

BTW, Isht, as you well noticed, the thief now has a shadowmesh & a few . . . well most . . . other AI