Skeleton LOD idea
Posted: Mon Mar 31, 2014 8:56 pm
Hi, I was thinking on implementing Skeleton LOD for Ogre3D, but I would like to discuss it first.
Problem: I have made some benchmarks, and found out that HW skinning is much faster than SW skinning. However I need to pass an array of bone states to the vertex shader, which requires a hard-coded size globally (We're not using RTShaderSystem). We would like to have animations like fingers, but that would require huge array globally in the shader for all meshes and it requires transforming all bones each frame. However we don't need animations for fingers in the far distance. If you combine it with mesh LOD, than the GPU will cull the unused vertices, which would be processed on CPU, so in far distance HW skinning is a double win.
Solution: We would like to have SW skinning in the near for detailed animations, while having HW skinning with reduced skeleton in the far distance for performance. It should be a fully automatic system without artist intervention. It could be implemented as a user created mesh LOD level generated by MeshUpgrader.
Algorithm: As my first suggestion is something like this: We calculate the bounding spheres for each bone (sphere containing all vertices with given boneID). We first reduce the bones with small bounding spheres. When reducing, we replace the old boneID with the parent boneID in the hierarchy and recalculate weights. This would work out for fingers/hand. The nice thing is that you already have a set of animations and the expected vertex positions for each frame, so you can calculate the error of the reduction accurately.
If you only reduce from the end of the hierarchy (like hands), than you don't need to recalculate animations, but if you reduce from middle of the skeleton, you need to.
Alternatives: Artist could create it in modeling tool, than load it as a manual mesh LOD, but this requires artist work, the artist would do it the same way as the above algorithm and it requires double maintenance. Other way would be to split the body (including bones/animations) into multiple meshes, this would be slower and requires artist work too.
What do you think of this idea?
Do you think it's worth working on?
What kind of problems/disadvantages can you think of?
Problem: I have made some benchmarks, and found out that HW skinning is much faster than SW skinning. However I need to pass an array of bone states to the vertex shader, which requires a hard-coded size globally (We're not using RTShaderSystem). We would like to have animations like fingers, but that would require huge array globally in the shader for all meshes and it requires transforming all bones each frame. However we don't need animations for fingers in the far distance. If you combine it with mesh LOD, than the GPU will cull the unused vertices, which would be processed on CPU, so in far distance HW skinning is a double win.
Solution: We would like to have SW skinning in the near for detailed animations, while having HW skinning with reduced skeleton in the far distance for performance. It should be a fully automatic system without artist intervention. It could be implemented as a user created mesh LOD level generated by MeshUpgrader.
Algorithm: As my first suggestion is something like this: We calculate the bounding spheres for each bone (sphere containing all vertices with given boneID). We first reduce the bones with small bounding spheres. When reducing, we replace the old boneID with the parent boneID in the hierarchy and recalculate weights. This would work out for fingers/hand. The nice thing is that you already have a set of animations and the expected vertex positions for each frame, so you can calculate the error of the reduction accurately.
If you only reduce from the end of the hierarchy (like hands), than you don't need to recalculate animations, but if you reduce from middle of the skeleton, you need to.
Alternatives: Artist could create it in modeling tool, than load it as a manual mesh LOD, but this requires artist work, the artist would do it the same way as the above algorithm and it requires double maintenance. Other way would be to split the body (including bones/animations) into multiple meshes, this would be slower and requires artist work too.
What do you think of this idea?
Do you think it's worth working on?
What kind of problems/disadvantages can you think of?
