Setting up new Maya pipeline - inputs please!

Hi guys!

So I think this “questing” will be very talk-y, but I’m more looking for general input, experience and ideas.

So I’m working on a quite small studio (around 40). This is the first time in a long time we’re working on our own in house project. This means that there is no established pipeline when it come to the art department. Maya 2014 is the standard tool, though a few are working in 3D Max and Blender because of previous project with other studios.

I’m first and foremost looking to set up the pipeline for the project I’m on. But I want to establish some rules so the tool library can easily be adopted by the rest of the studio when needed. At the moment I’ve written some animations, rigging and exporting scripts, most of them in PyMel. The user base is minimal at the moment (me and an artist) so I feel that this is the change to make something more stable before a lot more people start using the scripts. I already feel the current setup scale really bad the more characters we get!

  1. Which module should I use? I really like PyMel, but it might be more flexible just using maya.cmds? Or should I learn API 2.0? I don’t think there is a lot of Python knowledge except me. The last scripts I saw from the studio was a couple of years old and written in MEL.

  2. Is it really worth trying to setup our own pipeline, or should we maybe use a already existing pipeline setup like Red9’s tool and build on top of that?

  3. What’s the standard for sharing different tools to different projects? Do you have some tools that are general and some of that are project specific?

All inputs and feedback are welcome!

Well I’m slightly biased as you’d expect, Red9 has been in production at both Crytek and a large number of other studios for a few years now and certainly at Crytek is was the core of all the systems. We ran the animation tools native as there’s pretty much every tool support you could ask for, but we then used the MetaData codebase to write our bespoke export pipeline, but using all the power of Meta. We also modified the boot management to support multiple studios and multiple bespoke projects, all of which we treated as packages within the core.

Is it worth writing your own pipeline, well that depends on your experience, how fast you want to get it up and running and more importantly, how quickly you need it stable. It also depends whether designing a fresh pipeline is something that you want to do as a challenge for yourself? Sometimes it’s nice to start from fresh so that you have a full grounding of what the systems are actually doing.

If I were setting a new pipeline up I’d use Red9 as a base, as you’d expect, and expand around that. There’s a lot of hidden hooks in the systems to allow for project based integration of custom workflows. These have all been added so that I can keep the codebase open source and flexible, whilst having our own bespoke hooks to the tools at the studio. The last thing you need is a core that can’t be expanded or modified simply.

You may not also be aware that Red9 has now gone into Consultancy to offer just this kind of thing, helping studios integrate and utilize the Red9 core for their own pipelines as well as any bespoke development work or consultancy you may need. We’re talking to a lot of studios in a similar position as you at the moment.

We also offer full rigging and facial pipelines. The facial is based on our full performance cinematics facial tech and we have a great example that we’ll be able to show after Christmas, we’ve just delivered rigs for a TV commercial but have to wait till it’s been aired before we can start to demo it.

As for body rigging, well we have very ambitious plans for the up-coming year which will allow people to subscribe to our pro-pack systems, can’t say much more than that at the moment.

So to sum up, I’d at least have a damn good look at our Red9 codebase, if you want more info drop us a line. If you’d like to talk about how we may be able to help your studio then again, by all means drop me a mail.

www.red9consultancy.com

thanks

Mark

red9 is pretty good. however, my Japanese workmates prefer to use a similar tool just because it is in Japanese…

i have written a good majority of my company’s pipeline and rigging tools and we are thinking of integrating some parts of red9 into the system on future projects.

which goes back to the point of writing your own tools or just expanding upon an available system like red9/guren/eST/animation mentor picker thing,etc. personally, it all depends on your projects and the company culture. in my company, things very different compared to animation studios elsewhere in the world. the nature of the projects are different, the attitude of the people are different,etc. for our case, writing a special in house tool for our pipeline is the way to go and then adding bits and pieces of other people’s codes into the pipeline to enhance it.(of course, you have to credit the source so we always put credits on almost every tool we have that came from elsewhere. check the licensing as well.) writing your own tools can be expensive,too. but the good thing is you are mostly in control of every aspect in your pipeline. here in Japan, we use motionBuilder heavily from small to big productions and any tool that you use should be considered in your design. for example, the rigging system that i made in 2007 was rewritten and updated to support a separate fbx heirarchy for import and export to motionBuilder.

i prefer to use cmds since this is my preference, it also makes the code more accessible to other people in the future since more people are familiar with cmds.

the biggest bit of advise i can probably give is to always listen to your artists. make your tool work for them so that they finish more stuff faster. design the UI according to what they want. if you only have 1 person for your QC, then he should not be a tech guy, this way you are getting feedback from a genuine end-user POV.

the way we design our in-house tools is we always have room for expansion or modification. things are chopped up into modules and managers, these in turn read a master settings file for each project which in turn will implement certain project specific stuff like playblast format, resolution, publishing parameters,etc.

in the end, just keep things simple. this is just my lowly opinion, coming from a dental school dropout who ended up in CG

Thanks both of you!

I think the most important thing is to get things up and running as fast as possible. This means I wil probably first look at the animation tools and I maybe will have a look at Red9’s tools since some of the tools I’ve written doen’t work 100% with animation layers. I would love, if you’re ok with it Mark, to maybe have a chat with you sometime after New Years to get things going properly.

I desperetly need to update the rigging module. I read an article by a guy from Weta where he talked about how they are scripting all rigs. Maybe I misunderstood but I thought that this could maybe be a better way of working the needing to do UI windows for all rigging stuff all the time, when it’s only me who do the rigging anyway. What does you guys think?

I’d say the real first thing to work on is the what get’s passed along the pipe and how.

Decisions you make there – from file formats to versioning to naming conventions – are going to be shared with other departments or maybe outsourcers, which means there will probably be political or technical negotiations to worry about. Plus you’ll need to worry about maintaining compatibility as you go forward, so you need to make decisions you can live with for a long time. The costs of getting that wrong are really big, and they can complicate things enormously.

i think what the gentleman from weta was talking about is that they use an auto-rigging system. personally, i think that every part of the basic character rigging pipeline should be automated by scripting except for accessories and additional setup. making the machine do all the driving is not good and it restricts freedom. in productions, big or small always remember to keep things as simple as possible. simple is best.

[QUOTE=Theodox;26415]I’d say the real first thing to work on is the what get’s passed along the pipe and how.

Decisions you make there – from file formats to versioning to naming conventions – are going to be shared with other departments or maybe outsourcers, which means there will probably be political or technical negotiations to worry about. Plus you’ll need to worry about maintaining compatibility as you go forward, so you need to make decisions you can live with for a long time. The costs of getting that wrong are really big, and they can complicate things enormously.[/QUOTE]
and this,too…