True, ASCII is indeed not “rocket science”, but it does leave ALL the actual “compatibility work” externally.
Also, it may expose data pople may want to keep private. You would need to get buy-in from *all* plugin developers for this, and that will be hard.

Although, of course, one workaroudn for the buy-in problem would be to export a new method to all plugins, ::AllowAsciiOutput, which, if off, means the plugin data is dumped as raw hex code, making it no easier (or harder) to decode than the current binary format, but any plugin that had ::AllowAsciiOutput to TRUE would output the param block “decoded”.

Or something.

So yeah. SaveAsASCII would be neat, and indeed easy technically, but hard, perhaps, “politically”.

/Z

again i vote for an pure ASCII format I/O option in future Max versions (like Maya has ) - this way many many things are possible for external converters, editing by hand troubling max files and so on - and this should NOT be rocket sience - it would be the same data as in the .max files . but in human readable and editable format....
this would enable a vast amount of people to come up with ideas and problemsolving strategies - a thing that’s currently blocked totally, because of max’s undocumented and blackbox like format.
even FBX has an ascii option - but hast the problem of being planed for inter-application data exchange . and it breaks sooooo manny things during the conversion process.....

Let me glue in a post from CgTalk to anyone thinking this is “easy” and that they “should have done this ages ago”.

Someone asked “Is it really rocket science for max 8 user to load up the ‘Shell’ modifier from max 2009 and change the amount”?

I replied:

As a matter of fact it is. Or maybe not for shell, assuming the shell modifier hasn’t changed at all since max 8.

You see, everythign in max is a plugin. And when a file is saved, it is up to the plugin itself to do so. So “3dsmax.exe” has no idea how to save a “Shell modifier”. It asks the shell modifier “Hey, here’s a file handle, write yourself to it and tell me when you are done”.

All that 3dsMax.exe knows, is that when it hits a certain tag (whats known as a “ClassID") when loading a file, it finds a plugin with this ClassID - say, the shell modifier - and then it creates this modifier, tells hit “Okay, here’s the file handle, now load yourself from it”.

To 3dsmax.exe, the built-in “Shell” modifier is just as alien and unknown to it as, say, the FumeFX atmospheric object, or the Thinking Particles superspecial particly thingamabob.

Now, when you add new things to a plugin, most people do this by adding new parameters in whats called a “parameter block” structure.

The trick is, that if an old plugin tries to load in new data, it’ll get ParamID’s it doesn’t know about. This will confuse it. And this is the easy thing, with ParamBlock2’s this would work sort-of ok.

But some plugin implement specific ::Save and ::Load methods, in which they tend to just suck in a bunch of bytes (i..e “now read 129 bytes from the file and stomp into this memory address"). The new version may read in 147 bytes instead.

But if you feed 147 bytes to the old version, at worst the file read comes out of sync after that (because the plugin read only 129 bytes, leaving the file pointer in the wrong place) or at even worser, it does read the 147 bytes into a 129 byte buffer, causing a nasty buffer overrun and a spectacular crash.

So, true “save as old version” really would have to be coded in to Every. Little. Plugin. And everything in max is a plugin. Every object. Every modifier. Every controller. Every render element. Every renderer. All of it. I’d wager base max ships with a cool thousand+ plugins.

So yeah. It’s a bit like rocket science.

/Z

...but is it worth the effort? Any thoughts?

Simple Answer ... a triple yes!

One of my customers is a big company here in europe they are using Max 8 right now and they won’t update for a long time.
On some workstations they are still using WIndows 2000. And i am making a lot of models for them.  Because of the missing
downward compatibility i am also stuck with Max 8.

Another example… i model something with Max2008 and could retexture it with a plugin that i have for an older Max Version.

Would that help?.... Yes a lot.

Ken, the real scary part is, that it took your company 11 Versions and 12000 miles to Korea to start considering this option.
Almost every professionell Max- User could and would have told you that, 5 or 6 years ago and just across the street!

Most of the time when I am exchanging data it is same version or another app all together. As I posted over at cgtalk there is alot of stuff that will have to be taken into consdieration. For example, you can’t export back multi-segment chamfer data in poly objects. To do so you must collapse the stack, even from Max 9 Extension to Max 9. On top of that 2009 is introducing new features that currently would have no backwards compatible features, as far as I know (New ColorCorrect Map, New Composite Map, mr Object properties, biped enhancements and changes, etc). Anytime I have had to go back to a previous version BFF worked, minus a couple of issues.

Unfotunately the way I see it is, they will be supporting users who aren’t supporting the current development of Max. User who don’t upgrade or are not on subscription don’t have money going into the current dev cycle. I am a current subscriber and would rather see my money invested elsewhere. I do understand that some users are current, but due to their current production can not upgrade. I don’t know what may or may not happen, but I really don’t want a large effort spent on this if it will cost me something else.

-Eric

From what Ken has posted, it seems like it’s not that much work for Autodesk that we should give up some major features. And this one would in a way change the workflows of lot of people by great amount.
Other then this, my greatest wish for a long time is to replace the old biped (no matter how you try to enhance him in every new max version) with something new and modern (again, not buying CAT seems like a big mistake , but there is still Puppetshop to buy :-D).

so Eric:
you always work allone and never have to exchange data with other people as it seems ?

The question I would want to see from people really wanting this is what are you willing to give up for it? Since I am sure this will pull efforts from other features, enhancements, etc. Personally I would rather see the effort placed else where. If I need to go back a version I can use Bobo’s BFF or FBX, DAE, etc. I would probably never use this feature in my day-to-day operations.

-Eric

I can’t believe that you are asking this as well. This has been asked for by the advisory boards for years. of course we would like to be able to do it.

If you can do this then I assume that you can also write all the data to an ascii format instead of a binary one. This would be the best and most useful solution all round. So far there have been many attempts to create tools that do this. Bobo did the best version with BFF and that is used by people all the time.

Please add this and you will save us all a lot of headaches.

With all the respect, first i thought that this is probably a joke of some kind. It’s almost as if there are two most common questions about max in the forums. First one is which app is better - max or xxxxx. Second question is how to open max file from new version in older versions. I’m very surprised that it seems like this is the first time in history of max that Autodesk is asking such a question. People are doing crazy things to get their data from new versions to older -from writting scripts (hello bobo ) to not upgrading to new version of max.

So in short, yes it would be EXTREMELY usful to be able to move data between different max versions.