General Character Setup Workflow

Rigging
1

Hi,

I’m about to setup a new character pipe at our studio and would like to throw the question out there about the “general” way in which studios deal with a character of relatively high resolution. Think, skin simulation and muscles to start out with. I’m sure this has been asked before, I skimmed the threads here and couldn’t really find any good enough answer.

Now, I realize it is very individual and based on the current needs at the time, so let me bolt the query to: several humanoid characters, good for about 4 commercial segments, produced by 1 td and animated by 4 animators under a period of the 4 month deadline.

Previously, we have had our character in one rig throughout the production. We’ve never gotten into the habit of caching even, so the rigs stays put until the final image is rendered. Which is about where we are now, which is also very inefficient.

So, my impression of how a more efficient way of handing off rigs to the animators and finally feeding the mesh over to rendering would be the following:

  1. The rig is split up into three parts; First one being the proxy version which is high performance stuff for the animator to go crazy on with the bulk of the animation. Simply parented, cut, geometry to the skeleton hierarchy.

  2. The skinned version; with facial controls and manual jiggle/flesh controls etc.

  3. Hi-res version for final tweaking, simulation and caching.

Now, here is where I get lost a bit. The proxy and skinned rig could be one and the same, with switches. But you wouldn’t want to keep the high-res rig toghether with your proxy/skinned rig, right? It gets heavy? Which means that you have a separate rig, ready for replacement via reference.

Which is where logic fails me. How do you maintain the rig if the rig exists in two separate scenefiles?

My spontaneous solution would be to keep proxy and skinned in one scene, and then reference that to an empty scene, where you would then apply muscles, skin the higher resolution mesh and do collision fixes and better volume preservation etc etc. Feels solid enough. But then you wouldn’t be able to replace the reference. Right? Since there would now be dual namspaces? Or would you find a way around that?.. I’m getting lost already.

Halp?

edit: and Oh yeah, this is in regards to a Maya Pipeline, although I’m sure the method is quite similiar in other packages as well.

2

Allright :slight_smile: The slimmed down query;

How do you handle the highest resolution, final, mesh in regards to the lower level proxy rig for the animators?

3

I’ve never found multiple nested references to work the way I want them to. Something always breaks, so I’d stay away from that anyway (unless they’ve gotten A LOT more stable after Maya2008)

Sounds like if you’re keen on keeping the highest res rig in a separate file so you can replace the reference when it’s time to render, one way to accomplish this is to create an updating script. You would make whatever changes to the middle/low res rig, then open up the highest res and run the script to remove stuff to be replaced, import the changed rig, reconnect everything, and clean up. We did something similar to get around referencing woes, but it was WAY simpler than what you’re talking about because it was for games… no skin/muscle/jiggle craziness.

Might be overkill for your sized project but if you’re already creating the assets with script it might be easier than you think.

4

@Tyler yes, after 2008 References were cleaned up a good deal and are more stable when using assets.

You can do a few things- have a core bind /deformation rig that lives in its own file that matches the “rig” skeleton with the light animation mesh on it, batch export and import animation. Stable.

I would tend to keep the parent/cut up and the first layer of deformation rig in the same file, only separating the level 3/highrez sim file because often animators need to work with or see the final deformations to make a decision abut the pose or what ever. The file should not slow down that much with having that med- rez rig nodes all hidden.

You could then reference the high-rez #3 rig in to the animation files with the animation rig in to the anim file…while keeping the bind rig unloaded until its preview time.

This way two separate files in to one “scene” that gets animated and then you just need a script to turn the ref back on and then copy anim. or hook up direct connections/constraints between the “animation rig” and the bind rig.

This keeps you from having nested reference but lets you still use them for keeping files updated.

Love the work from your studio, it is really great.

5

What I did for last project, which included the Muscle Sim, and advanced Facial was like this :

Animation scene = animation body/facial rig + proxy + skin
//Just run switches for animators, also ability to import/export animation data of your rig
skeleton.

Simulation scene = corrective shapes + muscle sim rig + cloth setup + dynamics + Deformations.
//Just run switches for animators to on/off between different sims, also ability to import animation data of your rig, so here you can generate all necessary date for next layer like catch or whatever else you may feel it’s needed.

Render scene = high mesh + catches applied
//here import all the data and add smooth and other necessary operations.

I think you can have the last layer with first ones due to animators request.

Anyways it was my setup for Max, and i never tend to use Max ref tools.

6

[QUOTE=SuppleTeet;8135]one way to accomplish this is to create an updating script. [/QUOTE]

Sounds solid, but I’m afraid update scripts would get too tedious in the long run. We usually update our rigs several times per day, just adding small things to it whenever needed. Automating the changes every time, well… we would start cheating and add things on a scene per scene basis until the scene broke! :slight_smile:

[QUOTE=bclark;8142]You can do a few things- have a core bind /deformation rig that lives in its own file that matches the “rig” skeleton with the light animation mesh on it, batch export and import animation. Stable.[/QUOTE]

Though not as intuitive as I have hoped, this seems like the most elegant solution. Will give the nested ref thing another go too since things would get so much simpler and automated. Although that has broke before…

Love the work from your studio, it is really great.

Thanks :slight_smile:

[QUOTE=EhsanKiani;8149]…
Simulation scene = corrective shapes + muscle sim rig + cloth setup + dynamics + Deformations.
//Just run switches for animators to on/off between different sims [/QUOTE]

That’s interesting. You let your animators control the simulations?

and i never tend to use Max ref tools.

But surely you must use some sort of referencing workflow? :0

7

[QUOTE=marcuso;8164]
That’s interesting. You let your animators control the simulations?

[/QUOTE]

Actually i meant the sim artists!

8

I’d always recommend referencing, but not nested referencing. They’ve bug fixed a ton of issues in every version, 2011 is by far the best and most stable. We run a fully referenced animation pipeline, goes a little like this:

The riggers skin and create the character bindpose in a fresh scene, this is bones and skin + deformers etc. That’s then referenced into the rig file and the skeleton bound (constrained) to the rig’s skeleton - piggy backing if you like). We then have a character publisher that once ready for production, dereferences the scene, generates the cut-cut prozy geo from the high res mesh and checks the files, then store the rig ready for production.

The animators then reference this file in for all animation, the referencing we manage via an asset manager to make sure we handle namespaces carefully. At this point they have a toggle that goes from block proxy character, to cut-up final mesh, to final game mesh. Now if the master mesh gets too heavy you could always just not have the final mesh in the rig and reference swap to a version that contains it when you need.

9

[QUOTE=EhsanKiani;8177]Actually i meant the sim artists![/QUOTE]

Oh. :): Still gave me some ideas though. Hmm.

@Mark-J - Feels solid, but not entirely sure how it would fit in a smaller shortfilm/commercial production. :frowning: Like, what if you make some drastic changes to the rig, add some blendshapes or fix a bug you found late in the pipeline? Wouldn’t you have to do the work twice, once in the final and once in the cut-up version?

10

This is where publish scripts are great- any changes you do happen at the source file- then you just export/build a new anim file and send it out, you don’t have to fix something twice as long as the master file is always the source of down stream changes.

I did a very similar build process for the rigs I was working on for the last 8 years or so, even in max with its limited reference functions.

11

[QUOTE=bclark;8202]This is where publish scripts are great- any changes you do happen at the source file- then you just export/build a new anim file and send it out, you don’t have to fix something twice as long as the master file is always the source of down stream changes.

I did a very similar build process for the rigs I was working on for the last 8 years or so, even in max with its limited reference functions.[/QUOTE]

We’ve done the same thing here because we didn’t have much a choice. The concept is sound- update an authoritative file and push the changes downstream. How complex that is can differ widely based on your setup (in our case, it can take a week or more, because our animations are stored inside our files on control layers (PuppetShop) and we have hundreds of seperate Max files (and tens of thousands of animations). But it is, conceptually, the same.

12

Do publish scripts also apply to intricately rigged characters for film? Like with correctives and muscles, clusters and all, or is it mainly for skeleton-only type characters?

If it applies, how exactly do you create the publish script? Manually, or procedurally somehow? We are of rather simple nature were I work and would rather not add another step to updating a rig since it happens so frequently… I can see how it applies to a larger studio tho.

13

Marcus, you can keep it simple or more complex… the simple version for me (Rob is a much better code/pipeline glue tech than I am though) would be to have a script that merges in all the reference files, fixes name space issues , it might group or constrain/connect up nodes that need to be connected and then save/name the file to the animation directory.

This is just a simple example.

With Maya referencing, you can also use an option that lets you save changes back to referenced file so you can edit both from one file.

-that file is updated-and maya refs take care of the rest.

14

I don’t mind complexity. My goal is to have the end result be as flexible as possible.

For us, keeping things simple early in a character rig pipeline usually ends up making things very complicated at the end, bottleneck style. Merging all your references for instance. This makes things easy, sure. But when the time comes and you need that additional edit to your character applied across all of your scenes, you’re done for.

Simple is how we’ve done things in the past and we’d like to get away from that and into more collaborative waters.

15

Well in turns of flexibility running a bound skeleton to our rig has saved us on many occasions. As long as the underlying rig control data doesn’t change, we know we can bind any skeleton onto it and have that propogate upstream by just replacing the master rig asset. This can even buffer you from small skeleton position changes and orient setups as we constrain the rig and master skeletons.

One other thing that we’ve found help us be more flexible is to run a scale 1 rig system. In our Proceedural rig builder all the internal data is scaled internally to fit our 100percentile character. Above all the systems is a scale node who’s values are calculated by first measuring the height of the input skeleton (actually it’s hip height+spine) now if we reset that scale node to 1,1,1 all characters in the systems will be the same height. Why??? lets say you have a referenced walk for a male, now you want to reference swap that to a boy. Normally the animations wouldn’t share because of the world space differences, but with the scale node they will, because the world space is controlled and scaled down. If that makes sense

16

[QUOTE=marcuso;8216]Do publish scripts also apply to intricately rigged characters for film? Like with correctives and muscles, clusters and all, or is it mainly for skeleton-only type characters?

If it applies, how exactly do you create the publish script? Manually, or procedurally somehow? We are of rather simple nature were I work and would rather not add another step to updating a rig since it happens so frequently… I can see how it applies to a larger studio tho.[/QUOTE]

Yes publish scripts apply. How you set this up is a whole research project in itself and can be just as much if not more important than the rig itself.

The biggest issues with build scripts for complex character rigs is that it becomes very script heavy so small changes take longer to implement and push threw the pipe than they would otherwise. So while you win with getting overall complexity through the pipe you lose on iteration.

At Disney we had a build/publish system that was written in a proprietary markup language and worked like Photoshop layers with robust referencing… complicated as hell but allowed for awesome propagation of changes through the whole pipe.

Right now I’m working with a principle that every rig component is treated as a tool when it’s first designed, I can build and edit it interactively and the build code is generated “automatically” for the most part.

Further, I am working on a visual scripting procedural flow software that utilities node based networks to accomplish a very similar functionality we had over at Disney but in much more visual and user friendly way.

More on a topic of high res meshes, last game pipe I set up we had the high res skinned mesh saved in a separate file and imported as a nested reference to the character in question, if we needed to swap that reference was redirected to the hi mesh. Worked like a charm! Swapping was fast and animation was never corrupted since the rig itself was never swapped. This also allowed for swapping the look to different character all together assuming they are of the same rig type (which in games is pretty common)
This however is not as trivial to set up on a higher complexity character but possible none the less.

17

Thanks for the great insight, exactly the kind of stuff I’m looking for.

> Right now I’m working with a principle that every rig component is treated as
> a tool when it’s first designed, I can build and edit it interactively and
> the build code is generated “automatically” for the most part.

Would I be correct in assuming that you would be using an autorigger of some kind, where the “tool” would originally be designed, and not doing it the manual labor way? I’m guessing that setting up that automatic script generator would get quite simplified when using an autorigger since conventions would remain very consistent in and between characters?

> Further, I am working on a visual scripting procedural flow software that
> utilities node based networks to accomplish a very similar functionality we
> had over at Disney but in much more visual and user friendly way.

Oh this you have to tell me more about. :slight_smile: Do you mean just for updating the rigs or rigging altogether?

> More on a topic of high res meshes, last game pipe I set up we had the
> high res skinned mesh saved in a separate file and imported as a nested
> reference to the character in question…

See, I like the idea of nested references. Our characters aren’t as complex as I can imagine some characters are so this might be the ideal solution. Once solved that is.

18

@merging refs- I think I was not clear- you never save your working files merged, only the published anim file- it is an “exported asset” that when you need to update something your always doing those changes/fixes in the rerferenced system and it keeps things fluid… after the fix- export the new “animation ready” file and that then shows up updated in all the (anim cip scenes) that would reference the animation file.

this lets you use a heavy refernce build file but animation never gets a nested/file dependent rig to animate with.

this level of separation also allows for a “safe” buffer between any changes /fixes you do and their final animation shots and makes for easy roll back if you break something.

but you always have your "photo shop , full layer psd) master maya file to rig in. Animation just gets the single image :slight_smile:

Brad

Great thread though, I love hearing better ideas than what I come up with.

19

[QUOTE=marcuso;8234]
Would I be correct in assuming that you would be using an autorigger of some kind, where the “tool” would originally be designed, and not doing it the manual labor way? I’m guessing that setting up that automatic script generator would get quite simplified when using an autorigger since conventions would remain very consistent in and between characters?
[/QUOTE]

These ‘tools’ are part of the auto rigging system but allow for manual or interactive rigging. For example if I have a foot rig component I can open up a foot build UI, mark ankle and ball pivots, set a few other arguments and click build. Then in the script editor I have an output of the few lines of code I need to put in my auto rigger to achieve the same result.
This helps get around the fact that if not everyone on your staff is very script savvy (which happens with large turnover and 911 shows) they can still do the work that seamlessly integrate into your pipeline.

  • This however is a basic example to explain the idea in a nutshell …

[QUOTE=marcuso;8234]
Oh this you have to tell me more about. :slight_smile: Do you mean just for updating the rigs or rigging altogether?
[/QUOTE]

Both. I use it to build rigs, design publishing pipeline, animation preview render pipeline and etc… It’s not tied to Maya or any cg tool either, the goal is to have a broad application. It’s useful anywhere you need to control procedure flow and have a good overview of the data relationship between the different steps, like a rig auto build process for example.

It’s somewhat inspired by kismet from Unreal.

20

[QUOTE=ShadowM8;8239]

  • This however is a basic example to explain the idea in a nutshell …[/QUOTE]

No I think I understand. I went through rather lenghty 3dbuzz tutorial on modular rigging in python that I think touches on some of those ideas.

But to be clear, using the foot as an example, you arent actually editing the rig, but instead recreate the foot, adding the changes to where you left off last time you built it, and then simply replace the old one?
Keeping naming and previous controller attribs the way they were for the animation to stay put etc.?

[QUOTE=ShadowM8;8239]
Both. I use it to build rigs, design publishing pipeline, animation preview render pipeline and etc.[/QUOTE]

Using it for rigging, you mean in terms of visualizing the hierarchy etc., or does it somehow hook into mayas rigging tools directly? Does it hook into various other apps, like sort of a glue-type-deal? I’m imagining this kind of monster app with nodes for everything from storyboarding to renderpasses. to compositing to delivery. Stop me if I’m going too far. :slight_smile:

Love hearing about how much work go in to in-house tools like this. Makes me re-think a couple of things.