Why would animation of subparts get out of sync on WebGL only?

I have a simple humanoid figure, which I rigged, imported as Humanoid, threw into a scene, and then added a couple of standard Mecanim animations (idle-shift and wave). It looks fine in the editor:



But when I build for WebGL, scary things happen:



Wtf?!? And here's the really weird thing... yes, the eyeballs are a separate submesh, but the helment is not. The helment is One with the rest of the head. I am not making this up:



And as far as I can tell, there is little to no difference between how the helmet part of this mesh is bound to the bones, and how the face is bound to the bones (as indicated by the color above).

So, how is the scary effect with the helmet seen at all? And why would this effect show up in WebGL but not in the editor?

 

Incidentally, playing around with the bones in the editor, I can't find any way to separate the helmet (or eyes for that matter) from the face. They stay perfectly in sync, no matter how I rotate, translate, and scale the head and neck bones.

Of course this is in the editor... I'll have to write some custom test code (with a very long build/test cycle!) to test this in the build. Any ideas in the meanwhile will be greatly appreciated.

 

I'm a bit surprised such a serious bug is met with chirping crickets rather than torches and pitchforks. But, maybe it's the wrong forum... trying again over in WebGL.

 

So I have noticed that there are extra optimizations that happen in Web GL automatically. Certainly you must have your max influences to a maximum of 4, but also even fractions of skin weight that don't belong on the vertex can get optimized to reflect bad skinning that is not visible in the source file. Finally if you have any extra bones you need to make sure that they are included in the calculation by creating an avatar mask than includes them and that each of your animations are using the animation mask.

 

OK, I appreciate the attempt to help. I know I don't have any extra bones — it is in fact a pretty minimal skeleton.

I don't understand these comments. Can you explain in a little more detail?

Thanks,
- Joe

 

Hey, here's some progress, of a sort... I switched from Unity 5.4.1 to Unity 5.5, and now I'm seeing the same bug in the editor! Hooray, I guess. It appears that, despite everything in the head being bound to the head bone in Cheetah3d, the face polygons completely ignore any movements to the head bone (except for one polygon under the chin, for some reason). This is easy to see when I rotate the Head and drag it off to the side:



Obviously this doesn't happen in my 3D modeling app, nor in Unity 5.4.1, except in WebGL. But hooray, this is the Animation forum, not the WebGL forum, because in 5.5 it's a more general problem.

Here's another clue, perhaps. The Head bone is connected to the Upper Spine bone (cue song). And when I move Upper Spine, the face does move (as does the hair/helmet and eyeballs, presumably because of the child Head bone).

So, it's acting as if these face polygons are weighted solely to Upper Spine, and not to Head at all... but that's not what I see in the modeling app. Is there some reason Unity would "optimize" away the vertex weights in this manner? Or some way I can check whether the problem really is in the model?

 

I tried re-binding the head mesh, this time offering only the Upper Spine and Head bones (in the Skeleton tag in my modeler), so there should be no possibility of having more than two weights per vertex. Still no dice. It does look a little different — there's now a substantial portion of the chin that moves with the head bone, but the rest of the face still does not.

I wondered if the mesh were simply too big or complex for Unity (5.5) to handle properly, but it seems pretty modest to me:



I'm quite at a loss as to why it would be misbehaving this way.

 

I have no experience with Cheeta3D whatsoever. But, this thing can happen in Blender if the bones aren't parented properly. So if you've got a bone for controlling the mouth, and that's not a child of the rest of the face, you can get these kinds of horrors.

If not, I suggest reporting this as a bug! The animation team visits these forums infrequently, but generally replies to a lot of threads when they come by. @Mecanim-Dev and @DavidGeoffroy are both listed as not having been logged on since last Wednesday.

 

Yeah, it's not that, at least not exactly. I have a Upper Spine bone, as the parent of the Head bone, and that's it (in that part of the tree) — there are no other bones in the head. (But yeah, if there were, and it weren't parented, I can totally see how this sort of thing would be expected behavior.)

But I did discover last night that if I increase the weight to the Head bone, then it seems to work. These vertices were previously about equally weighted between Head and Upper Spine. If I make it all Head, then they move with the head bone. I still have no clue why the face would act different from the helmet, though (both had the same weights as far as I could tell).

OK. I'll strip it down today to a simple example and report it.

 

Sorry for the delay in responding to your question. When binding a skin to a mesh there is a max influences setting. This means that a single vertex can be affected by a maximum of X number of joints. Unity only supports up to 4 joints per vertex. So when binding a skeleton you should insure that the max influences are 4 or less. I also know nothing about Cheeta3D but in Maya there is a window called the component editor in which you can view the vertex smooth skin weighting by vertex. If there is even a fraction of a percentage of skin weight that is miss assigned you may end up with an optimization that will favor the entirely wrong joint. I have seen this happen in my own work.

Also, a mesh with any history on it can cause issues too. Have you checked the input graph on your model? Insure that the only nodes on it are related to deformations and not anything from the build.

 

did u ever get a fix for this?
I have the same problem, but when trying to capture frame sequences, looks great in game view, but the child objects are ahead of the animation in the frame sequences.