Home Website Youtube GitHub

I have a question about weights

My weight skeleton has a namespace, but the exported weight JSON file does not have a namespace

What’s nice about that, is that you can open an animation shot where the rig is referenced, fix weights in the poses. And then export weights, and load them back into your rig.

Are you running into trouble with this?

2 Likes

Yes.

My weight joints have namespaces but the joints in the jskin file that I exported don’t have namespaces so I have to delete the joint namespaces in Maya every time I import them otherwise they won’t come in

QQ截图20220305145803

If I remember dictionary in jskin file should have key named “namespace”. Can you check if that key exists and if so it has value of your namespace?
It should look like this
'nameSpace': 'yourNamespace'.


That’s what you’re referring to and I changed it to my namespace but it still shows no joints

1 Like

Try to change this key : value also 'objName': 'DHIbody:f_med_unw_body_lod0_mesh',
What do you mean by still shows no joints? What is the error/warning Message in script Editor?

1 Like

Error message I have sent is the above yellow picture you click open a look to understand

It’s better to paste the text of errors instead of an image.

I understand now. I don’t know if this is a new bug, or if importing on a namespace was never supported. This seems like something that will be easy to fix in skin.py

This week I ran into a similar problem where skin.skinCopy() was failing when the target had a namespace too.

I’ll look into this if no one beats me to it. Perhaps a keyword argument to use the json namespace key, or to force the use of a specific namespace of your choice. (or if it’s a new bug, solve it.)

In my case it saves and loads skin data correctly. I’m using v 4.0.3.

1 Like

This problem has always been with me using the latest version of mgear

I tried to modify skin.py, but my programming ability is not strong, so it didn’t work

I hope you can solve this problem as soon as possible. Thank you very much

But when I used maya2022 mgear, it was 4.0.3 and the result was still the same

Have you changed 'objName' key’s value? Also I think kyou should do the same woth 'objs' key’s value to your current namespace

1 Like

Even though I think you’re not explaining your problem clearly enough, I believe I know what’s going on.

From what I understand, you have namespaced joints and when you import the skin, the script is throwing you an error. I was able to replicate this behavior, and I found a temporary solution. If you add all the corresponding namespaced joints as influences (with the bind skin menu), then importing the skin will work. This is because setInfluenceWeights in skin.py, line 347 is stripping the joints of their namespaces (line 357) and then using the raw names to match with the found joints.

The issue, and I can’t say if it’s a bug or if it’s working as intended, is in the try catch block on line 521. If the mesh doesn’t have a skin cluster, then it tries to create one with pm.skinCluster, but the problem is that the joints in the JSON file are saved without their namespaces.

If, and only if, the namespace of your joints is the same as the namespace of your mesh when you exported the skins, then you can change the behavior by adding these lines:

  • Below line 484 (objName = data[“objName”]), add myNameSpace = data[“nameSpace”]
  • Change line 524 (joints = list(data[‘weights’].keys())) to joints = list([myNameSpace + jnt_name for jnt_name in data[‘weights’].keys()])
  • You could also change line 533 (for j in data[‘weights’].keys()) to for j in [myNameSpace + jnt_name for jnt_name in data[‘weights’].keys()]: to have a better error message if something goes wrong.

(Edit: the line numbers may be slightly off by a few lines because I had been editing the file, but they should be close enough)

This is a VERY hacky workaround though, but it should work as long as the namespaces are the same. The better alternative is to simply bind the skin to the same joints and then import the skin, which will internally strip the joints of their namespaces.

2 Likes

Thanks for those details!

By the way, you can format code with surrounding backticks or triple-backticks to make it easier to read, and avoid smart-quote auto-formatting.

Example:
objName = data["objName"]
add
myNameSpace = data["nameSpace"]

Yeah I consider it almost a bug. And there is definitely room for improvement to be able to specify or change the namespace from the skin functions. Or a GUI option to guess, force, ignore, or specify the namespace.

1 Like

I thought of a few ideas, exporting and importing skins is something I’m also working on for a personal tool so I figured I could share some thoughts. Maybe you can get something from these ideas

Option 1: Import To Selection
Naive, but it works. Select the meshes and the joints, namespaces don’t matter. Import the skin. If you selected the same meshes and joints as in the serialized file, you get your skins.
Gist here. jignImportSkinToSelection.py · GitHub
Copypaste to skin.py, then in maya select your objects and joints and call

import mgear.core.skin as sk 
sk.importSkinToSelection()

You can find the sample files I used here mGear – Google Drive

Pros: The namespaces don’t need to match. There may not even be namespaces. All that matters is that the objects and joints are the same.
Cons: Hard to use as a post script, have to manually select. The ideal solution should probably be more automation friendly.

Option 2: Namespace Matching Dialog
Probably better than the other one. I didn’t have time to write a proof of concept, but shouldn’t be too difficult.
Have another extra function like importSkinWithNamespaces(args, meshNamespace = None, jntNamespace = None)

  • When scripting, the parameters can be passed to the call.
  • When accessing the function through the menu, the user could be presented with a simple dialog like this one.

ui idea

Option 3: Bruteforcing it
For each joint in the scene, compare it with each joint in the JSON file. If we have a match, add it to a dictionary with the serialized name as key and the scene joint as value. After iterating, if we have a corresponding joint for each serialized one, then proceed.
The obvious problem is when we have two rigs that are the same under different namespaces. Because of that, I think this one isn’t enough.

However I do think that this method could be used as the “guess” approach that you mentioned. First try to bruceforce it and if we have a 1-1 match without duplicates, then assume that we have a correct guess. If there are duplicates, maybe then show the dialog from option 2.

Let me know if you want me to write a proof of concept script for either one of these ideas, I’m not entirely sure how to display a dialog from mGear lol I’m still learning python but I think I should be able to figure it out, I believe could get it done sometime this week.

2 Likes

First of all, thank you for your solution. Now I’m using MetaHuman to guide weights with MGear and THEN I changed the code according to your method




And then the jskin file looks like this

But it’s still an error:# Warning: Object: DHIhead:head_lod0_mesh Skiped. Can’t found corresponding deformer for the following joints: [‘FACIAL_L_12IPV_ForeheadMid15’, ‘FACIAL_L_12IPV_ForeheadMid16’, ‘FACIAL_L_12IPV_ForeheadMid17’, ……

Then I used the other method you mentioned but it went straight to skin and exploded


I bind skin to him first and then import skin.jskin

Yeah that was just a proof of concept to show how it could be implemented, it clearly doesn’t handle every edge case and deformer unfortunately. I’m sorry you couldn’t get it to work but the fact is you’re trying to do something that from everything I’ve looked at, simply isn’t supported by mgear at least not yet and it’s evident that quick hacks won’t cut it.

I think you’re better off coming up with some way of removing the namespaces on the joints. It’s impossible to tell because I don’t have access to your files, but maybe if you remove the ns, import the skin and then add the ns back to the joints, then it could work (I’m not sure, just thinking out loud)

What’s strange about your error is that it doesn’t show the namespace you added.

Silly question, but did you restart Maya or reload the module after you made those changes to skin.py?