Cinema 4D

ferdinand

I forwarded this to the build team (who own this part of the build system). Let's see what they say, I will update this topic once I have an answer.

ferdinand

Hey @peter_horvath,

Thank you for reporting this. I have never encountered this because I am habitually never use any white space in folders when it comes to coding but I understand this can be annoying. As far as I understand your posting correctly, you are placing the Cinema C++ SDK in the designated library folder of MacOS, more concretely its 'Application Support' sub folder, and the white space in that folder name is then causing issues with the prebuild event scripts?

I would have to check if we can fix this, as this is a part of the build system (the frameworks) that is not owned by SDK. And just for clarity, you propose to change the relevant files to something like this:

# Section: macOS
set(exclude_from_build.MACOS /win)
set(prebuild_event.MACOS.DEBUG "mkdir -p ~/Library/Application\\ Support/MAXON ; cp -f \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/maxon.py\" ~/Library/Application\\ Support/MAXON/maxon.py ; perl -w \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/copytypeviewer.pl\" maxon.py ~/Library/Application\\ Support/MAXON/maxon.py")
set(prebuild_event.MACOS.RELEASE "mkdir -p ~/Library/Application\\ Support/MAXON ; cp -f \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/maxon.py\" ~/Library/Application\\ Support/MAXON/maxon.py ; perl -w \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/copytypeviewer.pl\" maxon.py ~/Library/Application\\ Support/MAXON/maxon.py")

# Section: iOS
set(exclude_from_build.IOS /win)
set(prebuild_event.IOS.DEBUG "mkdir -p ~/Library/Application\\ Support/MAXON ; cp -f \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/maxon.py\" ~/Library/Application\\ Support/MAXON/maxon.py ; perl -w \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/copytypeviewer.pl\" maxon.py ~/Library/Application\\ Support/MAXON/maxon.py")
set(prebuild_event.IOS.RELEASE "mkdir -p ~/Library/Application\\ Support/MAXON ; cp -f \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/maxon.py\" ~/Library/Application\\ Support/MAXON/maxon.py ; perl -w \"${CMAKE_CURRENT_SOURCE_DIR}/typeviewer/xcode/copytypeviewer.pl\" maxon.py ~/Library/Application\\ Support/MAXON/maxon.py")

I.e., you want CMAKE_CURRENT_SOURCE_DIR compound paths to be quote escaped. If we will fix this, this will happen in an upcoming release and not a hotfix. For now you must either place the SDK in a path without whitespaces (or fix the CMake files yourself).

Cheers,
Ferdinand

ferdinand

Hey @Dimitris_Derm.,

The example py_msc_licensing shows you how to change the icon of a node at runtime. The example uses this to change the icon of unlicensed nodes and the trick is to listen for the message MSG_GETCUSTOMICON.
The example py_obj_assetcontainer shows you how to place icons in cycles (Cinema slang for drop downs). The trick is to set the label of the cycle item to "{Label}&i{IconID}&", e.g., "Cube&i5159&" would display the cube icon next to the word "Cube", because 5159 is the cube object icon id. You can do this both in resource files and dynamically as the example does it.

Cheers,
Ferdinand

ferdinand

Dear development community,

On October the 14th, 2026, Maxon Computer released Cinema 4D 2027.0. For an overview of the new features please refer to the end user release notes.

Alongside this release, existing APIs have been updated. For a detailed overview, please see the Cinema 4D C++ SDK and the Cinema 4D Python SDK change notes.

Cinema 4D

C++ API

Updated the CMake build system, now using a pure CMake config workflow, deprecating the old projectdefinition.txt files.
Add three new examples revolving around changes in this SDK.

Python API

Added agentic metadata to the SDK, improving performance and output of agentic workflows. Head to Working with the SDK for more information.
Reworked the documentation UI, porting over many features from the ZBrush SDK.
Reworked many code examples.
Reworked many manuals.
The Cinema API now offers vector image loading, better Javascript support for HTML controls, and node plugins can now implement custom branches.
In the Maxon API, there have been made improvements to graph descriptions, especially for querying graphs.
In the Mxutils API, scene traversal tools have been significantly improved, and new debug helper tools have been added.

Head to our download section to grab the newest SDK downloads.

Happy rendering and coding,
the Maxon SDK Team

Cloudflare unfortunately still does interfere with our server cache. You might have to refresh your cache manually to see new data when you read this posting within 24 hours of its release.

ferdinand

Unless I misunderstand the scope of the tool, you could implement this as a tool because a tool can draw. But with the caveat that the user has to enable it. But doing something like this as a scene hook is not great, even in C++. The reason is UX. Either you implement it as a pure scene hook with no feedback, then the user is stuck with always having this bounding box shown on the selected object. Or you add some kind of toggle that enables or disables it, but then you are already pretty close to reimplementing a tool.

Question is: Do you really need this bounding box overlay to be able to coexist next to another activated tool. If so, you need a scene hook. Otherwise you should go with a tool.

Cheers,
Ferdinand

ferdinand

Hey Anlv,

thank you for reaching out to us.

There is no SceneHookData equivalent in Python yet. In this cycle we just tested internally a prototype but we haven't made a choice there yet. The main concern is performance, especially of Draw. It is currently unclear if we will ever go forward with the idea of a Python SceneHookData.

The workaround we suggested in the past was to add a hidden object to a scene via a MessageData handler or any other node that has the methods you need. But that is not really better performance wise. In general is the idea to have a Python plugin which draws in each an every scene a bit of a mixed bag. I personally think it is not that much of a deal, because when the plugin slows down Cinema because the author wrote terrible Draw code, the user can just uninstall it. Some of my colleagues are more of the stance that we should not allow such setups at all, as the average user might be unable to pinpoint the plugin as the source of slowdowns.

Cheers,
Ferdinand

ferdinand

Hello @hey2495,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment.
Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support.
Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions.

About your First Question

I would try closing the file into which you imported the Alembic file. I just checked it, when I import any Alembic file, Cinema holds a lock onto it while the file into which you imported is still open. That seems to be an Alembic specific behaviour, not to say a bug. But it should be avoidable by simply cloning or merging the imported document, so that you can close the import document.

I will give the exchange team a heads up on this.

Cheers,
Ferdinand

ferdinand

First of all, you should open new topics for new questions, as one otherwise tends to derail old topics, which makes it hard to for others to follow things later. I forked your topic.

And I also do not quite understand what your question is. GetClosestMeshPrimitive returns you the primitive type via primInfo.

When you only want to get the closest point on a mesh, I would build a KD-Tree for its vertices. You then get the closest vertex and its index for your point p. Then you orthogonally project p onto the polygons attached to that vertex (via cinema:: Neighbor). Then you chose the closest point. We have this Python example for KDTree and I also used Neighbor there. Building a KD-tree or just brute forcing it depends a bit on how often you want to do it. For just a handful of points, brute forcing it is usually faster.

I am sure you can also do this with DistanceQueryInterface and the uvw coordinate returned in the PrimitiveInformation, but all that extra work where you have to deal with all the primitive types seems like more work than it is worth. And when you want to do this in a generator (by the looks of your screens), using a manual KDTree approach will make it easier to parallelize it effectively and make it go zoom zoom instead of computing all that extra data.

Cheers,
Ferdinand

ferdinand

Hey @dex,

distancequery.h is part of the mesh_misc.framework which you alreeady include. Sounds a bit like you have a corrupted build system on your hands or are not using the frameworks you think you are using. Where does the CMake fragment come from you show us? I assume you are using the old projectdefintion.txt sourced workflow (in which case you should us show that file). Or are you a beta member and have access to the 2027 SDK (which is natively pure CMake), in which case this would be invalid CMake markup, as some stuff has changed.

Have you checked in the IDE of your choice that the mesh_misc.framework shows up as a dependency of the project in which you want to #include "maxon/distancequery.h"? And just for the recoord, this is not a std lib, so you cannot use #include <> but must use #include "". And since this is part of the Maxon API, you also need to specify the maxon folder.

Cheers,
Ferdinand

ferdinand

Hey @mogh,

let me clarify things first a bit.

Reproduce:

You have a scene A in an alien scene format such as FBX or OBJ.
You have an existing native Cinema 4D scene B.
You are trying to merge A into B.

Result:
The objects of A appear before the objects of B in the scene hierarchy of the merged scene. Even when you change the insertion order in Preferences > Interface.

First of all, it is not very surprising that "insert at" does not work (and "paste at" does neither), because these are for individual objects within a scene, not for merging entire scenes. What you are effectively missing is a scene merge order option and this does not really have something to do with importers. This would be addressed best by a feature request in our Support Center.

With a pinch of Python, you can solve this yourself as demonstrated by @Anlv (thanks!). Using BaseList2D.GetGUID as @Anlv did is okay, but the more native solution would be hash(obj), i.e., C4DAtom.__hash__. Scene elements are for quite a while now natively hashable, so you can for example do this:

roots: set[int] = { hash(obj) for obj in doc.GetObjects() }
new_roots: set[int] = roots.intersection({ hash(obj) for obj in new_doc.GetObjects() })

And it will give you the set of all root level hashes (GeMarker IDs). I think also the transform copying @Anlv does at the end of the script should not be necessary, because these are root level objects, and therefore removing and re-adding them will not affect their transforms (as they have no parents to which their transform would be relative to). But I have not run @Anlv's full script myself, so it could be that I am overlooking something.

Cheers,
Ferdinand

I	i_mazlov
J	jana
M	maxon
F	ferdinand
M	m_adam

Global Moderators

Posts

Cinema 4D

C++ API

Python API

Getting Started

About your First Question

Member List