Maya is Finicky…
Our ever expanding repository of lessons learned.
This a very unstable release of maya. We avoid whenever possible.
Release 5 has been the most stable for use and improved marking menu speeds immensely. Release 4 is pretty crash happy.
Reloading a ui from a menu crashes maya
Props to Charles Wardlaw for help on this. This stems from maya changing the way things work and what worked from 2011-2016 broke. However there’s a pretty simple fix.
Changing my previous
c = lambda *a:self.reload() to
c = lambda *a:mc.evalDeferred(self.reload,lp=True) resolved it.
Python update broke zoo.path and other things
2017 brought in a new version of Python which broke how strings were handled. Rewrote zoo.path and some other modules as Hamish isn’t developing currently.
UI back end changes
I don’t have a firm answer what specifically changed but Callbacks crash maya where they didn’t in 2016 and before. So in general, we try wherever possible to use
lambda calls or
mc.evalDeffered for ui calls to avoid it. Current understanding of what crashes:
- Pushing self initialized instances into a Callback
- Sometimes callbacks in general
- Calling a new ui from the marking menu.
- Trying evalDeffered to fix this.
Raycasting issues with OpenMaya 2.0 vs 1.0
Calls on OpenMaya 1 and 2 variations after some bugs were discovered with 2016 casting. Sepcifically 2.0:
- when casting at poly edge, fails
- nurbsSurface UV returns a different rawUV than 1. 1 Normalizes as expected, 2’s does not.
- nurbsSurface normal returns junk and broken
Hotkey system changed
Any previous hotkey setup tools probably broke. We’d been using zoo’s but wrote our own to address. You may find it
cgm.core.classes.HotkeyFactory. The biggest add was the addition of workspace which need to be dealt with.
Sometimes maya doesn’t wanna close and the task manager isn’t working. In cases like this, try this:
- Windows Run |
taskkill /f /im maya.exe
When this flag is turned off it will break maya student files. It manifests as no longer being able to save or open maya student files.
// Error: line 0: Error reading file. //
// Error: line 0: Could not save file 'D:/test.ma'. //
[x] Track Selection Order– Pretty important for rigging and technical purposes
Working on other’s rigs
Sometimes you get asked to work on other’s rigs to improve them. There’s a number of questions to get the answers to as you delve in.
- Check asset master control scale – sometimes rigs aren’t at 1 because of whatever reason. It’s tedious if you start setting stuff up and want to get your stuff in their rig and you have to deal with extra transform nodes when you parent stuff.
- Look at naming/numbering conventions and ask if they aren’t clear
- You can use the select
Constraints [Get Targets]call in the TD section of the toolbox for finding where the rig bits are. It’s like walking through what’s driving what.
- If you see
// Warning: Non object-space scale baked onto components. check your scale settings and put it in object mode.
- If you find objects flipping when you go back in the timeline. Select those objects and pick walk up or trace until you find aim or orient constraints. Try chaging the type from noFlip to shortest or know that the flipping will usually resolve when you go to the start of the time line because of how those work.
- MultiMessage attributes – In the end, not a fan of multi message nodes for things that we need to track specifically. When an item connected via mult message attr is duplicated. The multiMsg connections are duplicated. While this can be handy for certain things, when you need specific lists of items, it’s not so hot. We developed our msgList setup for this reason.
- datList is another version of this where you can store series of connectable points of data
- When doing chained segments, parenting the root of the roll segment to it’s root and leaving the handle joints clean works best.
- Joints doing funky scale things? Check that the
inverseScaleis conected to the joint parent.
segmentScaleis a very cool attribute when you wanna do fun scale stuff.
- Log.debugs still take a hit on processing time. Watch em
- Logger is much faster that print
- pprint rules all.
- Index — this is it’s index in the blendshape node. Note – not necessarily sequential.
- Weight — this is the value at which this shape is ‘on’. Usually it is 1.0. Inbetween shapes are between 0 and 1.0.
- Shape — this is the shape that drives the blendshape channel
- Dag — the dag node for the shape
- Alias — the attribute corresponding to its index in the weight list. Typically it is the name of the dag node.
- Plug — the actual raw attribute of the shape on the node.
- Weight Index — follows a maya formula of index = wt * 1000 + 5000. So a 1.0 weight is a weight index of 6000.
- Blendshape data is stored in these arrays in real time so that if you query the data and your base mesh isn’t zeroed out, the transformation happening is baked into that
- The caveat to that is that targets that have their base geo deleted are ‘locked’ in to their respective data channels at the point they were when deleted. Their delta information is frozen.
inputTarget— this is most often 0.
inputTargetGroup— information for a particular shape index
inputTargetItem— information for a particular weight index
- Sub items at that index
inputPointsTarget— the is the differential data of the point positions being transformed by a given shape target. It is indexed to the inputComponentsTarget array
inputComponentsTarget— these are the compents that are being affected by a given shape
inputGeomTarget— this is the geo affecting a particular target shape
- Replacing blendshapes – you can 1) use a copy geo function if the point count is exact to change the shape to what you want or 2) make a function to do it yourself. There’s not a great way to replace a shape except to rebuild that whole index or the node itself. We made a function to do that
- Once a blendshape node is created with targets, the individual targets are no longer needed and just take up space. Especially when you have the easy ability to extract shapes.
- Getting a base for calculating delta information. As the blendshapes are stored as delta off of the base, the best way I could find to get that delta was to turn off all the deformers on the base object, query that and then return on/connect the envelopes. I’m sure there’s more elegant solutions but I was unsuccessful in finding one.
- Once you have that creating a new mesh from a an existing one is as simple as:
- Taking base data
- duplicating the base and xform(t=vPos, absolute = True) each of the verts will give you a duplicate shape
- For components that are affected on a given index/weight: add the delta to base
- Aliasing weight attributes –
Copying skin data from many meshes to one – as in on a game project when you get your final single mesh
- Select all the various mesh items with skinClusters
- Add those to a new object set calling it ‘sourceSkin’ or something
- Make another object set with just the new mesh in it (I’ve tried avoiding this step but the results aren’t as good)
Rigging>Skin>Copy Skin Weights
- mc all the way. cmds eats toenails, Keith!
- To get plugs properly, you need both source and destination flags set – one True, one False to get expected results. Ran into a bug where the default value in maya changed between versions. Don’t assume.