Submesh invisible when all bone weights are 0

[antony]

I am seeing some strange behaviour here and I would like to check if I am doing something wrong or if this is an Ogre problem.

Try this: convert robot.mesh from Ogre demos archive to XML format, replace all occurrences of weight="1" with weight="0" and convert the XML back to a mesh file. When this mesh file is opened in Ogre mesh viewer, nothing will be displayed. If the matching skeleton file is renamed/removed, the whole mesh will be visible again.

I have tried using this model in one of Ogre demos to rule out the possibility that something is wrong with the mesh viewer, but the results were the same.

If only all occurrences of f. ex. boneindex="17" weight="1" are replaced with boneindex="17" weight="0", then only one part of the robot will be invisible.

I encountered this problem with a mesh where I wanted several submeshes not to be affected by any bones, but I found out that I couldn't see them instead when the mesh was displayed.

[sinbad]

That makes perfect sense. All weights must be normalised if the mesh is skeletally animated, this is a simplifying assumption that allows skeletal animation to be done more efficiently than it would be otherwise. This assumption means that the eventual effect on a vertex per animation must add up to 1.0 (ignoring animation weight, which can be 0). Animation is applied through weighted accumulation, not through averaging (which would require a divide, which is more expensive). Therefore if the total weight is 0, nothing accumulates so the vertex is at the origin. When the weight accumulates to 1.0 the vertex is in the correct position as it would be if the more 'strictly correct' averaging operation was done.

It is possible to get around this in software skinning by special casing the situation where all weights add up to 0 and simply using the original vertex position instead of starting at Vector3::ZERO and accumulating. However, in practice this is not feasible, since hardware skinning cannot make this kind of decision, since 'branching' in vertex programs is only supported on high-end cards.

So I'm afraid you must think about this another way. The simplest is to create another bone which is never affected by any animation and binding the vertices you don't want to move to that with a weight of 1.0.

[antony]

I see. Thank you for the reply, the workaround should do the trick.

This also explains why the robot behaves the same way when weights for all vertices are 1 and when they all are f. ex. 0.01.