Releases: AKEric/skinner
1.5.1 Updates
Until this update, there was a flaw (only discoverd in the past year) with how the .sknr format was searlized via pickle : it would physically pickle the Numpy ndarray's. The downside is, if userA saved out using numpy 1.x, and userB tried to import using numpy 2.x : userB would not be able to load userA's sknr files, based on binary incomabilities / API changes when trying to deseralize the pickled ndarray data.
v1.5.1 addresses this, by converting the ndarray data to standard builtin types for pickle searlization. Meaning, the version of numpy the user has installed will no longer impact the saving/loading of the sknr format.
However, this only addresses the issue with new sknr files saved in v1.5.1 or newer: Old files will still have the same limitation of numpy major version incompability. If you find yourself in this situation, the 'fix' is to 'simply' re-export the existing sknr data on a machine that has the 'correct' version of numpy installed: Clearly, this could be batched if needed, but annoying. See the notes in the v1.3.1 release on this.
But live and learn!
v1.5.0 Updates
Adding 'reset to defaults' options for all UI elements. Accessible by either RMB on any element, or a 'reset all to defaults' in the Extras tab.
v1.4.0 Updates
Changing overall git filestructure so it will play better with git and Maya python package management.
The main change is that there is no longer a /skinner/skinner subidr: All the Python code has been moved to the root /skinner folder, to allow this repro to play well both with version control in github and being added to Maya's Python path: The instructions have been updated to reflect the new install methods, as called out in this section:
https://github.com/AKEric/skinner#integrating-into-your-pipeline
v1.3.1 Updates
Found an issue if sknr files are saved with different major numpy versions (like 1.x or 2.x) : The versions can't deseralize the other's code, and will raise a :
ModuleNotFoundError: # 'No module named 'numpy._core'
Updated to detect for the exception, and print logical steps for the user to manually fix.
Specifially, the sknr file needs to be regenerated based on the user current version of numpy. The steps are:
1 : In the file with skinning, select the mesh.
2 : In the Skinner window -> Export -> Export Temp
3 : Import -> Check 'Unbind First'
4 : Import -> Import Temp
5 : Export -> Re-export on top of the old .sknr file.
This will update that sknr file to use the users current version of numpy.
Will have a think on how to address this in the future: I discovered this issue by 'accidently' installing numpy2.x in Maya 2025, not realizeing Maya 2025 already ships with 1.24.4 natively: The internal Maya code written for 1.x was coflicting with 2.x, and when I rolled back the 2.x numpy, all my sknr files stopped loading :(
I could see providing a future option to not use pickle for serialization, and use something like json, but my presumption there'll be a siginfiant speed hit on both serialization and deserialization between the two.
v1.3.0 Updates
Updating window.py to support PySide6, adding 'Reset Preferences' button to the 'Extras' tab.
v1.2.1 Updates
Bufixing core.importSkinChunks if multiple were imported at once : could have been duplicating them up / confusing itself.
v1.2.0 Updates
- window.py: Rearranging some of the Import tab UI elements. Bugfixing App.importSkin : It wasn't closing the undoChunk. Adding the 'Auto-Fix Broken skinCluster' to the 'Extras' tab. Updating tooltips, making multi-line.
- core.py : Setting setWeights unskinFirst default to False, was True. Updating the undoChunk closing code with specific names. Adding regenrateSkinCluster, adding new tempFilePath arg, and kwargs capturing to both exportTempSkin and importTempSkin.
- utils.py : Updating setBindPose : "it stopped working", and now needs a 'g' (global) arg set True.
Per the new 'auto fix broken skincluster' tool, copy/paste from the docs:
- There's a really weird bug that sometimes when you import skinning onto mesh with an existing skinCluster, the tool fails, with this error:
- '(kInvalidParameter): Object is incompatible with this method'
- I've found that sometimes (but not always), trying to load skinning onto a skinCluster that wasn't made by this tool, will trigger that error.
- It appears to be something 'bad' in the skinCluster itself preventing the new weights from being set. Much debugging/diffing of mayaAscii files hasn't turned up anything.
- The fix is simple (what this new feature/button does): Export temp skinning on the mesh, unbind it, and reimport the skinning, to get a 'new' (and much happier) skinCluster built, so that future sknr imports work better.
v1.1.11 Updates
Bugfixing tool to properly paste weights on selected verts. Specifically:
- utils.py : updating addInfluences to not change any weights when influences are added. Adding transposeWeights, to reorder SkinChunk influence weights based on skinCluster influence order.
- core.py : updating setWeights to leverage the new utils.transposeWeights to sort SkinChunk weights in the same order as the influences on the skinCluster. Also raising more expections if 'selectVertsOnly' is set and operations would happen that would change the skinning. Various verbose logging formatting changes.
Open Source Code
As of Feb 2023, Skinner has been open sourced. But the developer would still appreicate any tips you'd like to provide.
Please 'buy me a coffee' per the below suggested tipping rate: https://www.buymeacoffee.com/akeric
- Student / Hobbyist / Indy dev : Free! (but if you want to donate, I won't turn you down)
- Any other production : $25 a user.
Reobfuscate modules
Reobfuscating previous release via PyArmor to see if it fixes 'Marshal Load Fails' errors for those that have been getting them.