Rigging: What core rigging features do you feel Maya lacks?


#1

As Unity and Unreal are adding rigging chops to their engines, what features do you wish Maya had that you would like to see in new rigging implementations?

One that came up the other day was temporal features, like being able to get the previous angle or state of something. In order to make a twist setup for instance.

I know many people wish that Maya had a better system to drive things, not just with a curve, but with other interpolation options.

The ‘multi parent’ constraint that Unity showed off at GDC is another example of something simple that Maya has lacked for some time.

I haven’t rigged in Blender, any features there that people wish Maya had?


#2
  1. I’d really like a representation of rotation keys that was both mathematically stable and also visualizable in the graph editor. Almost 25 years of Euler flip garbage is too much.
  2. Better tools for hiding components that are necessary for the rigger but clutter up the outliner view for end users. Ideally something less clunky than containers.
  3. A good scheduling style view (like what tracks does) that integrated with the graph editor. Right now dealing with things like IK-FK limbs is clunky because the behavior changes modally but the display is scalar. Having a way to visually see “this is an IK interval” vs “this is an FK interval” would make many tasks easier (obviously, this would extend beyond just FK and IK, that’s just an easy example of the need for discontinuous views of discontinuous behavior data – multiparent constraints is a good example of a similar display problem).
  4. A better set of tools for creating control shapes – maybe an attribute that would make a mesh become non-renderable, hidden in playback, and toggleable with a native UI thing. I’ve been over nurbs curves for 15 years… animators, not so much :frowning:

#3
  1. Generalized weight containers in the DG.
  2. Expose Quaternions to the users as key-able manipulators - angle/axis.
  3. Softimage scale.
  4. Be able to use a generalized unit across the api - converting sucks.
  5. The ability to debug code compilation in Maya with breakpoints etc.
  6. The completion of API 2.0.
  7. A user friendly guide on creating manipulators in the API.
  8. True state access in plugins - currently its a little quirky with PE issues.
  9. Fix skin clusters stability issues in large scenes.

#4

1: Re-iterating: General weightmaps. This would be, by far, the most useful.
2: A script editor from this millennium
3: Universal support for polygon selection sets (Sounds like a “meh” feature, but really isn’t)
4: Support for post-facto re-topologization. (XSI kept track of vert ID’s, and it was great)
5: Fix Joints. They’re currently a half measure and treat rotation and position offset separately. There’s no reason for it. Joint orient should be replaced with a pre-parent world matrix, and should be part of the base transform. (This concept is one of the most powerful things I’ve had the pleasure to work with… in proprietary software)

6: Give those of us stuck on Windows some Numpy and Scipy love. Yes I know I can get it from <random google drive location>, but the fact that I can’t rely on it for my offsite guys is incredibly frustrating.
7: When writing nodes, dirty Point position and Topology separately so I can cache topology dependent data structures (3ds Max does it)
8: For the love of all that is holy, when I delete an alembic object, RELEASE THE FILE.
9: Geo constraints that use the GPU.

And we’ve coded, or have slated about 15 general purpose nodes that should have been part of maya since 2000.
10: Generalized math nodes and linear algebra nodes. (most of those 15 are here)
11: Built-in relax deformer (The brush doesn’t count)
12: Space-relative constraints. IE, move A relative to B as C moves relative to D.
… there’s more. Can’t think of 'em. Going to bed.


#5
  • Matrix-driven transforms, and far more user-friendly ways of visualising and manipulating local vs world-space data

  • Weight map nodes (and basic dilation/erosion/smooth operations) would be the knees of the bees


#6

Above all else I want to see standardization across applications. Something like an app agnostic, extendable universal rigging description format. It is very difficult to take full take advantage of any DCC or engine specific advancements when the functionality and setup differs dramatically between the source and engine content. No one wants to port rig related code or do a similar rig setup twice.

In an ideal world this wouldn’t be an app specific discussion. The very fact that this question is directed at Maya speaks volumes to the underlying problem. That divide is only going to get worse from here unless someone provides an open source standard and gets all the major players behind it.


#7

Fabric Engine tried to offer that already. There wasn’t enough uptake as people are too ingrained in the DCC’s they work in already.


#8

Yup, what a disappointing day that was when they closed shop. Had hopes to evaluate it before the news hit.


#9

It was an awesome bit of kit, but sadly not to be.

The main issue is that you have to provide rigs for animators, and the current generation seem very strongly coupled to Maya. So no matter how great the tooling or interface might be in another DCC, how feature rich or robust the rig. If it isn’t in Maya, not many animators will be interested.
This has at least been my professional experience for the past 5 or so years.

The best thing that can happen to provide updated features is for opensourcing of said features by any company that implements them. AD isn’t going to do much about cross DCC toolkits, but a lot of companies will and are.


#10

I’d say having nodes based on operation rather than type and allowing multiple inputs/outputs (i.e arrays) would be handy. They would still require type inference but it would be based on operation and not type E.g.

abs, add, sub, div, mult, remap, deg, rad, cos, tan, etc… ~ int/float operations

dot, cross, normal, wedge, etc… ~ vector operations

multMat, inverseMat, decomp, comp, etc… ~ matrix operations

Key to this is to basically list all operations based on type, i.e. float operations, vectors, matrices, curves, surfaces… Maya tends to ping-pong between type based and operation based.

Node name standardization would be a welcome update too - I hate having nearest, and closest name differences in nodes.


#11

If you are interested to help Maya to get better rigging tools you could join the beta.
There is a lot goin on in that area.