I wrote in a previous post about the principles making the 3ds Max SDK a catalyst for product resilience and user entrapment fidelity. I went quickly over the stability of Max, which I compared to a Babel tower. In this post, I will explain stability issues around interoperability.
The 3ds Max SDK is an inherent part of 3ds Max’s core. Most components shipping today in max are plugins in their own rights. We could say the the max development team is eating its own dog food and that would insinuate that the SDK is rock solid and well tested. True… Mostly.
Max’s robustness depends on :
- Max itself
- Each third party plugins at the individual level
- How the holistic system of plugins (#1 and 12) work together on a specific max version
- Backward compatibility (Loading previous version of 3ds Max file in the current version)
- Forward compatibility (Saving as a previous version file)
The 3ds Max tower is composed of a base provided by Autodesk on top of which third party provide their plugins. In my metaphor, a tower is the product for a specific year. Going from one year to another involve “jumping” across the gap : forward or backward interop. The triangle-eye represent the holistic view over the whole set of towers.
Max’s QA
Autodesk, in its yearly development cycle, covers for #1, #4 and #5 . (#4 and #5 is tested only for the 3ds Max components, of course). I don`t see how Autodesk can provide any testing for external plugins on #4 or #5.
Third party QA
Third party plugins developers are responsible of testing their own (#2) with each release of 3ds Max. They typically receive the 3ds Max SDK through the 3ds Max beta program. Want to know more? Contact ADN(Autodesk developer network). The SDK is provided a bit late, after the APIs are stabilized for release. Because all are not born equal, the quality of each third-party developer’s testing varies greatly. It is therefore difficult to attest that #2 is thoroughly tested for a specific max version.
As for #4 and #5, I know of very few plugin developers that test these. The usual strategy for them is to monitor their key client accounts and fix any issues showing up.
Hollistic stability
The holistic stability of the system (#3) isn’t managed. Don`t blame Autodesk for it probably is mission impossible. It certainly doesn’t fit in a yearly development schedule. This systemic stability is therefore random and coincidental to all the other stability efforts made overall. Trusting this is akin to blind faith. Amen.
To summarize :
- 3ds Max is released on a year over year schedule.
- Stability across versions, although pursued and desired, is not guaranteed.
- In line with this post and per virtue of the “If it ain’t broken don’t fix it” principle, If you have a working production pipeline (ex: a team in the process of doing a movie, a game, etc.)
“YOU SHOULD NEVER UPDATE MID-PRODUCTION.”
P.S. : My advice on updating is good for just any component in your pipeline.
P.P.S.: Don`t shoot the messenger but items #1 and #3 seem to indicate there is an issue with the business model of most major DCCs.
In upcoming posts, I’ll get technical about these interop problems.
QUADERNII
Thank you very much for taking the time to explain this to us. At least now we have an idea where the somewhat random stability issue stems from.
Adding plugins add some level of risk and need to be tested a bit.
Migrating files across version is risky. Even more if plugins are involved.
Breaking a work pipeline is extremely costly (all the work is halted) – and precaution is advised.
We’ve surveyed 3ds Max versions for components presence and should be able to present this information shortly.
It tells which component exist in which version (year, 32/64 bits, entertainment/design).
easy examples, on top of my head :
reactor goes off at a certain version.
Some plugin were terminated due to being replaced or unused.
There were legacy plugin that couldn’t survive the transition to 64 bits. the VRML exporter does not exist for 64 bits.
These are gaps a technical director / user need to deal with.