The 180 deg problem rears it head in a lot of places. If the ribbon's geo is collapsing, you can try using deformers. This guy talks about his method for getting distributed twist in his ribbon setup. https://vimeo.com/108727407 This rig is probably more computationally heavy than it needs to be though, and there are some other limitations when stacking deformations as blendshapes like that. These days I just use a curve and motion paths to drive joint chains, and set the upvector to something static, get twist rotation either as it's own separate twist attribute, or from a twist extractor, and distribute twist rotation by changing the motion path's 'front twist' value based on it's position on the curve. It rotates cleanly, and it's faster than a follicle.
Sounds like you're asking why sometimes the rotation values flip between 0 and -0 when you have constrained objects in general. If so, that's nothing to worry about - Maya calculates positions and stuff up to a certain decimal point, but the math isn't exactly perfect. it's probably just moving a little bit off from 0 in either direction. Channel Box --> Edit --> Settings --> Change Precision
Great share! That is really cool. I need to learn me some Pyside. http://cosmos.toolsfrom.space/ This will let you pull your scripts (as well as native maya commands) from a search bar if that's more up your alley. Haven't personally tried it.
Personally I keep my spine Ik controls world-oriented for consistent twisting that way, and let the fk joints have a little bit of bend to them depending on the model. I guess it's more organic? I've never really thought about whether a completely straight spine setup make life easier for animators though. In a lot of cases it seems like that would look spretty fake I'd like to hear what other people think of that. I think joints running down the center of the geo makes sense, but I work with a lot of cartoony characters. I might consider moving the joints maybe halfway to the spine for realistic characters.
Happened upon this while I was in the middle of trying to decide this very question for my own autorig. I'd be interested to hear what other people do. So far, I normally go: ctrlName_BUF (locked buffer group to hold trash values) ctrlName_CONST (constraint group for built-in spaceswitch or constraint inputs ctrlName_EXTRA (for further control or animator-made constraints) ctrlName_CTRL ctrlName_PIV (if you have a parent/point constraint from the control object to another node, any changes to the pivot point will also affect the position of the constrained node. This lets you keep pivot behavior, as well as letting you more easily add post-ctrl offsets if necessary)
I used to keep the buffer group so that if I deleted my constraints when the rig wasn't quite at bindPose, i'd be able to tell that it was off and easily correct it. But I think you could easily store the base values for the buffer group in a custom float3 attribute on the constraint group, so you could drop that one pretty easily and not lose anything. You can also conceivably drop the extra group in favor of using animation layers, which would probably actually be more predictable (for instance, scaling the 'extra' group will cause the control to move away from the 'extra' groups center, if it has an offset translation value. Which I think might not happen with animation layers? Then again I've known some animators that never implemented animation layers in their workflow, so layered groups might be more comfortable for them)
I've devoted a lot of the last year to trying to figure this out. A lot of it is just insulating your constraints from the rest of the rig, so that they only ever flip when you want them to. I highly recommend studying when and why orient/parent constraints flip. Other than that there are a lot of methods. If you just pull the X axis value with euler angles, the twist won't flip, but it doesn't always compute correctly. For instance, if you pull the x axis value directly from the control and rotate 90 in z and then 90 in y, no twisting happens. I've never tried using a parent constraint to fix that, and that might not be a bad easy solution, but you'll probably get the flipping problem again, and it won't be entirely accurate. I think the best solution is to somehow extract the twist value from the node's world orientation. These videos aren't hard to find, but in case you or anyone else reading has missed these, the simplest and most lightweight version I've found is here http://bindpose.com/maya-matrix-nodes-part-2-node-based-matrix-twist-calculator/. That one flips reliably at 180 deg, which is often enough all that's necessary. There's also the 360 twist extractor https://vimeo.com/149066264, but it's harder to understand and integrate, and only really works correctly when you're directly using the controls. If you applied the 360 deg extractor to an IK rig, it would still flip when twisting 180 degrees, because that's where the ik joints flip anyway, and if you applied the rig to a control that was also being affected by a constraint, you'd need to make some changes to this setup to get it to work. If you need even more twist, a good option is a plugin. Never tried this yet, but it seems promising: https://vimeo.com/190160103 The plugin uses simulation data, which means that its state is dependent on the previous frame, so scrubbing the timeline can get a little funky. Still, this plugin is proof that there are solutions of which I know nothing. Other than that, you can add a separate twist attribute which is independent from the control's orientation, and use that to overdrive the twist past 180deg when needed.
You could try using a 'choice' node. Attach the world matrix attribute of two transforms into the choice inputs and run the output through a decompose matrix, then into the resulting transform. So, two nodes. I don't really do this in my own workflow, so there might be issues, but I just tested it and it seems to work.
Links to particularly good bits from Cult of Rig would actually make a good thread discussion. There's lots of useful info in there, but it's so long and unorganized that it's hard to get through it all without missing things.
Thanks a lot for sharing this, I'm glad I didn't miss it!
From reading the blog, it seems to me like the problem of curve interpolation is one Raff would rather sidestep entirely, replacing procedurally calculated (but confusing) animation curves with a rig that supplies the animator a more intuitive experience, but is only useful for step framed posing like in traditional 2d styles.
I think many would say that animation with a variable pose rate can look really appealing, and a rig like that would certainly be way more approachable to all those 2d animator types who may not yet be fully capable of understanding the peculiarities of things like rotation orders.
I imagine that it's really a stylistic choice more than a technical one. The variable pose rate could come out a little uncanny in fully-realistic 3d, and might require some npr shaders to confound those details for the viewer. Without the option of controlling interpolation, I can't see it becoming a universal change in how the industry works, it's more like a solid framework with a very small demand. I like it though! Half the reason I first learned to rig was because making animation with curves didn't feel smooth or intuitive as it seemed like it should have, and I wanted to see if I could fix it. So I'm a fan.
I don't have much in the way of numerical data, and it's a big big world out there - but as a freelancer who's dipped into a few different studios, I think that it seems easy to overestimate the size of the industry. People that have found a place in the rigging industry seem to all know each other. I also haven't had a hard time finding studios that need experienced riggers as soon as possible. Along those same lines, I've also met several rigging leads who don't have a lot of extra time to revamp their rigging setup, and I know I don't search out quite as many rigging videos as I used to. Cult of Rig is also pretty high level stuff, so I doubt the view count would be a good representation of the entire industry.