Hey @hSchoenberger,

as I said, what we provided there is mostly a workaround, we'll have to streamline things there. I cannot talk much about the details here, since I do not yet know myself how we will solve this.

Please open new topics for new questions in the future, especially bug reports should remain clean.

Our render pipeline, and that includes commissioning third party renders, converges into a singular point. There are currently four entry points into that pipeline:

1. The built-in commands such as "Render to Picture Viewer", "Render View", "Render Region", etc. For them this pipeline has been built initially. This is basically the gold standard to measure against. Also headless Cinema 4D instances such as the command line or c4dpy use this mechanism when invoked for a rendering.
2. The c4d.document.BatchRender it works as (1) but the drawback compared to RenderDocument is that you must always operate on files on disk. I.e., you cannot just change a document im memory and then render it, you must first save it to disk, and also your output will provided on disk and not as bitmaps in memory. As stated before, this is the way I recommend. You will not have to apply any OCIO hacks here.
3. The .net Renderer, a.k.a, Team Render, basically the same as (2), just more complicated. And other than for (2), not all third party renderers do support Team Render.
4. RenderDocument differs from these three in that it does not take the full length of our render pipeline, but just a subsection of it. RenderDocument is used internally to render icons and preview images and was never intended to be the 'programmatic rendering interface' it has unfortunately has been in the past marketed as and is used as by many third parties. The advantage of RenderDocument is that you can easily operate in memory only without any disk activity.

Whoever asked me in the past, I always told them that using RenderDocument as a render pipeline endpoint is not such a good idea because that is not what it is designed for. Not because I was prophetic about the OCIO issues, but because there are also other short-comings due to it not taking the full route in the render pipeline.

With OCIO this worsened, as we have intertwined the render pipeline, the Picture Viewer, and saving output to disk even more, i.e., things RenderDocument is naturally left out of. Internally we can 'just' write code to fix this when we use RenderDocument, but for third parties not all of these tools are even available in C++ (and even more are missing in Python), and generally Python devs also have a lower pain tolerance when it comes to writing boiler plate code.

I simply do not know yet how I will fix this, as this is largely not my code. But for me is clear that this must be simplified in Python. This could either happen in the form of fixing RenderDocument regrading its Picture Viewer and BaseBitmap.Save, i.e., BitmapSaver interactions, or by giving the BatchRender more RenderDocument like qualities.

The solution to this will not be super simple, and it will likely not arrive within 2025. For now there is a somewhat functional workaround for RenderDocument and you can always use the BatchRender.

Cheers,
Ferdinand

Dear Developers,

the 2025.2.0 release did not add what I would consider a full fix for this, but at least a workaround. Have a look at the code example RenderOcioDocumentToPictureViewer.

We will have to streamline things a bit there, but for now this is at least a functional solution.

Cheers,
Ferdinand

Dear Developers,

the 2025.2.0 release did not add what I would consider a full fix for this, but at least a workaround. Have a look at the code example RenderOcioDocumentToPictureViewer.

We will have to streamline things a bit there, but for now this is at least a functional solution.

Cheers,
Ferdinand

Dear development community,

On April the 2nd, 2025, Maxon Computer released Cinema 4D 2025.2.0. For an overview of the new features of Cinema 4D 2025.2, please refer to the release announcement:

Alongside this release, a new Cinema 4D SDK and SDK documentation have been released, reflecting the API changes for 2025.1.0. The major changes are:

C++ API

• Added CMake support for the C++ SDK. Among other things, this brings Clang build system support to Windows and removes the Legacy Build System requirement under XCode.
• Deprecated the Project Tool build system generator. All Cinema 4D 2025.2.X releases will support both the Project Tool and CMake as build system generators. After that, Project Tool support will be removed entirely and SDKs will only support CMake.
• Updated he C++ standard the Cinema 4D SDK is targeting. Under CMake, the Cinema 4D C++ SDK is now targeting C++20.
• Updated and and streamlined "Introduction" section and multiple manuals in it. There is a new API Overview manual to help beginners with getting started with the Cinema 4D API. The getting started section has been moved to Quickstart and both the Windows and macOS got a small video tutorial series which guide users from unpacking the SDK to creating their first simple plugin.
• Added three new code examples (only the extended SDK contains all of them at the moment).

Python API

• Added OCIO (OpenColorIO) support and a new code example for it.
• Fixed multiple bugs and added features, among other places in the Asset API, the Volume API, and the GeDialog/GeUserArea model.

Head to our download section for the newest SDK downloads, or the C++ and Python API change notes for an in detail overview of the changes.

Happy Christmas 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.

Hey @indexofrefraction,

it seems I was a bit unclear in what I meant.

1. Your question (and also @spedler answer) are incorrect in that they assume 'green check mark means that an object has the flag OBJECT_GENERATOR'. There are many exceptions to this, as for example deformers, cameras, and lights (at least the old standard renderer ones).
2. The green check mark is expressed by ID_BASEOBJECT_GENERATOR_FLAG and all objects have that parameter as it is part of the object base description. It is just that some object types hide it, and restrict write access to it. But you can always attempt to write to it.
3. Your whole approach does not make too much sense (at least without further explanation). As always, we do not expose GUI details, but the data behind it - which in this case is ID_BASEOBJECT_GENERATOR_FLAG. You can set this flag blindly on any object, some objects will just refuse write operations which set this to False (as they are object which cannot be disabled).

And, yes, changing a parameter makes an object data dirty which entails Cinema 4D rebuilding the scene graph. But that was not how my code example was meant. It just demonstrates how this works. When you want to disable an object, you can just attempt to do it, and when it fails, you know that the object does not support being disabled. This whole of approach of "I want to know if an object has a green check mark" is wrong.

You could clone a node to set the parameter without having changes affect the scene graph. But cloning nodes can also be a quite expensive operation. Looking into the description could be another way, you would have to get the description container for ID_BASEOBJECT_GENERATOR_FLAG and then check if DESC_HIDE is set. That is at least how I would expect that they have realized that.

Cheers,
Ferdinand

Hello @indexofrefraction,

Thank you for reaching out to us. Here seem to mix up two questions, let me split them up.

How to find out if something has a green check mark?

The green checkmark and its counterpart the red cross are just an alternative way to set ID_BASEOBJECT_GENERATOR_FLAG, i.e., the enabled state of an object.

The caveat is however that this parameter is part of the BaseObject Description model, i.e., literally every object has that parameter. It is just that some object types hide and restrict write access to it. So, this applies:

# Get/set the generator flag of an object where we know that it has that GUI, can be disabled.
state: bool = op[c4d.ID_BASEOBJECT_GENERATOR_FLAG]
op[c4d.ID_BASEOBJECT_GENERATOR_FLAG] = not state

def CanDisable(obj: c4d.BaseObject) -> bool:
    """Tests if #obj can be disabled, i.e., if it has the "check mark GUI".
    """
    # An object which is disabled always has that GUI.
    if not obj[c4d.ID_BASEOBJECT_GENERATOR_FLAG]:
        return True
    
    # Attempt to disable the object.
    obj[c4d.ID_BASEOBJECT_GENERATOR_FLAG] = False
    
    # The object refused being disabled, it hides that GUI.
    if obj[c4d.ID_BASEOBJECT_GENERATOR_FLAG]:
        return False
    
    # The object let us write the state, reinstate the previous state and return #True
    obj[c4d.ID_BASEOBJECT_GENERATOR_FLAG] = True
    return True

# Figure out if something lets us write to #ID_BASEOBJECT_GENERATOR_FLAG, i.e., if it can be
# disabled.
print(CanDisable(op))

What is a generator?

But the underlying question is: What qualifies as a generator? We have to remind ourself that modern day Cinema 4D (V5 up 2025.1.0) is a 27 years old software project. There is bound to be some terminological noise and inconsistency how flags are set/interpreted because when there is one thing developers love to do, then it is bending the rules .

The OBJECT flags do exist to enable API features when an ObjectData plugin is registered. BaseList2D::GetInfo just exposes that registration data and is not meant as a user facing classification of objects. Because which OBJECT flags are passed and which kind of object plugin registration function is called, then determines how Cinema 4D operates that object in the scene graph. OBJECT_GENERATOR in combination with IS_SPLINE for example makes it so that Cinema 4D calls ObjectData::GetVirtualObjects or ObjectData::GetContour, the methods which implement a polygon or spline object generator.

But over the time, our developers got creative, and there are now objects which act both as objects and splines, objects can (sort of) act as tags, and many things more. And then there are of course things like null objects, lights, cameras and more, which escape the pattern "poly generator, spline generator, point deformer, or particle deformer" entirely. When interpreted practically, I would classify everything as a generator that has a cache that is not a null object. You can read more about our object model here.

Last but not least, when you just want to find out if something is a field, you can just test for OBJECT_FIELDOBJECT. But just as for OBJECT_GENERATOR, some things might bend on a technical level the rules of what a field is and what not, as these are not classification flags but API features enabling flags.

Cheers,
Ferdinand

Hi sorry I fixed my code.

Cheers,
Maxime.

Hi Sebastian,

Thanks for your patience. TLDR; it's a bug but you still need to set minimal width.

The issue is twofold:

1. For this UI element to work as intended you need to specify the minimal width argument minw, for example using the c4d.gui.SizeChr() function:
   self.AddCustomGui(self.ID_TEXT_1, c4d.CUSTOMGUI_FILENAME, '', c4d.BFH_SCALEFIT, c4d.gui.SizeChr(80), 0, bc)
2. There's currently a bug, which prevents this from working properly. The fix is going to be included in one of further Cinema 4D releases.

After the fix is released, given you're using the minw argument, the issue wouldn't be there anymore. Thanks for drawing our attention to this issue!

Cheers,
Ilia

Hey @gheyret,

you can project a world space coordinate into screen space with BaseView. But ViewportSelect is more meant for user interactions as its name implies.

We had this morning a quick talk about your subject, and my stance was mostly that it does not make too much sense to port something like KDTree to Python. Because while porting itself is entirely technically possible and the result is then performant (enough), it implies a technical complexity which is not. So, you are then basically able to process point neighbour hood blazingly fast in Python, but that implies processing a lot of points (at which Python sucks). Which is why I recommended ViewportSelect as a workaround for cases where you only have to lookup the neighbor of a handful of points. But for your case, you will not get very far with ViewportSelect.

Because in the end remains the fact that the popular computational geometry algorithms which could use something like a KDTree: differential growth, shortest path on a mesh, heat maps, optimal coverage (e.g., space colonization), etc., tend to be very complex computationally and therefore not very sensible to be implemented in Python. Going over ViewportSelect would make things even slower (and also imprecise).

Maxime has this still on his agenda and you might get lucky. I am of course aware that there is a wide range of what people would consider "acceptable" computation times. Technical artists are sometimes fine with a script running for 5, 10, 20 minutes; i.e., just brute forcing something. And in the end you can also write yourself at least an octree relatively easily in Python (with a then to be expected performance).

Cheers,
Ferdinand

Hey @gheyret this is on my bucket list of things I want to port it since a long time, but to be honest it's rather low-priority.

But I will keep it in mind.With that's said depending on what you want to do you may find ViewportSelect Interesting.

Cheers,
Maxime.