Autorigs, why are we reinventing the wheel?

Rigging
#1

Hello, tech-artists,

It’s a bit of a discussion\philosophy kind of topic here :smiley:

I’m currently working on my own autorig, a project which started a while back, but unlike with some other tools, I constantly ask myself a question - why do I do it? Do I really need it? Will it really help me? When there are a bunch of other great autorigs available for Maya, at least. And most of the time I can just use one of those, and slap some scripts on top if I need.

A lot of riggers I know all ended up writing their own auto rig tools. It even feels like when looking for a job as a rigger you better have your own autorig, and not use any of the existing tools. However, realistically, something like AdvancedSkeleton may do most of the work, and if something does not fit it’s easy to adjust it or add some scripts on top of it.

So if anyone here has any experience with their own autorigs, as a developer of one, as as someone who knows about reasons why someone else did it - I’d love to hear the reasoning and thoughts :slight_smile:

Thanks for your attention! :slight_smile:

#2

I’m writing my own for a few reasons - the original one is that I don’t like the way that conventional rigs work as a whole, and I want to build the coolest rig I can for the new age (parallel evaluation, GPU support, seamless FK IK and space switching, integrated collision and dynamics etc). It’s going to be a lot of work to make those elements in the first place, and instead of then trying to conform them to someone else’s existing framework (which may or may not come up short for me somewhere down the line), I might as well go the extra step and set it up for myself. I’ve found libraries like the various node calculators and Theodox’ Nodule to be much more use than a full autorig system.

The other reason is to get better at programming and design - as well as full object-oriented Python, it’s pushed me into PySide, numpy and openGL, as well as the more general aspects of data management and UX design. It provides a great metric to test each new technique I come across.

If you just need a character rig, I agree there isn’t much point in making an automated setup yourself - why spread yourself thin with a half-hearted rigging system when you could be focusing on deformation?

Good topic, and I’d be interested to see other perspectives :smiley:

1 Like
#3

I also wrote my own auto rig. There are a few reasons I did. # 1 is that I am outputting to a game engine so there are constraints to the joint structure that other auto rig programs may not take into consideration. I think more importantly though it was a test to see if I could do it. I didn’t know a lick of Python before I started. Now have written thousands of lines of functional code that have sped up my pipeline by many times over. It took over a year, but I am a very confident coder now. And I have a tool that will save me months if not years of work. It is immensely satisfying to push a few buttons and have a rig up and running knowing that you created it. It’s like doing magic, so cool. :mage:

#4

I think we’ll keep needing new rigging solutions, as existing ones either…

  1. Solves a Different Problem A lot of what already exists, exists to solve a specific problem, and is unlikely to solve yours.
  2. Was a Learning Exercise As highlighted in this thread, another lot of what exist were made to challenge or expand the skillset of the author. A great endeavour, but doesn’t solve your problem.

I can attest to both of these, having made a few to learn, and a few to solve specific problems. And I think that’s allright. The word “reinventing” have a negative but unjustified connotation in this context; the problem will keep shifting, and so should the solution.

Oh, and there’s one more reason to craft a new solution…

  1. Mine will be better

And we like those; bring it on!

1 Like
#5

My reasoning for creating my own auto rigging system is pretty much for the same reasons that have been mentioned above.

  1. Learning experience
  2. Create for my own workflow, I can also always go to my system and add functionality to it as the needs might grow.

Also, as Rigging/ Technical artists we are always learning new ways to improve our rigs/ rigging abilities (May it be better ways of solving a problem, or even performance).

Using other auto rigging systems I feel like it’s someone else’s tool that they created and I don’t get the same satisfaction that I get from rigging something from what I created. Self pride thing I guess…
In using other auto rigging systems, you might have to pay for the product. Again, being a Rigger/Technical Artist, I want to make myself as marketable as possible and have my own tools and systems that I can rely off of and make an income from.

My favourite reason so far of this post is from @marcuso and I know we can all we agree! We want to make the better one! :wink:

Great topic! I am very interested to see other people’s opinions.

#6

Agree with all of the above.

From my point of view it’s because our Red9 Puppet is an asset and service that we sell so we need to be in control of the systems directly. Also building your own rigging setup also means that you’re in control of all the wires and sub-systems and that makes it far easier to build bigger pipelines around. Sure there are some great auto-riggers out there, but when you’re then trying to connect those to the rest of your pipeline nothing beats running your own systems.

The other point, and this is really important from a business standpoint, is that with ever project we do the codebase evolves with our working practices, new rig compounds get written for specific clients, leg systems get replaced, secondary client side controls get added and it’s a fine balance between having one massive “it does all” rig, and having lean mean rigs that can be easily tailored to projects.

The final point is that the procedural rig itself is often only the start of the final asset. For example, the puppet that our code builds is only the base. … we could release assets just at this stage as the rig is fully functional, however to make the pipeline flexible and fast to iterate we break the process, adding in a massive publishing stage… we bind the clients deformation setups, we bind all the underlying meta systems and run a huge chuck of HealthTests over the final asset, adding in any client specific patches at the same time.

Plus lets face it, as a TD it’s great fun!! (when it’s goes well!)

1 Like
#7

Just throwing in my 2 cents here. I think the original poster implied an autorigger for bipedal characters, but that wasn’t specified, so another reason is simply that you want to make an autorigger for a different class of thing, whether that’s a certain kind of prop, vehicle, or cartoon animal, whatever. For my work, that’s often cellular and molecular processes, and obviously you’re going to need custom solutions. If you have the skills to build an autorig for one thing (say, a human autorig in your portfolio), someone would be more or less confident you could build an autorig for the sentient trees they’re building a game about.

#8

This has always been a big part of it for me. In this case, the “wheel” is a complex system with likely thousands of moving parts. So unfortunately it isn’t really an option to just use someone else’s wheel and have that be the end of it - maintaining and iterating on rigs is something we have to do as well, and those require you to have a good understanding of how it’s put together.

Also, of course, learning.

#9

What would be most ideal is getting a group of developers/riggers together and collaborating on a set of tools together.

If only one existed.

1 Like
#10

image

7 Likes
#11

You make a good point, but again it’s a microcosm of the issues that others have identified - every tool in every tech art suite, no matter how experienced the designer is, has been built to solve a specific problem for a specific purpose. There are absolutely valuable tools in mGear, and many other projects, and I use them in my scripts, but the higher functionality is just of no use to me because my problems and purposes are different.

Draw knowledge from many sources.

1 Like
#12

Oh, I’m glad that this thread got some interest :slight_smile: 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 :slight_smile:

@ritterrav That’s kind of what I was thinking about

@marcuso That’s EXACTLY whats happening here! :smiley:

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 :slight_smile:

Oh, and this is the thing that’s good to avoid:

1 Like
#13

I actually wrote an autorigger for a class during my undergrad, so I guess I fall into the “learning experience” category. There are a lot of reasons why different people don’t use autoriggers that are already out there. One of my main reasons is that they’re over-generalized. For instance, AdvancedSkeleton is very, very powerful, but it’s over-complicated and hard to figure out. (Same deal as what Nix was getting at with the XKCD reference.) I spent three days trying to rig a character with it and misunderstood half of the controls. Naturally, I didn’t end up with what I wanted. Then I went and rigged the same character by hand in a couple days, and ended up with exactly what I wanted. I’m not saying AdvancedSkeleton is useless or anything - some people swear by it. Me, I swear AT it, usually. : )

When I did my autorigger, it was designed to be ultra-simple to use. You import a set of locators, put them where you want the major joints to be, and then the rigger creates the skeleton, skins it, and drops in the controls. You adjust the controls to your liking, and then the autorigger wires them up. Done. With a selector, even. Trouble is, it didn’t really generalize well. It worked for a lot of characters, but there were a few that it broke on.

I think that’s the main issue with developing an autorigger - you have to balance simplicity with the ability to generalize. That’s not an easy task. But then again, as tech artists, we weren’t hired to do easy tasks, were we? Otherwise we’d be tech directors. Just kidding. I only put that because my tech director is sitting next to me right now.

2 Likes
#14

@ArtGeek The “just kidding” part? :smiley:

Well, what a lot of autoriggers lack is a rebuild feature. When I first came from max to maya I was frustrated with the fact that after I rigged a character and skinned it I could not just go back and tweak joint position, because it would require to rerig everything. Sure, later I realized that I could export weights, delete\recreate the rig (which is fast with autoriggers) and then load skins back. Still - that’s a lot compared to, say, what you do in CAT - literally just click a button in Skin modifier to allow it to move joints, go to CAT’s ‘figure’ mode or whatever it’s called, and move the damn joints. Two more clicks - everything is a adjusted. And you don’t even need to wait for anything to rebuild.

In Maya AS got the closest to it with it’s Rebuild feature. It even preserves your modifications to the rig, or at least some of them, and it preserves skinning. But only if you use it’s Deformation Skeleton, if you use ue4 skeleton, for example, you’ll have to take care of exporting\importing skinning yourself.

#15

Good point - rebuilding and saving every single part of rig is huge in production. If the proportions on a model change, it should be as simple as loading the starting rig locators, making the change, and rebuilding - I don’t know many autorigs that do that.

#16

We took the decision really early to base our Autorig on the skeleton itself rather than any guide locators, mainly as we work a lot in games and for that the skeleton is absolutely crucial, the skeleton is a solid, non arbitrary entry point and it also makes you evaluate the orients correctly on the client side data. The codebase stores all the build flags and any calibrations done on the subsystems to a settings file so the whole thing can be re-built really easily and without any guess work. Again, we have games clients with thousands of anim files and need to be able to confidently insert a new rig into the current pipeline without the fear of destroying any current data!!

Above all we do it because we love writing the stuff and having full control of how our pipeline integrates to the puppet, having to shoe-horn data onto existing rigs works, and we do it for a lot of clients with pre-existing internal studio rigs, but there’s nothing like knowing the codebase intimately.