Request for Legacy Maya file compatibility

#1

There was a post here from an Autodesk rep here asking end users about their current satisfaction with Maya which I can’t locate right, but there’s another topic that should be raised besides just the desire for the return of perpetual licenses.

One thing about modern versions of Maya that will put off long time users that stayed with their perpetual licenses from upgrading is the lack of import of all Maya binary and ascii files back to Maya 2012 and further.

Versatility and compatibility has been a hallmark of professionalism since the earliest days of skilled professionals establishing themselves as professionals with professional standards. Locking those actual Maya files out from Maya 2019 and beyond ties the hands of some professionals that have been working with Maya for more then three or four years and it’s just unprofessional.

There’s a lot of value and time saving data in those files. Simply telling people that have been using Maya for ten years or more that they are SOL and their only recourse is to partition their individual files into incomplete sub- file formats like Objs, FBXs etc. that’s deplorable…IT’S NOT GOOD ENOUGH.

If the files have to be partitioned anyway, for a lot of end users there’s little to no real advantage in selecting Maya as their DCC platform unless it’s required as these sub-files could be imported to Houdini, Cinema 4D, Blender etc. and the laborious task of reconstructing whatever was in the original file to the best one can will be more or less the same. Also the native import of .blend files at this time would be helpful for groups that work in mixed DCC tool environments.

#2

Thats why the industry is jumping onto USD files as the new pipeline backbone. Backwards compatible files are the worst you could do for inovation. You just need the result of your work stored in a file.

#3

Maybe in a couple of years, but everything that’s in the all those Maya files from all those years is not in a USD file.

Maya has been in production for professionals since 2003, that 17 years and 14 years of work by thousands of people that’s more or less inaccessible in the same software that only has 3 years on the market. Ridiculous.

When you can’t open a 2016 file in the 2019 version of the app that was released in 2018 with correct render layers represented in some usable way and you can’t open any previous dated files from years that’s just a major flaw.

#4

I think that this is the one. Tell me your satisfaction with Maya or 3ds Max

Actually, Maya v1.0 came out in 1998. That makes it 22 years as of this coming February. That’s not including the carry over user base from PowerAnimator and Wavefront. Maya is basically just a Frankensteined rewrite/fusion of the two. Its core design and use in production goes as far back as 1988.

And that comes across as a shock… how? :stuck_out_tongue:

Look. If you own a legacy version, Autodesk doesn’t care about you. They’ve got your money. They’re interested only in new money. That’s why they’re pushing subscriptions, to maintain that flow of new income. Autodesk isn’t in the business of making software. They’re in the business of selling it. They’re all about milking that cash cow.

First they ditch perpetual license sales in favor of subscriptions. Then they stop supporting activation of perpetual licenses older than “x” years, effectively forcing you to subscribe if you want to continue using. (The side consequence here is that these perpetual license are now not so perpetual.) Next they create an indie version so crippled and incompetently executed that you’re forced to go with a full subscription if you want an actual Maya experience.

If it seems as if they’re not doing much about backwards compatibility that’s because they’re not. They don’t care. Autodesk does everything in their power to push you toward subscriptions and thus paying in perpetuity. That they even provide ANY updates beyond general compatibility is secondary. They could go without any major features for years and not care because their business model has shifted.

Contrary to popular belief, Autodesk no longer sells software. They sell subscriptions. Knowing that, I wouldn’t hold my breath waiting for enhanced backwards compatibility. As they push more users to subscriptions, the cries for such functionality will quiet. Anybody still left on an old version or with old files will be told to either use non-ma/mb export, 3rd party conversion solutions, or just suffer.

Good luck with replying to their “how can we help” type threads too. In recent months, they asked for input and were told about the inadequacies of the Indie version. Their response was a “fake” indie pricing structure. That brought the full version to indie users a low price… for only 12 months. The fine print was that they’d forced into full subscription pricing via auto-renewal. Of course, they’ll tell you that it was a limited promotion thing, but that’s not exactly how it was promoted. They touted it as a real solution to indies. Sleazy and further proof of what they really sell - subscriptions.

I honestly and genuinely feel for you. I do. I hold a valid Maya subscription myself and it’s only out of necessity, not legitimate desire. If I had any inkling that they had the end users’ best interests at heart, I’d tell you. Personally, however, I think that they’re far more interested in our money than our input. Because they’re the de facto standard, they think that they’re the only game in town and can screw users six ways to Sunday. We’ll see how long that mindset lasts though. An anti-ADSK/subscription sentiment seems to be growing these days.

As far any lost/old files you may have, my condolences. I’ve been there. I’ve got a lot of old work in outdated, unsupported formats. At first, I practically cried. I just had to throw my hands in the air and accept that I’d never get that stuff back again. Autodesk users aren’t alone with this problem.

#5

I’m afraid its a pretty unrealistic request as well.
How do you get a ten year old software build to load feature data from the future without just freaking out?! Well you can’t. Its like turning lead into gold.
How do you ‘fix’ such issues with out keeping countless versions of live dev branches in a compilable state? Whose job is it to manage this ‘legacy monstrocity’? Probably would take an entire new company of staff to support it.
Or it would be a half-assed effort.

And since this may very well benefit only folks who aren’t spending money on the software anymore where is the financial motivation for this very expensive undertaking?

USD is by far the most practical alternative-because really the foundation is Alembic and it is a god-send.
It has been my goto for many years now for doing FX between multiuple DCC. And I have had first hand experience moving bits and pieces from software-to-software (using fbx, dgs, obj, etc ). Sometimes many formats for a single shot! Now just Alembic for this same task has made my life ten times easier since it was introduced.

Also because you have the bake all your scene data to deformations (point data), etc it is also the most practical way to use super large and complex/heavy scenes (i.e cities and crowds) and so on because it also super optomizes everything to a much lighter memory and perfromance foot print. Therefore point data type scenes are the standard for finishing shots in most pipelines today. Only animators keep the regular ‘memory heavy’ live rigs, plugins, etc of old. But publishing their shots often convert all this data for upstream use like USD does anyway. Also makes data more bullet proof and harder to break accidently too.

The only hope to get brand new features ‘converted’ into something more generic and digestible for old software is the bake the details you want to keep- via something like USD…

#6

This is not something I’m going to loose sleep over but it is like Business 101:
It’s exponentially easier to keep existing customers then to find new ones.

Trying to railroad people towards generic, non-proprietary file formats that work just as well in competitor’s tools while offering no additional benefits in the updated original software isn’t going to encourage many people to get on or stay on subscription. It’s just a dumb strategy.

#7

I fear thats out of control for Autodesk. The ASWF members tell how the pipeline of the future does look like. If you arnt supporting USD you wont play with the big studios.

Thats why Autodesk does all kind of foundation work for open source. If you control the code of those projects you are part of the game.

https://www.aswf.io/members/

#8

It’s strange that every time there’s a discussion about the tech behind our tools a lot of people almost seem to figuratively drop to their knees and look to feature studios for guidance on, like everything.

The reality is that feature studios probably only represent 10%-15% of the global 3D DCC userbase. Yes, they are the most visible customer base and yes a lot of the ideas they have are good, especially for their specific purposes, but in some cases their solutions are far from the default standard that should be adopted by the global 3D DCC userbase because the majority of DCC users don’t have access to an small army of coders to mix up in-house solutions to help them glue everything together.

As one of my buddies might say “Get off their dick, man!”
It’s embarrassing.

#9

I fear this won’t work. While USD does support a couple of parametric elements it does not support nearly enough to represent any kind of scene that goes beyond basics. You can embed binary data into USD, but that does not solve this specific problem since, again, you would need the software specific for that binary information to interpret the USD file correctly, which is the problem you wanted to solve originally.
In general binary compatibility comes at a price that many users don’t see easily. If you remain compatible you can only do small improvements. Every bigger step you take breaks compatibility. This is often resolved just by keeping legacy code in just to interpret old stuff on load, but once your software architecture progresses the maintainance of such old code becomes a costly nightmare.

#10

Problem is those studios are the big ticket customers for Autodesk and are spending $$$ on subscription. Basically fueling the tank over all. They just don’t happen to be demanding that much legacy support.

Hey by all means. If you just up and chuck several miilion dollars at Autodesk on the condition that they suddenly add an entire division of R&D to support your legacy request. In fact you volunteer to fund the entire project. By all means you would be taken very seriously I am very sure. Money talks like nothing else can.

But I’ve worked 8 years at a DCC. I know how hard this request is to even consider. Nobody wants to go there. Only huge amounts of cash would motivate a companty to open this pandora’s box.

#11

Its been happening for years but for certain parts of the pipeline only. Basically for everything after animation it is a requirement for both optomization and bullet proofness.
Basically this is what software like Katana depend on.
https://graphics.pixar.com/usd/docs/Katana-USD-Plugins.html

I see Houdini is adding their own Katana equivilent - Solaris- in the next release. This type of pipeline is getting pretty standard.

#12

Pinch of salt: it’s been a few years since i’ve had my hands in USD code…

At its core, USD is a serialization system driven by schemas ; as a container, it can represent ‘anything’, so it kind of does ‘nothing’. This is a bit of an over-simplification, because out of the box, it does provide fairly extensive schemas for geometry (polys & subd). However, most everything else (articulation, materials, lights, effects…) is left as an ‘exercise to the reader’.

Considering that in the past 30 years, no one seems to have agreed on any of these topics, transporting this type of data across systems, apps & pipelines will require ad-hoc translation code. For instance, the closest i have seen to an agreement on material definition is Substance’s GGX-ish, simply by sheer virtue of the app being the dominant choice of the artist pool (yes, i know MaterialX, and no). Don’t get me started on lighting…

USD is a great answer to a lot of issues faced by the big guys, and occasionally the small guy who’s picking work off of their table. But it still going to take a while before it can be established as a fully viable storage solution for ‘rich content’ (other than barebone canned geometry).

Also: Mel is terribad as a data storage, and the closed binary format is too unreliable & limited to be considered viable at scale.

https://xkcd.com/927/

#13

True, but the system IS kinda rigged in Autodesk’s favor. They’re not going to lose sleep either if a few disgruntled users jump ship because they can’t open old or ancient files. Being the de facto standard comes with some perks. One of them is being able to get away with that “I don’t give a shit” attitude… for a time. (Until it doesn’t work and they can’t get away with it anymore.)

You’re 100% right. It would be good business to do right by as many users as possible. From ADSK’s perspective, that’s exactly what they’re trying to do. In their minds, that’s why they’re forcing everybody to get on the same page with subscriptions. To them, spending too much time looking back is a wasted effort. Why support 20 years’ worth of versions when every subscriber is current within 2 or 3? Forcing everybody to get in the car is a whole lot easier than dragging them from the back. I’m not saying that I agree with that logic, but I understand their desire to prioritize their use of resources and maximize their profits.

I’m with you. I’d love to be able to open old files. Better backwards compatibility would be awesome, especially if you’re trying to dig up old assets to kitbash with or repurpose. Still, life isn’t so perfect. ADSK isn’t the only perpetrator here. Other developers suck like this too.

#14

Ok, let me put this in a way that you will immediately understand: The first Avengers film was made in 2012 Marvel studios uses Maya at the core of it’s pipeline, USD was Open sourced in 2016. While everything Pixar and Lucasfilm and Disney Studio has, technology wise, was available to Marvel Studios I can guarantee you that there more then a few Maya files from that project. The only way they can churn out complete movies every year/every other year is re-using modified assets, rigs, textures etc.

Basically, I already know that what I requested exists in some form or fashion but it’s not being offered publicly because AutoDesk doesn’t want to be on the hook to have to maintain it publicly indefinitely. All I’m saying and what a lot of people know even some are unwilling to speak up about it right now is really that that’s simply not good enough.

#15

But your example is forward compatability. Not backwards.

Older assets often work fine in newer builds. Its Visa Versa thats much harder.

Why would a film done in 2019 be done by a studio in maya 2011?
And why riddle-me-this would their older film assets from previous Avengers have assets built in Maya 2017
-but the new film’s Pipeline is Maya 2011?! Makes little sense. Basically your scenerio likely doesn’t exist.

Besides studios usually decide a single build of maya per show absolutely.

Plus you’d be amazed how often assets are rebuilt from scratch when a new studio does Hulk. They don’t wanna try a figure out another studio’s ‘Huk’ asset. Faster to roll their own for their shots. Way less surpises that way… if something is wrong they know how to fix it. When 10 different studios work on an Avengers film likely each have their own redundant assets…all optomized to their own latest R&D spec for better results than the previous film.

Another point about your example not making much sense. I don’t think any studio has taken a shot -aka a scene from one film - and used it again for an all new scene in a completely different film.
If they recycle anything it might be older props and rigs. But thats it. Not entire scenes. Too messy.
Even ‘flashbacks’ would just use old finished footage. Not scenes.

So you see your issues aren’t really that probable. It only seems like demon engineering from your POV.

#16

100% conspiracy theory nonsense - @circusboy nails it.

#17

“Legacy” As I’ve always known it, relative to computer software, means “old” otherwise deprecated code, files, formats etc.

It seems like you want to argue for the sake of arguing. “Forward Compatibility” is not a term that’s used…like ever (Basically you’re just making up stuff).

Most people don’t have a problem understanding the backwards compatibility for this year’s application means for files, assets etc. from previous year’s installations, sorry I didn’t think I had to get that granular.

Certainly old assets work fine in new tools, however if you can’t open the file to export the assets without digging up an older version of the same tool (some cases like only 2 years older) you cannot export the assets without jumping through a lot of unnecessary hoops.

#18

EDITED>>> Wasted effort on my part. We all get your point. Believe what you will.

#19

EDITED>>> Wasted effort on my part. We all get your point. Believe what you will.

#20

My 8 years at Softimage say otherwise.
As for everthing else…good luck with that.