Oh, I’m glad that this thread got some interest Thanks a lot for all of your replies!
@stwert Oh, no, I was not really talking about any kind of autorig in particular. But I don’t really see the point in making non-modular autorig, it’s not THAT different from making an autorig specific for some creature. I mean in the end it’s all just FKs, IKs, Spline IKs and some variations of those, and a bunch of other additional things topping this cake
@ritterrav That’s kind of what I was thinking about
@marcuso That’s EXACTLY whats happening here!
So some of my own thoughts then!
I do relate to a lot of reasons mentioned here, summing up:
- Toolset that you control, and can tweak and adjust to your own needs
- Not relying on someone else to fix and update this autorig, or to update it to work with new versions of Maya
- Adding things that other rigs did not implement
- Practicing Python and rigging
- Showing that you’re capable of writing such a complex system
All of this is what’s driving me to writing my own autorig as well.
It would be interesting to hear what kind of problems you had that your autorigs solve better than others? Things that absolutely require using your own solution?
A word on standards.
I do think that having a standard is important, in the big picture. Let’s take (no stones please) 3ds max for example - it has Biped and CAT. A lot of animators know these tools, and outsourcing animation work with these rigs is often a breeze (relatively), at least as long as you don’t need to adjust your rigs or have the tools to transfer animations from old rigs to new ones.
You just bundle it up in one file, and they can even animate it in almost any version of 3ds max. Everyone who works in 3ds max knows CAT and Biped tools and how they work. People (me too) can hate these tools, but still, they do the job for a lot of people.
You’re not locked to any rigger, as a lot of people, even animators, know how to work with these tools.
And then there’s Maya, with all it’s rigging power, but no real standard. If you’re making your own super-auto-rig that relies on some plugins to work - in case of outsourcing you also need to ship those plugins to all animators and explain them how to use them. Oh, and it’s also version-locking. Outsource animators do have to keep multiple versions of Maya installed on my system, and keeping their settings and tools in sync. And in outsourcing world there are quite a bunch of people standing between studio’s TD and outsource animators, so it’s not always easy for an animator to just ask “Hey, this install script did not work, how do I install these tools so I can work with your rig?”.
I would also not really be interested in buying autorig that’s compiled to a specific version of Maya. Because there’s no guarantee that author will keep supporting it and updating it to fit new versions.
And one more for production - from the management point of view - if you have a rigger who’s using his own autorig and then he leaves… And new rigger will have to either learn tools of the guy who left, or adjust his own tools to work with the new thing, or write a new one… Either way it seems like a lot of work, time and money spent. I wonder how Epic worked around it, after Jeremy Ernst left.
I do feel like this is the problem. So I really don’t like the idea of writing nodes\plugins that are required to animate the rig.
Maybe I’m wrong, though, or don’t see something. That’s why I’m asking
Oh, and this is the thing that’s good to avoid: