@Irreversible
To be honest I probably won't be implementing any bullet-time effects, but I will have changeable game speed, which could drop the game speed to a very low value. I still think doing the interpolation in real-time is more accurate, since even if the animation speed matches the game FPS it would still be more accurate to do the interpolation for the exact time. Maybe it really is an unnoticeable difference in 99.999% of all cases. I might not be able to afford the additional cost of lots of slerps each frame even with multithreaded joint interpolation, so getting rid of it and just keeping the precomputed bone matrices in GPU memory might be the best choice anyway. Memory is something I can afford to use more of, so precomputing to about 60-120 frames per second should give enough smoothness in all possible cases. Now I know what the animation quality setting does in games... >_>
I am actually making a real-time strategy game, so I might be having about 100 units on the screen at the same time.
@Hodgman
I've read up quite a lot on GPU skinning and I have more than enough experience with shaders to implement this. Storing the joint translation and orientation in a matrix is probably the best idea as it eliminates the weight positions that would have to be stored per vertex otherwise. I'm loading MD5 meshes and animations, so the maximum number of weights per vertex that format supports is 4, so I'll just stick with that. It also doesn't support joint scales, so that simplifies it further. If using MD5 is a bad idea for some reason, please stop me now!!!
24 frames per second comes from the specific model I'm animating.
In other news, I just managed to get my software skinning working, so Bob is (happily?) waving his lantern around. FPS dropped from 83 FPS to 14 due to the skinning being done on the CPU (well, with 1000 instances though xD). Next I'll move the skinning to a vertex shader but keep joint interpolation on the CPU which is was the standard approach, right? Lastly I'll try a pure GPU solution with precomputed joints stored in a texture.
EDIT: My software implementation is obviously bottlenecked by the skinning. Skinning takes about 65% of the frame time at the moment, possibly a lot more if you count methods that are shared with other parts of the game.
Show differencesHistory of post edits
#1theagentd
Posted 20 January 2012 - 08:20 AM
@Irreversible
To be honest I probably won't be implementing any bullet-time effects, but I will have changeable game speed, which could drop the game speed to a very low value. I still think doing the interpolation in real-time is more accurate, since even if the animation speed matches the game FPS it would still be more accurate to do the interpolation for the exact time. Maybe it really is an unnoticeable difference in 99.999% of all cases. I might not be able to afford the additional cost of lots of slerps each frame even with multithreaded joint interpolation, so getting rid of it and just keeping the precomputed bone matrices in GPU memory might be the best choice anyway. Memory is something I can afford to use more of, so precomputing to about 60-120 frames per second should give enough smoothness in all possible cases. Now I know what the animation quality setting does in games... >_>
I am actually making a real-time strategy game, so I might be having about 100 units on the screen at the same time.
@Hodgman
I've read up quite a lot on GPU skinning and I have more than enough experience with shaders to implement this. Storing the joint translation and orientation in a matrix is probably the best idea as it eliminates the weight positions that would have to be stored per vertex otherwise. I'm loading MD5 meshes and animations, so the maximum number of weights per vertex that format supports is 4, so I'll just stick with that. It also doesn't support joint scales, so that simplifies it further. If using MD5 is a bad idea for some reason, please stop me now!!!
24 frames per second comes from the specific model I'm animating.
In other news, I just managed to get my software skinning working, so Bob is (happily?) waving his lantern around. FPS dropped from 83 FPS to 14 due to the skinning being done on the CPU (well, with 1000 instances though xD). Next I'll move the skinning to a vertex shader but keep joint interpolation on the CPU which is was the standard approach, right? Lastly I'll try a pure GPU solution with precomputed joints stored in a texture.
To be honest I probably won't be implementing any bullet-time effects, but I will have changeable game speed, which could drop the game speed to a very low value. I still think doing the interpolation in real-time is more accurate, since even if the animation speed matches the game FPS it would still be more accurate to do the interpolation for the exact time. Maybe it really is an unnoticeable difference in 99.999% of all cases. I might not be able to afford the additional cost of lots of slerps each frame even with multithreaded joint interpolation, so getting rid of it and just keeping the precomputed bone matrices in GPU memory might be the best choice anyway. Memory is something I can afford to use more of, so precomputing to about 60-120 frames per second should give enough smoothness in all possible cases. Now I know what the animation quality setting does in games... >_>
I am actually making a real-time strategy game, so I might be having about 100 units on the screen at the same time.
@Hodgman
I've read up quite a lot on GPU skinning and I have more than enough experience with shaders to implement this. Storing the joint translation and orientation in a matrix is probably the best idea as it eliminates the weight positions that would have to be stored per vertex otherwise. I'm loading MD5 meshes and animations, so the maximum number of weights per vertex that format supports is 4, so I'll just stick with that. It also doesn't support joint scales, so that simplifies it further. If using MD5 is a bad idea for some reason, please stop me now!!!
24 frames per second comes from the specific model I'm animating.
In other news, I just managed to get my software skinning working, so Bob is (happily?) waving his lantern around. FPS dropped from 83 FPS to 14 due to the skinning being done on the CPU (well, with 1000 instances though xD). Next I'll move the skinning to a vertex shader but keep joint interpolation on the CPU which is was the standard approach, right? Lastly I'll try a pure GPU solution with precomputed joints stored in a texture.