Major New Features

Viewport Graphics API

3ds Max 2012 has introduced a new viewport graphics API that allows procedural object, modifier, material, and texture map plug-ins to take advantage of the new Nitrous viewport display driver. The details for this new graphics API including object display API, simple and advanced material, and texture map display API and their impact on plug-ins are covered in detail in Porting Object Plug-ins to Nitrous, Porting Simple Material and Texture Map Plug-ins to Nitrous, and Porting Advanced Material and Texture Map Plug-ins to Nitrous. See the Handling Requests for Interfaces topic to learn how to override the InterfaceServer::GetInterface() correctly. Incorrect overrides of this function can prevent a plug-in from displaying correctly in the Nitrous viewport.

Plug-in DLL Defer Loading Enhancements

3ds Max by default tries to defer load the plug-in DLLs unless the developer has explicitly opted-out by returning FALSE from his implementation of the CanAutoDefer() function. This is in oppose to the default behaviour of the previous versions, in which the plug-in DLLs were not defer loaded unless the developed opted-in by returning TRUE from CanAutoDefer() function.

Prior to 3ds Max 2012, many plug-in DLLs could not be declared as deferrable because they were using features that were not supported by the defer-loading mechanism, such as:

Action tables - see class ActionTable
Function publishing of core interfaces. A core interface object is a static variable of type FPStaticInterface marked with the FP_CORE flag
Startup notifications such as NOTIFY_SYSTEM_STARTUP

Declaring a plug-in DLL as deferrable that supported the last two items did not prevent 3ds Max from defer loading it. This ultimately resulted in run-time defects. Besides, defer loading was usually not implemented in the plug-ins because it was optional. In 3ds Max 2012, many of the restrictions preventing plug-in DLLs from being defer loaded (including the above-mentioned cases) are eliminated. Also, to significantly improve start-up times and over-all memory consumption, defer-loading of plug-in DLLs is now the default behavior of 3ds Max, even if the CanAutoDefer() function is not implemented.

Impact on Plug-ins

Potentiality of the plug-ins to be deferred need to be re-assessed in 3ds Max 2012 as following:

Plug-in DLLs that already declare themselves as deferrable (CanAutoDefer() returns 1 or TRUE) are now more likely to be deferred by 3ds Max even if they weren't in the past.
Plug-in DLLs that do not implement CanAutoDefer() might now be deferred. If deferring them creates a negative impact on the user experience, they should explicitly disallow deferring. For this, the function ULONG CanAutoDefer() should be implemented and should return 0. Moreover, this function needs to be exported from the DLL.
Plug-in DLLs that explicitly disallow being deferred should be reviewed, to see whether the reasons for disallowing defer loading still apply.

There are also certain flags defined in the file 3dsmax.ini that control each of the new features of 3ds Max for plug-in DLL defer loading. For more information and details on this topic, refer to Deferred Loading of Plug-ins

Better Support For Save-to-previous

Changes to the reference structure of a plug-in used to be very restricted if the plug-in tried to save itself to a previous version of 3ds Max. One scenario where such a reference structure change is inevitable is when a plug-in migrates from using parameter block 1 (IParamBlock) to using parameter block 2 (IParamBlock2). In this case, the reference to the plug-ins parameter block would change.

Saving An Alternate Reference Hierarchy

A new class called ReferenceSaveManager has been introduced to help plug-ins define a different reference structure than the one they have at run-time. For example, the number and type of references the plug-in saves can be different than those it has at run-time. This new API helps to eliminate the restrictions that applied to reference structure changes of a plug-in, so that it can be saved to a previous version of 3ds Max. For information on this new API, refer to the topic Changing the Reference Structure. You can also see the documentation of ReferenceMaker::SpecifySaveReferences() member function and that of class ReferenceSaveManager for more information and sample code.

Support for .NET 4.0 Run-Time and Microsoft Visual Studio 2010

3ds Max 2012 targets version 4.0 of the .NET Framework. The SDK sample and howto project files have been upgraded to Visual Studio 2010, while still targeting the Visual C++ 9.0 SP1 compiler that is part of Visual Studio 2008.

Plug-ins can be developed using either VS 2008 or VS 2010. When plug-in projects are upgraded from VS 2008 to VS 2010, the following requirements apply:

Non-managed and mixed plug-ins must target the v90 toolset (see the FAQ in the Upgrading the target .NET framework version to .Net 4.0 for instructions on how to set this up). The Visual C++ 9.0 SP1 compiler needs to be installed in order to build non-managed (C++) and mixed (C++\CLI) plug-ins.
Mixed (C++\CLI) plug-in projects cannot target .NET 4.0 since they need to be built using the v90 toolset which does not support.NET 4.0. See the FAQ in Upgrading the target .NET framework version to .Net 4.0 for instructions on how to change the target .NET framework version. Managed plug-ins are free to target .NET 4.0.

This feature is discussed in more details in Writing .NET plug-ins.

Morpher API

A new set of classes and member functions have been exposed to make it easier to access data stored by the 3ds Max Morpher modifier. This new Morpher API replaces the legacy, now deprecated IMorphClass class. The Morpher API has been modeled after the MAXScript exposure of the morpher modifier.

The Morpher API is not part of the official 3ds Max SDK (maxsdk\include), but instead ships as part of the morpher modifier sample project:

Morpher API include files: maxsdk\samples\modifier\morpher\include
Morpher API libraries: maxsdk\samples\modifier\morpher\lib

Because it is a sample, the Morpher API is subject to change in subsequent releases of 3ds Max, even in those where the 3ds Max SDK stays binary backwards compatible.

The Morpher API consists of two main classes, class MaxMorphModifier, which is a wrapper around a 3ds Max morph modifier instance, and class MaxMorphChannel, which is a wrapper around a morph channel of the 3ds Max morph modifier. For more details see the comments in maxsdk\samples\modifiers\morpher\include\MorpherApi.h

The following code example uses the new Morpher API to get the name of morph channel 0:

Modifier* morphModifier; // must point to a MorphR3 instance
MaxMorphModifier maxMorphModifier(morphModifier);
const MCHAR* morphChannelName = maxMorphModifier.GetMorphChannel(0).GetName();