Transitioning studio from 3DS Max to Maya

maya
max

#21

[quote=“CLR, post:18, topic:8646, full:true”]Here are some of the reasons we are moving - whether these are valid or not is debatable:

  • Referencing in Maya, although not perfect provides a less waterfall pipeline which is invaluable. 3dsMax’s X-Ref, even after the advancements provided in 2017, is not production ready from our preliminary tests.
  • Maya can run standalone. 3dsMax sort of does, but drags all of the UI with it and is cumbersome (seemingly 2018 should fix this).
    [/quote]
    Haven’t worked at a studio where 3dsmax was the primary DCC package, but these two factors alone would be a major handicap. Depending on how bad the situation is, the pipeline we built around Maya might not be realistic in a Max setting.

#22

Remember that most game pipelines are in fact built around Max. Depending on your tools it’s not impossible to do in Max - it most likely will be just different (quite possibly even better).

X-Ref in Max has received constant updates, bug fixes and improvements. Although not perfect (even Maya is far from it) it does the job done for most cases. It’s rock solid for static geo AFAIK.

Not sure what you mean by “standalone”. That can be understood in various manners. Do you mean just not launching the UI?


#23

Maya standalone is Maya’s python console from the command line, without the viewport overhead when processing jobs and loading files, or time wasted loading Maya’s UI dependencies. At work I do a lot of time-intensive, computationally expensive, batch jobs where standalone saves a considerable amount of processing and iteration time.

I just cannot see the production I’m in working without a lightweight commandline DCC option and a referencing system stable enough for skeleton iteration. Again, I don’t know firsthand the current state of all this in 3DSmax or the app’s future roadmap, just that it has been a problem for others in the past (watch Richard Katz’s GDC talk).

If Max is indeed still behind Maya here, I doubt Autodesk will let it be for long. All the more reason to get in contact with them. The more complex game character assets get, the more important all this becomes.


#24

I can agree with this. I don’t know the state of X-Ref, but we do rely on references heavily when it comes to our animation pipeline.

Does X-Ref allow for multiple levels of references? For example our Animation scenes reference our character rigs, which reference the actual skinned meshes (or proxies if the mesh it to complex).


#25

I think this is in danger of going into fanboy land. Understanding how the software fits into our studios is part of our jobs – partisanship isn’t. Both pieces of software do well in the right hand – and anybody who claims to be a pro should be able to be productive in either. But they aren’t interchangeable.

Having worked on pipelines large and small in both packages, I’d say Max’s biggest strength is modelling tools. Maya modelling is equally capable in the right hands – but you need more training and experience to be equivalently productive. OTOH Maya’s top capacity is probably higher: for the small percentage of power users who really know how to take advantage of scripting and automation Maya is more powerful. But those folks are rare and always will be. If you’re a studio which thrives on model content, Max is probably a better bet (particularly if your business model inclines to large numbers of junior people, instead of a smaller number of vets).

The situation is reversed for animation. Dominating all the tech stuff is the fact is that Max’s animation ecosystem isn’t that great, even if the tools are workable. There are plenty of talented Max animators – but there are far, far more talented Maya people. It’s not that Maya makes them better – it’s that the market for animators is Maya-centric and there’s no reason to think that’s going to change: Max and Maya are competitive in games; Max is not competitive with Maya in film/VFX. The premier animation schools, especially Animation Mentor (which is the only one that really catches the eye of my animation director when looking at resumes) skew very heavily towards Maya. A good max animator – and there are more than a few – can always get a job… but a studio can not always get a good Max animator. So studios which want to hang their hat on animation content are going to have a hard time sticking with Max.

As far as infrastructure… There are good points to Max’s native animation, to Character Studio, and to CAT – but they don’t play well together and they don’t always play well with MaxScript either. Maya has gradually lost the edge it traditionally had in this department: at more than 20 years old the original architecture is showing its age too. But on the whole the underlying architecture of the Maya animation system is more predictable, consistent and expandable. @Mark-J has it right: what you get with Maya out of the box is less – but the platform you have for building your own infrastructure on top of it is better: Structurally Max is built around plugins and it doesn’t exert strong API control over what those plugins look like, how they work with each other, or how they are scripted. Plugin-based design is why Max is so quick to pick up new renders and modeling tools. It’s also why it’s a bad pipeline citizen.

The C# and Python integrations help to close the gap. Depending on your workflow that can be enough: If you mostly want to add some external functionality to Max, dotnet or MXSP will let you talk to a network or a database or move files around just fine. If you want to do scripted content inside of Max, thought, they suffer from the same inconsistent level of access to functionality as Max animation. Adding capable full-purpose language support to Max makes life far easier when writing glue code: but f your exporter script breaks because the user closed the command panel, it doesn’t matter what language you’re using.

One thing that is true for both platforms: if you’re afraid of switch costs for technical reasons, you’re doing it wrong. Tightly coupling your actual content to the specifics of your DCC app is a bad idea no matter what package you use: it puts your studio at the mercy of other people’s business decisions. What do you think became of all those studios who hung their hats on XSI? You can and should design your pipeline around data flow, not around the movement of specific file types. Get your data out in an open, readable and long-lived format that doesn’t depend on one vendor, and then have your importer reformat it for your engine – otherwise you end up stuck on some outdated version because they dude who wrote your custom binary exporter left and nobody wants to touch it. Exporters are inherently stupid and boring – holding your whole business hostage to them is crazy.

If you are rigorous about keeping DCC concerns inside the DCC and content data outside the DCC, the costs of switching go way, way down. Because these decisions tend to be made on emotion there’s a high, high chance that at some point in the life of a studio it will end up becoming split – one department or another will use political power to make sure they get to keep their favorite tool, even if it imposes ridiculous costs on the studio by making the pipeline twice as complex and expensive. You need to fight hard to make sure that when that happens (and its happened at 50% of the places I’ve worked at!) it’s not going to destroy your productivity. I know one studio that did it so wrong that just manually copying files back and forth from the Maya animation pipe and the Maya modelling pipe was basically a full time job : a tremendous waste of time and energy.

The rise and fall of XSI proves you can be technically superior and fail to get a sustainable share of the market: artists and animators tend to be emotionally attached to their tools and will resist change for that reason. Our role is to have an accurate understanding of the costs and benefits, not to fall in love with one tool or the other. Leave that to the production guys.

Related: Sigh


#26

Thanks for taking the time to inject some of the clear-eyed, erudite wisdom that you’ve so frequently shared with our community, Steve. :smiley: I don’t think I’ve seen a better summary of the relative strengths and weaknesses of the two tools.

but f your exporter script breaks because the user closed the command panel, it doesn’t matter what language you’re using.

:laughing: Yeah, that’s certainly a point of frustration with 3DS Max. MAXScript is at times very dependent on the state of 3DS Max’s UI. That said, it can be extremely powerful if you’re willing to work through the eccentricities.