CGTalk > Software > Autodesk Maya
Login register
Thread Closed share thread « Previous Thread | Next Thread »
 
Thread Tools Search this Thread Display Modes
Old 08-15-2012, 08:16 PM   #1
EdtheHobbit
File read in 0 seconds
portfolio
Ed Whetstone
Lighting Artist
Richardson, USA
 
Join Date: Oct 2007
Posts: 664
Send a message via AIM to EdtheHobbit
The Guerrilla Maya Pipeline - your best advice

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:


General:

  • Referencing Workflows
  • Naming Conventions
  • File Versioning
  • Communication Tools
  • Asset Organization
  • Reviewing Work
Layout:
Rigging:
  • Rig updates in animation
  • Model updates to rigged assets
  • UV updates to rigged assets
  • MEL and Python tools
  • Naming Conventions
  • Other Advice
Animation:
  • Baking and point-caching animation
  • Alembic, .mc, and other cache-file formats
  • File referencing procedures in animation
  • Working with sets and props
  • MEL / Python tools
  • Other Advice
Texturing:
  • Organizing Textures
  • Organizing shaders in the hypershade
  • Updates to shaders
  • Naming Conventions
  • UV unwrapping huge numbers of assets
  • MEL / Python tools
  • Other advice
Other free pipeline tools:

Open Pipeline



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

Last edited by EdtheHobbit : 10-23-2012 at 09:10 PM. Reason: update
 
Old 08-16-2012, 08:41 PM   #2
EdtheHobbit
File read in 0 seconds
portfolio
Ed Whetstone
Lighting Artist
Richardson, USA
 
Join Date: Oct 2007
Posts: 664
Send a message via AIM to EdtheHobbit
added a couple links on file referencing
 
Old 08-17-2012, 08:18 AM   #3
Mark-J
Know-it-All
 
Mark-J's Avatar
portfolio
Mark Jackson
CEO & Founder
Red9 Consultancy
United Kingdom
 
Join Date: Feb 2005
Posts: 408
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
 
Old 08-17-2012, 08:10 PM   #4
InfernalDarkness
Madness. Madness, I say!
 
InfernalDarkness's Avatar
portfolio
Sho Pi
CG arch/viz
Seattle, USA
 
Join Date: May 2008
Posts: 5,586
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.
__________________
Commodore 64 @ 1MHz
64KB RAM
1541 Floppy Drive


"Like stone we battle the wind... Beat down and strangle the rains..."
 
Old 08-17-2012, 08:57 PM   #5
EdtheHobbit
File read in 0 seconds
portfolio
Ed Whetstone
Lighting Artist
Richardson, USA
 
Join Date: Oct 2007
Posts: 664
Send a message via AIM to EdtheHobbit
Quote:
Originally Posted by Mark-J
God where do you start???


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.
 
Old 08-17-2012, 09:47 PM   #6
EdtheHobbit
File read in 0 seconds
portfolio
Ed Whetstone
Lighting Artist
Richardson, USA
 
Join Date: Oct 2007
Posts: 664
Send a message via AIM to EdtheHobbit
Quote:
Originally Posted by Mark-J
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.


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

 
Old 08-18-2012, 08:38 AM   #7
Mark-J
Know-it-All
 
Mark-J's Avatar
portfolio
Mark Jackson
CEO & Founder
Red9 Consultancy
United Kingdom
 
Join Date: Feb 2005
Posts: 408
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
 
Old 08-18-2012, 09:12 AM   #8
doffer
Keying everything
 
doffer's Avatar
portfolio
Christoffer Andersen
Animator
Valence, France
 
Join Date: Dec 2005
Posts: 906
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).
__________________
Website
Steam Punk Challenge
 
Old 08-18-2012, 09:18 AM   #9
Mark-J
Know-it-All
 
Mark-J's Avatar
portfolio
Mark Jackson
CEO & Founder
Red9 Consultancy
United Kingdom
 
Join Date: Feb 2005
Posts: 408
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
 
Old 08-18-2012, 03:16 PM   #10
floppydj
New Member
 
Join Date: Dec 2002
Posts: 6
Quote:
Originally Posted by Mark-J
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


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
 
Old 08-18-2012, 06:04 PM   #11
oglu
Christoph Schädl
 
oglu's Avatar
portfolio
Christoph Schädl
Austria
 
Join Date: Mar 2003
Posts: 3,128
thanks for this thread... super interesting...
hope we get more info out of this... there is so less info about animation pipelines...
__________________
...
 
Old 08-18-2012, 07:23 PM   #12
Mark-J
Know-it-All
 
Mark-J's Avatar
portfolio
Mark Jackson
CEO & Founder
Red9 Consultancy
United Kingdom
 
Join Date: Feb 2005
Posts: 408
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.

Last edited by Mark-J : 08-18-2012 at 07:26 PM.
 
Old 08-18-2012, 07:24 PM   #13
EdtheHobbit
File read in 0 seconds
portfolio
Ed Whetstone
Lighting Artist
Richardson, USA
 
Join Date: Oct 2007
Posts: 664
Send a message via AIM to EdtheHobbit
spelling

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

Pipeline Basics

Last edited by EdtheHobbit : 10-23-2012 at 07:23 PM.
 
Old 10-23-2012, 07:23 PM   #14
EdtheHobbit
File read in 0 seconds
portfolio
Ed Whetstone
Lighting Artist
Richardson, USA
 
Join Date: Oct 2007
Posts: 664
Send a message via AIM to EdtheHobbit
updated the original post. I'm hoping to expand this a bit more soon.
 
Old 10-23-2012, 08:24 PM   #15
oglu
Christoph Schädl
 
oglu's Avatar
portfolio
Christoph Schädl
Austria
 
Join Date: Mar 2003
Posts: 3,128
this scene assembly overview could be from interest...
http://vimeo.com/51283849
__________________
...
 
Thread Closed share thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 09:14 AM.


Powered by vBulletin
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.