Multiple Skin Clusters On One Mesh

[shon]

Hello, all =) This is my first post here, but I've found this place through Google many times.

My question is this: Is it possible to get the correct weights for polygon meshes which were bound to a skeleton and then subsequently combined?

For example, if you create a two polygon spheres, and a chain of 2 joints within each, and then bound each one to their respective skin, the weights returned from MFnSkinCluster are correct. But if you select the two spheres and then use Polygons->Combine, the skin clusters are not combined so you now have two skin clusters affecting the same mesh.

I was able to get a list of all the skin clusters affecting the newly combined mesh, and the weight data seems to be there, but the problem is, even though I'm passing an array of components which are supposed to correspond to the vertices on the visible bound mesh, and none of the functions are complaining by giving me a bad MStatus, the returned vertex weights for both spheres always seem to start at vertex zero. So I get double weights for one sphere, and no weights for the other.

I noticed that the paint weights tool doesn't work on such combined meshes, so I'm wondering if it's even possible.

Has anyone else ever experienced this issue and found a solution? Thanks!

--Shon

[rob-bateman]

hmm, just tested this in my export code, and it breaks Damn you for informing me about extra work i need to do I'll try to have a look at this somewhen this week and see if i can find some form of solution.

\edit
Damn. The same also applies to any poly modifier node that add's or removes vertices from a mesh. I can just about handle it after a quick bit of hacking, but it requires me to use and MItDependencyGraph to iterate back up the graph from the output mesh, and then ignore any node that does nasty things to meshes. ie, in the case of the polyUnite, i can export the two input meshes as seperate objects. In the case of polySmooth nodes, i can ignore the smoothed version and instead export the original. There is however an obvious problem. If the modeller made changes to the UV's or material assignments on a mesh after the modifier node was applied, the data exported from the original nodes is rubbish.

Erm. In my case i guess i can either

1. re-write core of the exporter to handle this, which means reverse engineering to a certain extent the various poly nodes that cause problems (not to mention a fair amount of work on the exporter core).
2. Ignore it and add it to the known bugs list.
3. Take a stab at exporting the original nodes, and print loads of verbose errors for the user to realise something might have gone quite wrong.

[shon]

Thanks for responding! I've been using your site a lot, so I know if anyone can figure it out, it's you =)

It's starting to sound like the only way to get the real weights might be to trace the path from the skin cluster through the various tweak nodes to the visible mesh and apply similar calculations to what Maya must do to get the final weights... which would obviously be way too much work =/ But deleting the history, which is what I'd usually recommend, unfortunately destroys the skin binding in the process. I was hoping there was something in the API or a MEL command I could invoke that would return whatever weights Maya is using to deform that final mesh.

Well, for now I'll add it to the known issues. Thanks again, and good luck!

[rob-bateman]

yeah, i tried deleting all non-deformer history, but it fails for polyUnite (I asume it also fails for boolean ops on meshes as well). It kinda works for all other modifier nodes, however there seems to be small visual diferences in the resulting deformations.

One noticable example, is if you create a NURBS surface, skin it, then re-build the surface with more spans. Move the bones about a bit, and it gives you fairly expected results. If you delete the non-deformer history, it does re-assign the skin weights, however the surface does not deform in the same way as it did (i.e. It looks bad). The results from poly modifiers are significantly better though, so it does seem as though it may only be poly combine and boolean ops that you need to worry about.

I guess that it would be possible to pre-parse the scene using an MDagModifier to delete non-deformer history, then undo it at the end, which should handle the other modifier nodes (generating warnings for visual differences with nurbs and subdivs).

[pornozvedepo-pornozvedepo]

I really liked this information.

dubli