The Guerrilla Maya Pipeline - your best advice


#1

Hello! My name is Ed Whetstone, and I have spent the last few years developing guerrilla tactics for individuals, small teams, and schools to get the most out of Maya / mental ray without a professional pipeline.

     Ultimately, I'm planning on writing a free online textbook that explains how to build a zero-pipeline Maya production from scratch.  Unfortunately, my focus has been on lighting/rendering, and I don't know as much about rigging, animation, or texturing for efficiency.
     
     So I'd like to start this thread for your best advice on these topics:
     
    
     [u][i][b]General:[/b][/i][/u]

[ul]
[li]Referencing Workflows[/li][list]
[li]Blog posts from Mark Jackson dealing with problems in file referencing:[/li][list]
[li]Maya Referencing[/li][li]Reference Edits[/li][/ul]
[li]File referencing has a tendency to break when used with render layers. See this thread:[/li][ul]
[li]“error while parsing arguments”[/li][/ul]
[/list]
[li]Naming Conventions[/li][li]File Versioning[/li][li]Communication Tools[/li][li]Asset Organization[/li][li]Reviewing Work[/li][/list]Layout:

[ul]
[li]Scene Assembly (2013 SAP)[/li][/ul]Rigging:
[ul]
[li]Rig updates in animation[/li][li]Model updates to rigged assets[/li][li]UV updates to rigged assets[/li][li]MEL and Python tools[/li][li]Naming Conventions[/li][li]Other Advice[/li][/ul]Animation:

[ul]
[li]Baking and point-caching animation[/li][li]Alembic, .mc, and other cache-file formats[/li][li]File referencing procedures in animation[/li][li]Working with sets and props[/li][li]MEL / Python tools[/li][li]Other Advice[/li][/ul]Texturing:

[ul]
[li]Organizing Textures[/li][list]
[li]MEL script: File Texture Manager[/li][/ul]
[li]Organizing shaders in the hypershade[/li][li]Updates to shaders[/li][li]Naming Conventions[/li][li]UV unwrapping huge numbers of assets[/li][li]MEL / Python tools[/li][li]Other advice[/li][/list]Other free pipeline tools:

Open Pipeline

If anyone has any other thoughts or ideas to contribute, feel free!!


#2

added a couple links on file referencing


#3

God where do you start??? Actually it’s a question I’m now asking myself again as I’m moving from Eurocom after 11years of building a solid animation pipeline, to start all over again at Crytek from scratch.

So a few pointers. I’d run referencing all the way, let Maya handle updates to rigs so that your animators don’t have too. Referencing in Maya keeps getting better, and with all the Asset and Scene Assembly work their doing it’s only going to continue. We’ve run fully referenced animation pipelines since Maya7 now and we honestly don’t think about it anymore.

Naming is an issue if you don’t run characterSets. Actually I’ll qualify that a little, naming in rigs should always, ALWAYS be maintained at all costs if possible. Running a procedural rig helps as we know everything is always the same. CharacterSets and index orders within them help with everything else.

Base rigs: A few pointers to help issues:

Firstly never name anything as you’d want. So if you have a character called JACK don’t ever name anything on his rig JACK_. Always call everything neutrally and let Namespaces on referencing name the characters for you. This way when you swap referenced rigs you can rename the namespace and not worry about nodes not linking up.

Think about scale if your running referenced rigs. Why??? well lets say JACK is 6ft and you’ve animated him in 500 shots. Now you want to switch all his references to point to SID who is only 5’9" ooopss now all your anims are ****ed! So think about scale. We’ve always built all our rigs internally to a set scale and then scaled them up in code during the rig building process so that this isn’t an issue. It doesn’t matter if SID was 4ft or 10ft, internally the rig is still the same size as JACK so the animations still map correctly.

OPTIMIZE OPTIMIZE OPTIMIZE you wouldn’t believe some of the shit that gets left in scenes which them propagate over time to destroy Maya. We’ve had scenes with 700,000 camera bookmarks in before, I SHIT YOU NOT! So keep it clean!!

But yes, reference your rigs.

Finally use a bind to take animation data to your master skeleton. We have a specific definition between what’s a Rig and what’s a character. The rig stays the same, in fact the same Rig file for most Pre-Published rigs. Our rig file references a Skin file who’s skeleton is just bound to the internal Rig skeleton. When a rigger wants to update the character or make a new one he just switches the skin reference then publishes the file. The publisher dereferences the file and runs a ton of optimizers and checks before pushing it out to the Asset database ready for the animators to use.

If you’re starting to code tools never rely on naming at all, use attribute markers or some form of MetaData to get round your rig in code. And a really good pointer if your starting a new pipeline, expect and code everything to expect LONG NAME and deal with namespaces. This way you won’t suddenly get bitten in the future

Wow, I’m waffling, coffee I think

Mark


#4

For texturing, File Texture Manager has proven a great boon for me. You can easily source and copy all your files in any given scene for use on a network rendering pipeline, or even just for transferring between workstations.


#5

Seconded.

Great stuff, Mark! I’ll admit, a lot of what you’ve just said is still gibberish to me, but I’m learning. The goal is to help the next generation of CG students understand what a pipeline is and how to work within one in a clean, efficient way.


#6

I’m pretty sure I’m misunderstanding you… is this in the ballpark of what you’re talking about? (image below)


#7

Near enough. We don’t tend to reference the first two, ie, skeleton and skin separately into a file. Our SRC file (source character) is just the skeleton and skin, its the base file that goes into engine as our BindPose. Other than that yes, the Published file which is the final characterRig is referenced into all animation files


#8

Great stuff guys.

I’m not sure how much I can participate, but I did just go through a fairly big production.
We had a lot of issues with referencing, losing shading groups and such.

But we had a published model, referenced into rig file.
That same model was referenced into shading file.
The rig was then referenced into animation scene, where we would animate it.
Once done with animation, we would geo cache it.

That is the end of animation. When lighting, we would reference the shading model in, apply geo cache and we were ready to render. We found this really clean, and it was a great joy to light a scene, without having a rig in there. It just seemed so much cleaner. But I’m sure for you guys it’s basic stuff.

One thing I found interested afterwards, was seeing the “gears of war” demo of how they did the rigging and pipeline. Because we found the reference system a bit unstable, we were looking at ways to eliminate layers of reference when possible.
One way of doing that, is to not actually have the rig as a maya scene file, but only exist as a script file (of course this means one must be able to script the rigging process).
But then instead of referencing in a rig file, you just create the rig from scratch in the animation scene.
If you have access to a way of storing animation data, that can be used to hold the animation data temporarily, if the rig needs to be regenerated in the animation file (rig update).


#9

That’s one of the reasons we always have a published rig file that has no referencing. That way there’s only ever one layer of reference in the anim files but the riggers still have a referenced skin that they can switch, that layer of referencing just never gets into the animation pipe. The beauty of referencing is that any small changes to the rig just propagate through automatically, and it is rock solid if managed carefully


#10

Hey Guys,

I’ve had a rather good run at referencing in Maya since way back in Maya 5 and 6.

We have always done a nested reference system, and in the last 2 projects at THQ I had skeleton referenced into model which was then referenced into rig which in turn was referenced into the animation file.

I had a system that allowed the model to be switched in the animation file by replacing references, though the models that were being replaced had to be from the rigs skeleton…which always kept the same naming and markup through all the characters.

Prior to that we used a publishing system that collapsed the references into a single file and that was used.

I think I could count on one hand the number of times in a project referencing screwed a scene on us.

That would be attributed to pretty much what mark said above, naming, clean scenes and generally having a good pipe that everyone understood who ‘touched’ the skeleton, model and rig.

Dave


#11

thanks for this thread… super interesting…
hope we get more info out of this… there is so less info about animation pipelines…


#12

Well for some of the most complex scenes we have maybe 7000frms of Mocap data, 15 full referenced rigs, referenced weapons and vehicles and at any time we can switch any reference and update any character. Now we do run custom management tools to do this. Thats not to say that Maya can’t manage it, it’s just that we prefer the animator not to mess around in the reference editor, I’d rather give them pipeline tools that does it all for them. This way we manage the namespaces, characters and have hooks to run any custom code during the switch.
We also give them an option when switching characters to use a copyKey style swap…this is really useful as it ensures that the new rig has no bad referenceEdits taken over. So this time the new rig is referenced in, the animation data copied over, and the old rig unloaded.


#13

An excellent starter for pipeline basics and organizational issues – scroll to bottom for video:

Pipeline Basics


#14

updated the original post. I’m hoping to expand this a bit more soon.


#15

this scene assembly overview could be from interest…
http://vimeo.com/51283849


#16

oglu, see also this link: http://area.autodesk.com/blogs/stevenr/maya-2013-sap-scene-assembly


#17

I’ve started working on a metaprogramming framework for MEL to help with this endeavor. The idea is to focus on flexibility above all else – the code that runs the user’s pipe will all be procedurally generated from more general templates, which in turn will be generated from initial conditions set by the user, e.g. a naming convention spreadsheet. The system will be inherently recursive, so I can go as many levels deep as I need to.

Not only is this a good exercise in reading, writing, and manipulating text files with MEL, but I’ve already seen efficiency gains in my own tool writing. Right now I’m still printing headers and simple procedures, but soon I’ll be able to write fairly complex, dynamic UI code in minutes, customized down to the variable names.

I’m working on procedural commenting as well, which I think will be pretty snazzy. The end result will be to automatically comment a procedure with its name, return type, and inputs. These comments can then be parsed by a “help” tool.

I’m still working on the specifics of what the ideal guerrilla pipeline looks like, but having these tools in hand will definitely help me get there… might be 2015, but I’ll get there!


#18

Posting to keep the thread alive. I’m still very interested in this idea, and if I find anything interesting I’ll put it here.

For now, though, the pipeline project is dead in the water. We’re moving away from Maya at RFX, so I’m going to be focusing on developing for the new tools here.


#19

You said that you were moving away from Maya at RFX. What are you moving to? Houdini?


#20

I’m not sure what’s public or not – so I’d better not say!

I’m pretty sure rigging/animation will still be Maya, but lighting won’t.