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
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'.
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.
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?