Supported Build Systems

The Cinema 4D C++ SDK support Windows, macOS, and Linux as build platforms. The supported build systems for are:

The supported build system generator for Cinema 4D C++ SDKs are CMake and the project tool (deprecated). The recommended Visual Studio edition is Professional or Enterprise, but Visual Studio Community will usually also work - but problems arsing from using the Community edition are unfortunately out of scope of support. As a Linux desktop environment we recommend Ubuntu Linux and as an enterprise/server environment we recommend Rocky Linux.Due to the dual build system generator support, there are two sets of requirements for Cinema 4D 2025.2, the new CMake requirements and the legacy Project Tool requirements.

Cinema 4D 2025.2 CMake Build System Requirements

MAXON_API_ABI_VERSION is 2025000
Targets the C++20 standard
Uses CMake 3.30+ as the build system generator

OS	Build System	Compiler	Comment
Windows	Visual Studio 2022	MSVC or Clang	CMake 3.30, Python 3, MSVC v143, Windows 10 SDK 10.0.18362.0
macOS	Xcode 16	Clang	CMake 3.30, Python 3
Linux	Ninja 1.11+	GCC 11.2.1+	Requires glibc 2.28 and Python 3.

Cinema 4D 2025.2 Legacy Build System Requirements

MAXON_API_ABI_VERSION is 2025000.
Targets the C++17 standard
Uses the legacy Project Tool as a build system generator.
Requires using the Legacy Build System in XCode (see older documentation versions for details).

OS	Build System	Compiler	Comment
Windows	Visual Studio 2019	MSVC	MSVC v142
macOS	Xcode 13	Clang
Linux	SCons 3.1.2+	GCC GCC 9.3.1+	Requires glibc 2.17 and Python 3.

Registering Identifiers

Identifiers to register modules, plugin hooks, and other data are a common occurrence in the Cinema and Maxon API. You will encounter them in various forms when realizing Cinema 4D plugin projects and it is crucial to provide unique identifiers when the API requires you to do so, as your plugins will otherwise malfunction or not even load. Generally, there are two types of identifiers to be found in Cinema 4D plugin projects, integer identifiers and string identifiers.

Integer Identifiers

An integer identifier is just an Int32 integer which is usually also exposed as a symbol when issued by Maxon Computer. E.g., the symbol Ocube is the symbol for the value 5159 which itself is the plugin - and with that type - identifier of the parametric cube object in Cinema 4D. I.e., when you would call op->GetType() on a BaseObject that represents a parametric cube, it would return the value 5159, its plugin identifier.

But this does not apply only to tangible things like objects, tags, materials, and shaders, but all Cinema API plugin hooks require this form of identification. The example shown below for example registers a command, and the plugin identifier will here then become the command ID of that command which then could be invoked with CallCommand.

static const Int32 myPluginID = 123456789; // A unique plugin ID obtained on developers.maxon.net.
 
// A plugin hook registration call which uses as its first argument a plugin ID. This will become
// the identifier for this hook and it must be unique, as the plugin will otherwise not register
// when an ID collision occurs. Here we are registering a command, which is more or less a button
// which can be placed in menus and palettes and which will invoke a function when pressed.
const Bool res = RegisterCommandPlugin(
  myPluginID, "My Command"_s, PLUGINFLAG_SMALLNODE, nullptr, "Does command stuff."_s, NewObjClear(MyCommand))

Warning: Integer plugin identifiers must be issued via developers.maxon.net. Never 'invent' plugin identifiers. Ignoring this rule can cause your plugins - or much worse other plugins - to not to load or otherwise malfunction. We reserve the right to blacklist developers and plugins ignoring this rule.

A more rare case for using integer identifiers is for writing values under alien parameter identifiers into BaseContainer instances; or by extension when writing am alien parameter on a BaseList2D. E.g., you write under the identifier ID_FOO = 123456789 into an Ocube instance although a parametric cube usually does not store any data there. Doing this is generally not advisable but sometimes not avoidable when scene data must be decorated with other data. When you do must do this, you must always register a plugin ID to be used as that alien parameter identifier.

Warning: Make sure that the node/container you write into does not dynamically issue parameter identifiers in a range which could collide with your plugin identifier.

static const Int32 myAlienParamID = 987654321; // A unique plugin ID obtained on developers.maxon.net.
 
// We write into the container bc, whose management/implementation we do not own. #bc could for 
// example be the data container of any BaseObject. While doing this should generally be avoided at
// all costs, when done, we MUST use unique plugin ID to write such alien data.
BaseContainer bc;
bc.SetString(myAlienParamID, "Hello World"_s);

String Identifiers

String identifiers are used by the Maxon API and upon module registration. String identifiers must follow the reverse domain name notation derived from a web-domain you own. So, when the web-presence of your company is my.company.com, you would prefix all your string identifiers with com.company.{...} (the subdomain www is conventionally exclude in string identifiers but you could also include it).

Note: Other than for integer identifiers, string identifiers are currently not required to be registered.

Warning: Do not use string identifiers that start with net.maxon., as this can lead to non-loading modules and other problems. Use only lower case letters, numbers, the underscore character, and the dot character for string identifiers. With Style Check Settings you can enforce identifier prefixes in a module.

Note: Do not use string identifier prefixes for which you do not own the domain. When you do not own any web domains, register an integer identifier on developers.maxon.net and use the pattern user.{name}{pid}...". E.g., user.alice123456789.module.foo, where user.alice123456789 would be then the permanent prefix used for all your string identifiers.

You will encounter string identifiers when registering modules in projectdefinition.txt, e.g.:

//...
 
// The resulting plugin binary will attempt to register this module with the here given module ID
// with Cinema 4D on startup. This ID must be unique and follow the inverted company domain pattern.
// DO NOT use module IDs that lie in the 'net.maxon...' domain, as your plugin will not load otherwise.
ModuleId=com.company.modules.foo

And when declaring components, data types, attributes and other entities in the Maxon API; which are then later registered. Here for example, both an attribute and a component are being declared:

// Declare a published object for dots asset type class.
namespace maxon::PresetAssetImplementations
{
  MAXON_DECLARATION(
    Class<BasePresetAsset>, DotsPresetAssetClass, "net.maxonexample.class.dotpreset");
};
 
// Declare a custom metadata attribute to describe the dot scale of dot asset thumbnails. Defining
// custom metadata attributes is optional. The source-processor will generate the files 
// dots_preset_asset1.hxx and dots_preset_asset2.hxx which must be included for this attribute to 
// be correctly exposed.
#include "dots_preset_asset1.hxx"
namespace maxon::ASSETMETADATA::DOTSPRESET
{
  MAXON_ATTRIBUTE(maxon::Float32, DOT_SCALE, "net.maxonexample.asset.dotpreset.dotscele");
};
#include "dots_preset_asset2.hxx"

ABI Compatibility

Each SDK has an Application Binary Interface (ABI) which determines with which versions of Cinema 4D plugins are compatible with, depending on the SDK version they have been compiled against.

Warning: An SDK being ABI incompatible to a certain version of Cinema 4D cannot be circumvented by only using parts of an API which have not changed. A plugin compiled against an incompatible SDK will not be loaded by an unsupported version of Cinema 4D. Do not change any files in the frameworks directory of an SDK, as plugins compiled against such SDK might otherwise become incompatible with Cinema 4D.

The Cinema 4D ABI will remain upwards compatible for one major version. This means for example that a plugin compiled with the Cinema 4D SDK for release 2023.1 will also work in the releases 2023.2 and 2023.3, etc. but not in 2024.0. The ABI version of an SDK is expressed by the define MAXON_API_ABI_VERSION. The ABI version of major releases is also expressed in the Supported Build Systems table.

Note: In the old version scheme of Cinema 4D an R/S version pair counted as one major version. The Cinema 4D R25.000 SDK is for example ABI compatible up to Cinema 4D S26.110.

Fig. I: Demonstrates the concept of ABI compatibility with the three fictional plugins Plugin A, Plugin B, and Plugin C and how they are compatible with different Cinema 4D releases. Boxes in dark grey are the Cinema 4D SDK releases for which a plugin has been compiled. The arrows outgoing from a plugin release indicate up to which release of Cinema 4D such plugin binary is compatible.

As an example and as shown in Fig. I, the developers of Plugin A always compile their plugin for the first version of a major Cinema 4D release. With plugin binaries compiled with for the 2023.0.0, 2024.0.0, and 2025.0.0 Cinema 4D SDKs, they can cover all Cinema 4D releases of 2023, 2024, and 2025.

The authors of Plugin B also compile for the first version of a major Cinema 4D release. But they also want to support a new feature of Cinema 4D 2024.2.0. To do that, they ship two plugin binaries for Cinema 4D 2024. One version which has been compiled for the Cinema 4D 2024.0.0 SDK. This plugin can be used with every version of Cinema 4D 2024. And another version which has been compiled for the Cinema 4D 2024.2.0 SDK. This plugin can be used with all Cinema 4D versions between 2024.2.0 and the last release of Cinema 4D 2024. Only the latter version of their 2024 plugin can support the new features of Cinema 4D 2024.2.0. But customers of Plugin B who do not want to update their installation to the 2024.2.0 SDK version of the plugin could still use it up to the end of the 2024 release cycle.

The authors of Plugin C have only compiled their plugin for Cinema 4D 2024.0.2 and 2025.0.0. The plugin binary for the 2025.0.0 SDK will be fully compatible with all 2025 releases. But the plugin binary compiled for the Cinema 4D 2024.0.2 SDK will not work in Cinema 4D 2024.0.0 or 2024.0.1. Cinema 4D 2023 is not supported at all by Plugin C as its authors have never compiled their plugin for any 2023 SDK.

Note: Plugins must be compiled separately for macOS, Windows, and Linux. The example lined out above ignores this for simplicity in its wording. Plugin A would require for example two binaries for each the major Cinema 4D releases it supports, if the authors wanted to support macOS and Windows.

Table of Contents

Supported Build Systems

Registering Identifiers

ABI Compatibility

Further Reading