Limit on number of vertex influences?

Is there a hard limit on the number of bone-influences for a given vertex? If so, what’s the limit, and what happens when you exceed it in Maya?

  • Josh

There is no hard limit; you can have as many bones influencing a particular vertex as you like, limited only by your CPU power.

Still, there is a point of diminishing returns; the cost of blending animation from n bones is linearly proportional to n, but the visual effect is logarithmic with n. Also, there is a separate cost for each unique combination of n bones x m weights within a particular node. That being said, most ordinary animations can be computed quite rapidly.

If you run your models through egg-optchar, it will (among other optimizations) by default quantize bone influence on each vertex to the nearest multiple of 0.01, which doesn’t generally affect the visual quality of your animation, but in many cases it can vastly reduce the CPU effort it takes to compute the animation.

NB: Panda 1.0 always computes all vertex blending on the CPU. Panda 1.1 will take advantage of hardware support for vertex blending, if available, and if the number of blends required is within the GPU’s capabilities; in other cases, it will still fall back to doing the work on the CPU.


Well, the reason I was asking is that we’re having a recurring problem with mangled animations (animations that look fine in maya, but when you export them and view them in pview, the model does all kinds of weird things.)

i would like to second this problem, as i work on characters for the animateering project, we have the recurring problem of “stray” vertices. the two problems we’ve had are either the mesh totally collapsing on itself, which seemed to be a problem of the mesh still having transformations on it. that was easily solved.

but now we’re having a problem of one or two vertices that either seem to be following a joint that they’re not influenced by, or they seem to move of their own accord, and by move i mean really far out from where they should be.

and i should mention that we’re working in maya 6

Well, skeleton animation is a very complex process. There are lots of places something can go wrong, and when anything at all does go wrong, no matter what it is, the result is generally the same: the model does all kinds of weird things.

In the past, we have had this sort of problem come up due to an obscure bug in Panda, an obscure bug in maya2egg, or an obscure bug in Maya itself. (We’ve fixed all known occurrences of the first two. There is still at least one oustanding known skinning bug within Maya, but its manifestation is a lack of animation, not polygon soup.)

We have also seen this sort of thing happen due to the use of a novel skinning approach that we didn’t know about (or that didn’t exist) when we wrote maya2egg.

Another class of problem is an unusual model property that is not supported by maya2egg, but is not identified or reported as a warning. Usually, these are things that the maya2egg writer simply didn’t expect to happen, for instance, local static transforms on an animated mesh. These are arguably bugs in maya2egg, but they have easy workarounds, once they are identified. (Please tell us about these sorts of things, though, so we can fix maya2egg for the future–I’d never heard about the problem with transforms on the mesh before.)

Diagnosing this sort of problem is a bit of an art. I’d suggest the following things to try to help track it down:

maya2egg -a pose -sf 1

Pick a particular troublesome frame. Chances are good it will be converted correctly by -a pose, which doesn’t tell you much, but if it comes out looking equally bad, then it indicates there’s a bug within Maya’s internal MGlobal::setFrame() method, or in the way we are iterating through the vertices.

maya2egg -a both -sf 1 -ef 1

Pick the same frame, and extract out just the one frame. This should be as screwed up as before. If it isn’t, check your sanity.

maya2egg -a both -sf 1 -ef 1 -nf 1

Use -nf to specify the same frame you are extracting as the neutral frame. This means the initial, unanimated pose will be the same pose as the animated frame. If this is still screwed up, it means that maya2egg is extracting the static joint positions out differently from the joint animation tables.

egg-optchar -lsv model.egg chan.egg

Ensure that the skeleton animation hierarchy matches the joint hierarchy.

egg-optchar -inplace model.egg chan.egg

Sometimes egg-optchar can repair a damaged animation by correcting mismatching joint hierarchies or by applying the quantization mentioned above.

Also, you can visually inspect an egg file to ensure that the vertex weighting is what you expect it to be. In particularly troublesome cases, it may be helpful to simplify the model to find the smallest model that reproduces a particular problem.


In particularly troublesome cases, it may be helpful to simplify the model to find the smallest model that reproduces a particular problem.

This was the first thing I tried. Here’s what I learned: if you simplify a model after you rig it, it totally confuses maya. The result is that the weights reported by maya are complete garbage. Even the weights reported in the maya “weight editor” are complete nonsense. There’s no question that this a bug in maya. However, it will be perceived as a bug in panda, not maya, since the animation still looks fine in maya, it just looks crazy in panda.

What I would like to do, if it’s possible, is detect this situation in the exporter and print an error message (“you modified the model after you rigged it.”) Would it be hard?

Now that I know this, it’s on to step two of this debugging process.

Sounds like a fine thing to detect automatically. It’s not obvious to me how we could detect it, though. Do you see any viable approach?


I’ll take a look at the Maya API when I get a chance. I’m betting that there’s some way to detect it. I’ll see what I can do.