SkinCluster Component Tag breaks in 2022 when changing .ma header "Requires" line to "2018"

[aseredy]

Hey all,
I'm doing some rigging tests for a potential gig, and the studio uses Maya 2018. I have 2022. When I try to make the file backwards compatible, the skin cluster breaks and the joints no longer influence the geo. The skinCluster Node is still in the file, but it has no affect.

For NDA reasons I cant show the file, but this is the general issue.
- Simple game skeleton on a simple biped human character. No control rig. Calethetics animation is just joints keyed directly.
-Skinning Method. Dual Quaternion/4 influences (everything else stock)
-Apparently there is no bindpose attribute anymore (?)

NOTE POSSIBLE FIX!!!: Under SkinCluster1 > Deformer Attributes > Input Attributes
In Broken file "Component Tag = "(None)""

When I change the "Component Tag = "*(All)" "   - It starts to work again.
Why is SkinCluster1's "Component Tag" not getting hooked up correctly on file open in 2022???

I only change the requires line to 2018... Why would the skin cluster break when I reopen the file to test the results? Additionally, my 2020 license ran out, so I upgraded to 2022. I did a similar test in 2020.4 and I did not see this behavior when making the file backwards compatible. The only difference is that in the previous test I used Classic Linear skinning.

Thanks for any help!

Script Editor output: (my only change is the "requires maya "2018";"  from "2022")
Shows nothing of interest... no clues to the error.

file -f -new;
// untitled // 
doOpenFile ("C:/Users/ANDY/blah.ma");
file -f -options "v=0;"  -ignoreVersion  -typ "mayaAscii" -o "C:/Users/ANDY/blah.ma";addRecentFile("C:/Users/ANDY/blah.ma", "mayaAscii");
updateRendererUI;
+++++++ Turtle for Maya registered successfully ++++++
updateRenderOverride;
// Warning: line 1326: The default image may not be modified. Use the -i/image flag instead. // 
// Warning: line 0: This file is from an older version of Maya.  If saved, it will not be readable by previous versions. // 
// File read in  0.51 seconds.
// Warning: file: C:/Program Files/Autodesk/Maya2022/scripts/startup/findStartUpCamera.mel line 116: Could not find an appropriate startup camera: side.  A substitute will be used. // 
commandPort -securityWarning -name commandportDefault;
// Error: line 1: Could not open command port b'commandportDefault' because that name is in use. // 
onSetCurrentLayout "Maya Classic";
// AbcExport v1.0 using Alembic 1.7.5 (built Nov 30 2020 18:40:46)
// AbcImport v1.0 using Alembic 1.7.5 (built Nov 30 2020 18:40:46) // 
gotoBindPose;
// Error: file: C:/Program Files/Autodesk/Maya2022/scripts/others/gotoBindPose.mel line 61: No object matches name: .bindPose // 

[mspeer]

Hi!

1. You can't make a file backwards compatible, just by changing the requires statement.

Newer features are still not supported in older Maya versions.

2. If you change the requires statement, this does not (/should not) have any impact when you open the scene again in Maya 2022,

BUT

3. If you edit the scene in Maya 2018 and open it again in Maya 2022, then Component Tags may no longer work as they are simply not supported in Maya 2018.

So...

a) If you want to use Component Tags, then work with the scene only in Maya 2022 (or newer versions)

or

b) Don't use Component Tags in Maya 2022, if you want to open the scene in older Maya versions.

[aseredy]

Thanks mspeer thats super useful info.

Curiously, I wasn't using Component Tags per se, but that is the only discrepancy I found in the file when reopening it in 2022 and comparing the working file to the broken file. In theory the file should be fairly backwards compatible since I'm not using any 2022 features. At least, the features I am using should be backwards compatible. Also, this exact technique worked in 2020.4 going to 2018 (I was able to confirm functionality on a 2018 license from my old studio. I do not have access to that system any more though). Presumably, the only things I'm doing differently this time around are using DQ skinning instead of CL, in Maya 2022, not 2020.4.

Thanks again!
Andy
Steps to reproduce in Maya 2022:
1. Create a joint

2. Create a poly plane
3. Bind Skin (Selected Joints, Closest Dist., DQ, Interactive, Distance, MI = 4)
4. Test skin functionality (witness proper function)
5. Save File
6. Open File in text Editor and change Requires to "2018". Save File as something new.
7. Open file in Maya 2022
8. Witness disconnected SkinCluster

[mspeer]

Hi!

Thanks for the steps I was now able to reproduce this here.

I tested first with a simple torus, where it works (at least if history is kept).

There could be a reason why certain objects from an older Maya scene are loaded differently, maybe because of some changes in the product, so my previous suggestions are still valid.

[aseredy]

Thanks mspeer. This actually feels like a regression 2020.4 -> 2022. I did a lot of Parallel EM testing at my old gig (we had consultation time in our license contract with ADSK, but that studio no longer exists) This definitely feels like a regression. I've seen them before... (similar to the dirty propagation and loss of manipulation eval on SDKs after 2 keys were set, between 2019.2.2 -> 2021.) It worked fine in 2020.4. So my debugging instincts are telling me this is a bug.

What are the proper channels for reporting bugs if we don't have consultation service contracts, like large studios do? I'm not using any feature specific to 2022, and most studios dont version upgrade as fast as individual users. (truth be told, I haven't had a version of Maya on my home rig in 10 years). So, if a studio asks for skinning tests, I need to use some form of skinning. And if I can't accomplish that in 2022, I need to walk back to a version that does work. I can confirm on Monday if the file opens fine in 2018, once I hear back from their Lead Tech Anim.

Thanks again for all the help. Your insight is super useful!
Andy

[mspeer · Accepted solution]

Hi!

There could be a valid reason to treat files from an older Maya version differently, so I would never recommend to edit Maya files manually as part of a workflow.

Anyway if you want to report this problem (bug?) to Autodesk, you can do this here.
In Maya main menu:
Help -> Speak Back -> Report a Problem

[aseredy]

Thanks! I'll at least report it and see if anything comes of it. I agree this one def seems weird. I know forcing files to be backwards compatible is a terrible idea, but  sometimes you gotta do what you gotta do. haha

Thanks again for everything!
Andy

PS I tested it with a torus also, and at first I was hopeful it was an issue with non-manifold geo... but even on closed surfaces the behavior persisted.

[zewt · Accepted solution]

If you have component tags enabled in 2022, deformers are created in a much simpler way than before.  They don't have any groupParts or groupId nodes and don't have deformer sets.  All of that is stuff that 2022 no longer requires thanks to the component tag work, whether or not you're actively using component tags.  This isn't backwards-compatible, since deformers in earlier versions of Maya require these nodes to function.

If you want scenes to be backwards-compatible, you need to disable "Animation > Rigging > Use component tags for deformation component subsets" in settings, which will cause deformers to be created using the older method.  This needs to be changed before creating any deformers, since it only affects newly-created deformers.

In general, though, Maya doesn't guarantee that scenes will work in previous major releases, even though they often do.  I wouldn't want to do work targetting a version of Maya unless I could install that version myself (and Maya 2018 is so old it's no longer available...)

[aseredy]

Thanks Zewt. That's super useful.

My game plan now is to export skin weights, disable Component Tags, and then import the skin weights on to new skin clusters created after disabling the tags.

This seems like a huge liability in a production environment. I know backwards compatibility isn't guaranteed, but speaking from experience, we would do it all the time for a bunch of reasons. Especially when evaluating parallel EM for production, or when a regression or bug was discovered.

For instance, in 2019.2.2(or 2.4 I cant remember) custom user attributes connected to an SDK would lose manipulation evaluation after 2 keys were set (there was a rule issue that caused the node to not evaluate once the EM thought it was animated). We never discovered this until we were well into production and 2019 was promoted to production). So our solution for Animators was to roll back (or is some case roll forward too). If a rig were to be made in 2022, it would seriously limit the flexibility of the asset in a production pipeline(if unknowingly/mistakenly component tags were used). This seems like the kind of thing that should come in default OFF.

However, in retrospect, I would prefer the scene build to break this in 2022, because its a good clue as to the problem.

Thanks Again zewt. I will rebuild the deformers. Cheers!
[salute]
Andy

[aseredy · Accepted solution]

1. Leave Component Tags intact on original geo.
2. Disable Component Tags in Settings > Animation > Rigging
3. Duplicate the original surface.
4. bind skin (old style bind with groupIDs)
5. Select original geo first, then new geo second, Skin > Copy Skin Weights
6. Save File
7. Open in text editor and modify Requires to "2018", save as something new.
8. Open new file in Maya 2022.
9. Witness old geo skinCluster is broken, but New Geo skinCluster is working.
10. Have a beer.
    
    
    (thanks Zewt!!!!!!!)
    
    PS Export SkinWeights didnt work sadly.

[aseredy]

PPS note to self, RTFM and also the change log... [presses lip, and shakes head]

[416588748]

optionVar -intValue deformationUseComponentTags false; changeUseComponentTagsPrefsCallback; string $skinCluster[]=`ls -typ "skinCluster"`; for($in in $skinCluster) { string $joints[]=`skinCluster -q -inf $in`; string $shape[]=`skinCluster -q -g $in`; string $parent[]=`listRelatives -p $shape[0]`; string $tempMesh[]=`duplicate -rr -n "tempMesh" $parent[0]`; string $tempSkin[]=`skinCluster -tsb -bm 0 -ih -nw 1 -mi 8 -omi 1 -dr 4 $joints $tempMesh[0]`; copySkinWeights -nm -sa closestPoint -ia closestJoint $parent[0] $tempMesh[0]; skinCluster -e -ub $shape[0]; string $newSkin[]=`skinCluster -tsb -bm 0 -ih -nw 1 -mi 8 -omi 1 -dr 4 -n $in $joints $parent[0]`; copySkinWeights -nm -sa closestPoint -ia closestJoint $tempMesh[0] $parent[0]; delete $tempMesh; }