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
I don’t think I’ve seen a better summary of the relative strengths and weaknesses of the two tools.
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.