This topic describes new items and changes that affect the 3ds Max 2024 C++ SDK.

• 3ds Max 2024.1 Update Changes
• SDK Break
• SDK Requirements
• Qt version and PySide2
• Python version
• .NET version
• C++ version
• C++ standard conformance
• Removal of min and max Macros
• Color Management API
• Mesh, MNMesh, and bezierShape API Changes
  • Important New SDK headers
  • Mesh
  • MNMesh
• Better Qt UI Binding Control for Params
• OpenEXR SDK
• VolumeObject Classes
• Deprecated Items

3ds Max 2024.1 Update Changes

You can now specify Python scripts (.py and .pyw) in a Application Plug-in Package PackageContents.xml file as component entries in the "post-start-up scripts parts" section. See Autodesk Application Plug-in Package Format Specification for more information.

SDK Break

3ds Max 2024 is an SDK breaking release. Plugins compiled for 3ds Max 2023 will need to be recompiled to work in 3ds Max 2024 builds.

SDK Requirements

3ds Max 2024 is built with Microsoft Visual Studio 2019, version 16.10.4, C++ Platform Toolset v142, and Windows Platform SDK 10.0.19041.0. For compatibility reasons, we recommend that plugins for 3ds Max 2024 are built with the same version of the compiler, toolset and platform SDK as 3ds Max 2024 itself.

With 3ds Max 2024, we have updated to C++17 from C++14. We recommend that plugins do the same. See the section below on upgrading to C++17.

We have also enabled some compiler switches to enforce C++ standard conformance in our code. See the section below on C++ standard conformance.

Note that installers for other versions of Visual Studio 2019 are available.

Qt version and PySide2

3ds Max 2024 is built with Qt 5.15.1 and PySide2 5.15.1

Python version

3ds Max 2024 ships with Python 3.10.8

.NET version

3ds Max 2024 is targeting the .NET 4.8 Framework and run-time.

C++ version

3ds Max 2024 is built with the C++17 language standard.

Plugins can still be compiled with C++14, as long as the required compiler version is used. However, we do not guarantee that all SDK headers can be used with C++14. Some recent additions to some SDK headers require features from C++17.

Some standard library features were deprecated and/or removed in C++17. It is likely that new warnings and errors will pop up when upgrading. Here are some issues we faced and how we fixed them:

• error C2872: 'byte': ambiguous symbol (and other ambiguous symbols). There is an ambiguity between typedef byte in Windows headers and std::byte introduced in C++17 in header .
  • Solution: Remove using namespace std;
  • See https://en.cppreference.com/w/cpp/types/byte
• Deprecation warning for header
  • Solution: Define macro _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING before including any standard header to silence warning
  • See https://devblogs.microsoft.com/cppblog/c17-feature-removals-and-deprecations/
• Error because of removed old function binders, like std::binary_function and std::unary_function
  • Solution: Remove these classes completely. Use lambdas instead if needed.
  • See https://en.cppreference.com/w/cpp/utility/functional#Old_binders_and_adaptors
• Error because of removed std::auto_ptr.
  • Solution Use std::unique_ptr instead.
  • See https://en.cppreference.com/w/cpp/memory/auto_ptr
• Error because of removed std::random_shuffle
  • Solution: Use std::shuffle with a custom URNG. See implementation of std::random_shuffle in Microsoft headers for inspiration.
  • See https://en.cppreference.com/w/cpp/algorithm/random_shuffle
• Warning because of non-standard throw specification
  • Solution: Remove throw(type) and throw(…). Replace throw() with noexcept
  • See
    • https://en.cppreference.com/w/cpp/language/except_spec
    • https://en.cppreference.com/w/cpp/language/noexcept_spec
    • https://docs.microsoft.com/en-us/cpp/cpp/exception-specifications-throw-cpp?view=msvc-160
• Errors because of auto and register keywords
  • Solution: Remove auto and register keywords
  • See https://en.cppreference.com/w/cpp/language/storage_duration

For a more complete list of changes in C++17, see https://en.cppreference.com/w/cpp/17

C++ standard conformance

There are many C++ code constructs historically accepted by MSVC that are not officially valid C++ code according to the C++ standard. This code works fine when compiling with Visual Studio, but it is sometimes an obstacle to using other modern development tools that expect standard conformant code only. MSVC provides a compiler switch to prevent compilation of all this non-conformant code: /permissive-. See: https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170

The goal is to eventually enable /permissive- in 3ds Max to ensure our code is fully conformant. There is no official timeframe for this goal at this point. Consider enabling this switch already when compiling your plugins to get a head start. For an application as large as 3ds Max, this represents a massive effort. Luckily, MSVC provides many other compiler switches to gradually enable standard conformance instead of enabling everything at once.

Here are the compiler switches that were enabled in 3ds Max 2024:

• /Zc:strictStrings
  • Prevent assigning string literal to non-const pointer.
  • Example: TCHAR* str = _T("hello"); will no longer compile because str is not const.
  • Mitigations: Add const wherever possible. Otherwise, use const_cast
  • See: https://learn.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170
• /Zc:externC
  • Prevent using extern "C" on functions that aren't compatible with C language
  • See: https://learn.microsoft.com/en-us/cpp/build/reference/zc-externc?view=msvc-170
• /Zc:inline
  • Ensure that all functions marked as inline are defined in the current cpp file.
  • See: https://learn.microsoft.com/en-us/cpp/build/reference/zc-inline-remove-unreferenced-comdat?view=msvc-170
• /Zc:lambda
  • Add some restrictions to lambda definitions
  • See: https://learn.microsoft.com/en-us/cpp/build/reference/zc-lambda?view=msvc-170
• /Zc:rvalueCast
  • Ensure the result of c-style casts is considered as a temporary (rvalue).
  • Example: int i; std::cin >> (int)i; won't compile, because std::cin can't write to a temporary.
  • Mitigation: Remove c-style casts
  • https://learn.microsoft.com/en-us/cpp/build/reference/zc-rvaluecast-enforce-type-conversion-rules?view=msvc-170
• Treat warning C4596 as error
  • Prevent using class name inside class definition
  • Example: class Thing { void Thing::my_func(); }; won't compile.
  • Solution: Remove Thing:: from inside class definition
  • See: https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/c4596?view=msvc-170 Note: You can disable these switches by adding "-" in your property sheets. For example: /Zc:strictStrings-. This is not recommended.

Here are the switches that are being considered for a future version of 3ds Max (not yet confirmed):

• /Zc:hiddenFriend: https://learn.microsoft.com/en-us/cpp/build/reference/zc-hiddenfriend?view=msvc-170
• /Zc:referenceBinding: https://learn.microsoft.com/en-us/cpp/build/reference/zc-referencebinding-enforce-reference-binding-rules?view=msvc-170
• /Zc:ternary: https://learn.microsoft.com/en-us/cpp/build/reference/zc-ternary?view=msvc-170
• /Zc:static_assert: https://learn.microsoft.com/en-us/cpp/build/reference/zc-static-assert?view=msvc-170

Removal of min and max Macros

In this release, the Windows min and max macros are disabled to improve compile speeds and reduce errors. A preprocessor definition NOMINMAX has been defined across the SDK. To avoid getting build errors related to min and max macros, consider defining NOMINMAX in your codebase. Alternatively, you can #undef min and #undef max.

To replace usage of min and max macros, consider using std::min and std::max Alternatively, consider using <maxsdk/include/Util/minmax.h> if T1 and T2 are different.

To fix errors in header <gdiplus.h>, include <maxsdk/include/Util/safegdiplus.h> instead.

Color Management API

Up until version 2024, 3ds Max has provided only basic color management capability through the process known as de-gamma/re-gamma linear workflow where sRGB color primaries were assumed throughout the system, including the input textures, output images and display devices. In 3ds Max 2024 we are introducing a modern color management capability and concepts using the industry standard OpenColorIO (OCIO) library. Although there have been some major changes in the 3ds Max codebase to make it possible to integrate OCIO library and to add modern color management concepts, we have tried our best to keep the impact minimal for the end users and the 3rd party developers. The existing gamma-based color management mode is still available to users and should behave as before. Similarly, the API that exposes the fundamental gamma-based color management workflows were mostly retained, but we have deprecated or removed some entry points and functionality which were clashing with the modern color management concepts. The majority of plugins will require no or trivial changes to work as before in the gamma mode.

Although GammaMgr and IColorCorrectionMgr classes are retained for backward compatibility as described above, those classes are streamlined and will only work in the gamma mode. We're planning to phase out these gamma-only classes in time, therefore, we suggest 3rd party developers start using the new color management API that supersedes GammaMgr and IColorCorrectionMgr by supporting all color management modes, including the unmanaged and gamma modes.

Although there are changes in various places, the central pieces of the new API are defined under the MaxSDK::ColorManagement namespace and are located in the maxsdk/include/ColorManagement subfolder. The main management class is IColorPipelineMgr. Please check the developer guide and header files for detailed information.

The new ColorConverter is included as a sample project in the SDK under maxsdk\samples\ColorManagement\ColorConverter, and illustrates the use of the new ColorManagement API.

Mesh, MNMesh, and bezierShape API Changes

The Mesh and MNMesh classes have been refactored to have internal data organized into channel objects. This provides improved stack performance, stability and a lot of code cleanup and modernization. The goal was no functional change to these meshes and minimal API changes to avoid ifdefs.

Mesh -> MeshTopoChannelData, MeshGeomChannelData, MeshVertexColorChannelData, MeshTextureMapChannelData, MeshEdgeVisibilityChannelData, MeshMaterialChannelData

MNMesh -> MNTopoChannelData, MNGeomChannelData, MNVertexColorChannelData, MNTextureMapChannelData

Important New SDK headers

• MeshChannelContainer.h andMNChannelContainer.h, container for the channel objects for Mesh and MNMesh
• MeshChannelData.h and MNChannelData.h, declarations of the new channel objects for Mesh and MNMesh

The public mesh members of Mesh and MNMesh that are not owned by channel objects have been either replaced by getter/setter or wrapped with "BlockWrite" objects. The purpose of these is to block the ability to write to these members directly because it isn't Mesh that owns the data, they are simply mirrors. This should not be too disruptive.

For example, you can access mesh->faces[f] and alter the faces but you cannot write to the faces member itself. If you want to do this, you still can but it's not adviced. See documentation for Mesh::GetChannelDataContainer() and MNMesh::GetChannelDataContainer() in the API Reference.

Mesh

Change highlights:

• Deprecated public members that have been replaced with getter/setters: vdSupport, vData, vertSel, faceSel, edgeSel, vertHide, mtlIndex, numMaps, maps
• With the exception of the per vertex data members, you should be able to update your code to use existing public methods to access the data you are after.
• Meshes SELECT_CHANNEL has been removed. The data that was in it has been moved into topo and geom channels respectively. This fixed issues related to face / vert counts changing and getting out of sync with selection BitBrrays.
• Modified the handling of the MeshMap flags. Previously there were some cases with the stack operations where the flags were not properly cleared. Ex:mesh.FreeChannels(TEXMAP_CHANNEL) would not clear the map flags.

MNMesh

Change highlights:

• Deprecated public members that have been replaced with getter/setter: m, numm, ed, edSupport, vd, vdSupport
• The concept of allocated maps versus used maps has been removed, there is just used maps now. MAlloc and MShrink have been deprecated.
• MNMesh no longer inherits from FlagUser. This is because some of the flags in there are now owned by the topo channel. Appropriate methods have been added to MNMesh so no code change should be required.

Better Qt UI Binding Control for Params

New methods have been introduced to provide manual Qt UI binding with params, which is useful for dealing with dynamic data, such as tab-type params with P_VARIABLE_SIZE. The new methods are:

• QMaxParamBlockWidget::PreConnectUI([[maybe_unused]] const MapID paramMapID)
• QMaxParamBlockWidget::PostConnectUI([[maybe_unused]] const MapID paramMapID)
• IParamMap2::ConnectUI(MaxSDK::QMaxParamBlockWidget* widget)
• IParamMap2::ConnectUI(ParamID id, QObject* uiControl, int tabIndex = 0)
• IParamMap2::DisconnectUI()
• IParamMap2::DisconnectUI(QObject* uiControl)

The PostConnectUI() is a callback that can be registered for a ParamMap, and can be used to call the IParamMap2::ConnectUI(ParamID id, QObject* uiControl, int tabIndex = 0) method to manually create a binding.

The maxsdk/howto/UI/qtObjectDemo sample project is updated with a new QtVariableFloatTabRollupWidget to demonstrate how to use this approach to dynamically re-connect to a param with a variable size.

OpenEXR SDK

The activeshadefragment (maxsdk\samples\render\activeshadefragment) sample plugin requires OpenEXR to compile. OpenEXR 2.5.3 is required. This can be downloaded at: https://github.com/AcademySoftwareFoundation/openexr

VolumeObject Classes

Two new classes have been added to support volume rendering, and provide access to OpenVDB grids. Note that these classes are a work in progress, and are not intended for production use. They are:

• ArnoldMaxVolumeInterfaceObject (in include/ArnoldMaxVolumeInterface.h)
• MaxVolumeInterfaceObject (in include/MaxVolumeInterface.h)

Deprecated Items

These items have been deprecated in the 3ds Max 2024 SDK. See the 3ds Max SDK C++ API Reference for a complete list that includes items deprecated in previous releases.

Member BitmapIO::__declspec (deprecated) virtual void EvalMatch(MCHAR *matchString) final This has been deprecated as of 3ds Max 2024, please use MSTR& overload instead

Member BitmapStorage::__declspec (deprecated) static MCHAR *evalString This has been deprecated as of 3ds Max 2024, please use m_evalString instead

Member bmmHistoryList::__declspec (deprecated) static MCHAR title[MAX_PATH] This has been deprecated as of 3ds Max 2024, please use m_title instead

Member bmmHistoryList::__declspec (deprecated) static MCHAR initDir[MAX_PATH] This has been deprecated as of 3ds Max 2024, please use m_initDir instead

Member FILE_SUPPORT_MERGE Deprecated as of 3ds Max 2024. Unsupported for many versions.

Class IColorCorrectionMgr This class is deprecated. Please use IColorPipelineMgr which provides better color management functionality.

Member MaxSDK::Util::__declspec (deprecated) StaticAssert This has been deprecated in 3ds Max 2024, please use builtin static_assert(b, "msg") instead

Member ReferenceTarget::__declspec (deprecated) virtual void RefDeleted() final Deprecated method in terms of implementation as of 3ds Max 2024 - re-implement with ReferenceMaker* method signature

Member ReferenceTarget::__declspec (deprecated) virtual void RefDeletedUndoRedo() final Deprecated method in terms of implementation as of 3ds Max 2024 - re-implement with ReferenceMaker* method signature