Maximum amount of bones in an ogre skeletal animation (bug or feature)?

Hy there,



I found that the BoneAnimationLoader can load maximally 128 bones. But the underlying index-buffer is a byte-buffer, so we could store 256 bone-indexes. But Java treats a byte as signed.



I noticed that problem on a model with a 135 bones skeleton, where I suddenly had negative index-buffer entries.

It shouldn't be a problem to fix this issue with using shorts until the value gets written to the buffer, instead of byte, which implicitly converts the parsed number from the xml file to a signed byte.


  • Is there another reason why it is not possible to have 256 bones animated ?
  • Is this a bug or has that implementation a reason ?



    Thanx

This might be a simple fix :slight_smile:

In the class MeshAnimationController, method softwareSkinUpdate(), find this code:

// iterate vertices and apply skinning transform for each effecting bone
        for (int vert = 0; vert < mesh.getVertexCount(); vert++){
            vt.x = vb.get();
            vt.y = vb.get();
            vt.z = vb.get();
            nm.x = nb.get();
            nm.y = nb.get();
            nm.z = nb.get();
            resultVert.x = resultVert.y = resultVert.z = 0;
            resultNorm.x = resultNorm.y = resultNorm.z = 0;

            for (int w = 0; w < maxWeightsPerVert; w++){
                float weight = wb.get();
                Matrix4f mat = offsetMatrices[ib.get()];


In the line where it says "Matrix4f mat = offsetMatrices[ib.get()];"
change it to "Matrix4f mat = offsetMatrices[ib.get() & 0xFF];" without quotes, see if it helps.

In the line where it says "Matrix4f mat = offsetMatrices[ib.get()];"
change it to "Matrix4f mat = offsetMatrices[ib.get() & 0xFF];" without quotes, see if it helps.


This will help. Nice solution, short ;)

For those who don't see why the solution works:

I had to write a test for me, to understand why it works after that cast in the BoneAnimationLoader (which I suspected to be 'lossy'). It seems Java has a bit a strange behavior when casting from an integer to a byte. When we stay in the positive range 0-255, the cast does not involve the sign bit. So the information is completely existent in the byte. I expected it to always use the sign bit for sign purpose, as a byte is by definition always signed. But Java seems to do that just for the case of negative numbers...