Broomstick - bone number limitation

[chlor...@gmail.com]

Hi,
I have a MD5 file with 54 bones. I add on my stage a lot of this
object.
My md5 have sub object. When I remove few bones of subobjects my stage
can render. But with 54 bones I have error at :

context.drawTriangles(renderable.getIndexBuffer(context,
contextIndex), 0, renderable.numTriangles);

in MaterialPassBase.as (index 0 out of range)

What is the limit for bones ?

(sorry for my english)

Thx.

[richardolsson]

There is no limits to the number of bones that can be used in a model.
However, there is a limit to how many can be calculated on the GPU.
For models with large numbers of bones, the animation should revert
back to being calculated on CPU.

There is currently a known bug in the automatic test for this, which
means that the animation system will not always automatically figure
out that animation needs to happen on CPU. So it tries running it on
GPU and that's when this fail.

Solve it by setting the "forceCPU" constructor parameter to true when
you create your SkeletonAnimation, to bypass the faulty test and
always run the animation on CPU. If you do not see the forceCPU
parameter, you need to get the latest code from GitHub.


Cheers
/R


On May 23, 4:11 pm, "chlorid...@gmail.com" <chlorid...@gmail.com>
wrote:

[themightyatom]

Is there an example using the SkeletonAnimation class?
I'm using SkeletonAnimationSequence and it doesn't have a forceCPU
option.

Richard, have you any other ideas as to why the mesh dissappears and
reappears in this example?
The source code is all there, based on the MD5 loader example from the
Github branch.

I was wondering if it's running out of room on GPU, and "dying nice"
rather than exploding
as it did in the latest incubator and the previous Broomstick library.

It does the exact same thing in the may 12th AND previous version of
incubator, when compiled
with the Github Broomstick. With the pre- may 12th incubator, and the
AwaySVN, no such problem.
I've tried changing Lens, and near/far parameters with no luck.
The fault is consistent over 3 different machines/graphic cards I've
tested on.

Cheers,

Pete