Cinema 4d Stuck On Initializing Plugins

[Dhara Lyford]

Ive tested the Ornatrix C4D demo and directly decided to buy a one month license for further testing. But now after installing the licensed version my C4D hangs on "Initializing plugins" whenever I start the application. And when I remove the Ornatrix plugin C4D works fine.

We had the exact same issue on macs, but it not supposed to happen on Windows. Just to be sure, can you delete your Cinema 4D R23\resource\modules\usd.module directory and check if it loads?

I removed the usd.module out of the folder but it didn't change anything. I also installed Ornatrix for my R21 license to see if there is a difference but unfortunately it stops also when initializing the plugins.

Log starts on 2021-01-05 15:25:52, Ornatrix 2.1.1.26493 Release Demo, built with Visual C++ 1916, loaded from C:\Program Files\Maxon Cinema 4D R23\plugins\Ornatrix

[Error ] [t 1287792] [tid 16720 ] [M 4400452] [HairFromGuidesGenerator::UpdateState] \Ephere\Ornatrix\Operators\HairFromGuidesGenerator.cpp(2668): error: I need at least 1 sparse roots to work with.

[Info ] [t 2566337] [tid main ] [M 8072244] [::] OpenCL: 2 devices discovered

[Info ] [t 2566338] [tid main ] [M 8072244] [::] OpenCL: using device GeForce RTX 2060 SUPER version OpenCL 1.2 CUDA

I just tested on a clean Windows 10 VM with C4D R23 and Ornatrix 2.1.2 latest stable. It does indeed look as if it's freezing on the C4D splash screen with the "Initializing Plugins..." message at the bottom, but eventually the Ornatrix authorization dialog appears.

I did get it to work however by paying close attention of what plugins Vegas was initializing upon start-up (there at the bottom of the Vegas startup screen) when it was scanning so I was able to see what .dlls it was stuck on. I moved them temporarily outside of the VST folder and got it to open.

One of the major changes of Cinema 4D 2024 release is the general improvement of scene execution speed achieved trough careful modifications of central parts of the classic API. It is important that plugins follow these changes faithfully as plugins substantially determine the scene execution speed of a loaded document. Since scene execution happens largely in the so called classic API, most changes can be found in the cinema.framework. The most important abstract changes are:

We unfortunately cannot make any development cost predictions for multi-version code base solutions, as these never have been supported by the SDK group as stated in the Development Environments manual. In the custom circumstances of the 2024.0 API migrations we encourage developers who use such solutions and run into troubles, to reach out to us for help.

The change documentation is accompanied by a new section in the SDK, \plugins\example.migration_2024, containing a NodeData plugin migration example (Fig. 1) in oboundingbox.cpp and oboundingbox_legacy.cpp, as well as other examples in change_examples.cpp.

The overarching theme of the 2024.0 API changes is the more precise distinction between mutable and immutable data. This is done so that data can be reused and so that scene execution can be more effectively parallelized. The foundation of all this is the correct application of const-ness to methods in the Cinema 4D API. This has happened for many non-overrideable types where adaptions in third party code are often not necessary or only yield a performance benefit. But legacy plugin code that implements overridable types such as ObjectData or TagData must be adapted. Multiple NodeData methods and the methods of derived types have been made cosnt to allow for such more efficient scene execution. An example for such change is NodeData::GetDParameter where both the method itself as well as the node passed to it have become const:

In general, one should strive for embracing these restrictions, as circumventing them can be expensive both in development and runtime costs and can potentially lead to crashes when not carried out properly. The example shown below is taken from the example.migration_2024 plugin Oboundingbox. The legacy version of that plugin counted the access to one of its parameters in its NodeData::GetDParameter method by incrementing a class bound counter field _get_display_mode_count. The 2024.0 code shown below demonstrates different approaches for translating such feature requirement to a method which is now const.

With the introduction of the Asset Browser, scene elements often must be reinitialized to drive the Asset API preset system. isCloneInit indicates now such cloned node allocations which are usually deallocated right after their allocation. It is not necessary to initialize the data container of a node in these cases, as Cinema 4D will copy the data from a source node right after such isCloneInit call. Using this argument and NodeData::CopyTo, plugin authors can now also avoid doing expensive initialization computations more than once for the same data.

The classic API provides now an all new data dependency system for scene elements. It allows for the more effective parallelized execution of certain stages of the scene execution such as generator or deformation cache building. While the system does realize a long desired dependency system between classic API scene elements, it is not a user oriented system at the moment. Its only purpose is the optimized parallelization of scene execution. The frontend of the system can be found in BaseList2D:

The example below is taken from the example.migration_2024 plugin Oboundingbox. The ObjectData plugin returns a bounding box geometry for its first child object as its generator cache. In its NodeData::GetAccessedObjects method, the plugin then expresses its data dependencies for building that generator cache.

Reworked was also the data container access for scene elements, now differentiating clearly differentiating between read and write access. It is recommended to use the reference methods over the pointer methods.

Containers should be copied with the BaseContainer copy constructors or one of its copy methods. BaseContainer BaseList2D::GetData will be deprecated, as its copying behavior has often been invoked unintentionally.

GeListNode::GetBranchInfo now operates with the concept of a maxon::ValueReceiver and therefore also returns a maxon::Result. This eliminates the need of predicting the number of branches that must be accessed and allows for terminating searches early.

The types VariableTag and BaseTag now store their internal data as copy-on-write (COW) references. This has far-reaching consequences because VariableTag is the storage form of most fundamental scene data such as points, polygons, normals, tangents, and vertex data. Creating for example two Cube object instances with the exact same settings, will have the result that the Tpoint, Tpolygon, and `Tuvw tags in their generator caches reference the same data in memory (Fig. 2). Effectively, there is only the geometry data for one cube object being stored memory, without any explicit actions from the user such as an Instance object.

Similar optimizations can also happen for editable geometry. Internally, these optimizations rely on the already existing memoization optimization of the modeling core of Cinema 4D. The referencing of data is being updated on the following events:

There are also constructors and a ::Create method on DescID which are wrapped by these macros, but they should not be called manually. Most DescID constructor calls in old code should be replaced by ConstDescID, since most parameter IDs are usually compile-time constants.

The decision what to pass in each case for create should be guided by the goal of minimizing idle event-handlers. As a rule of thumb, adding observers requires the observable to be created, but removing observers from an observable or notifying an observable can be terminated when the observable does not yet exist in the first place. There could, however, be cases where it for example only makes sense to add an observer when the observable does already exist or analogously to allocate a non-existing observable to notify it without any observers yet being present.

Gradient and FieldObject sampling has been changed so that all sampling related methods are now const to ensure performant sampling. This is achieved in both cases by helper data structures returned by the respective initialization methods, GradientRenderData for gradient sampling and maxon::GenericData for field sampling. Similar changes have been applied to EffectorData sampling, but operating plugin hooks is not part of the public API and therefore not here documented. Please reach out to the SDK group via sdk_support(at)maxon(dot)net in case you must sample your own EffectorData instances and run into troubles doing so.

Instances of maxon::DataDictionary can become a bottleneck when being accessed thousands of times in quick succession. The type maxon::AttributeTuple provides a lightweight alternative for cases where the data schema is known at compile-time which acts like a named tuple and shares the the performance characteristics of native C-data-structures.

With the API overhaul, we removed a substantial amount of C-style casts from our code base because such casts are dangerous due to their unbound nature. C++ style casting is and will not become mandatory in Cinema 4D projects in the near future. But we encourage all third party developers more than ever to follow our example and remove them from their projects. A minor change has been made to our style guide, which now does recommend conversion constructors over C-style casts for fundamental types.

The culprit is the custom qualifier SDK_CONST, as the source processor only allowed for a predefined pool of such function and variable qualifiers in the past. With 2024.0 the source processor allows to define custom qualifiers on a framework and file level.

With // stylecheck.register-qualifiers = Qualifier; [Qualifier; Qualifier; ...] we can register one to many qualifiers. Multiple stylecheck.register-qualifiers comments in a file act additively. It is recommended to put the registration calls at the top of the file, but it is only mandatory to place them before the first usage (not definition) of a custom qualifier symbol. So, this works too:

3a8082e126