Hey @T1001,

I am still not 100% sure how you all mean that. But in short what you are doing is not possible in the public API and also only to some degree in the internal API. First of all, Cinema 4D only supports HDR in the viewport and it must be enabled by the user:

image.png

I.e., viewport effectively means Drawport API. What the docs write there about the only the viewport is only semi true, because you can embed a drawport into a GeDialog (but that functionality is still not even semi-public I think, but we could change that in a future release).

I am not quite sure what you mean by 'integrating a custom OpenGL pipeline into a plugin'. When I take this at face value, I would say you cannot do this. The Drawport API is an abstraction around effectively Vulkan and Metal. We do not write OS specific graphics API code anymore. This goes as far as that we have (sort of) our own shading language (MSL). You cannot just draw with OpenGL into a GeDialog, because that dialog will not be drawn with OpenGL and we also do not offer a direct access point to drawing handlers.

I assume this all has something to do with implementing some kind of render buffer? I really would recommend then applying for the Maxon Registered Developer program to get access to the Drawport API. Just as a warning ahead, the Drawport API is not totally undocumented but not documented to the same degree as our fully public API. It is an API from graphics API experts for graphics API experts. You seem fairly knowledgeable there, so this might be just your thing, but you have been warned, there will be less hand-holding there.

Cheers,
Ferdinand

Hi @ferdinand,

Sorry about missing that post. This exactly solved my problem, thanks.

Dam

Love the mxutils and GeDialog Changes, I use these features almost every time, thank you for having a more refined official version.

Thank you to the SDK team for their work achievements

Cheers~
DunHou

Hey @skibinvitaliy,

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

No one is judging you here, problems are part of the game and what we are here for to help with 🙂 . But please familiarize yourself with our forum rules, such question should be accompanied by example code and the version you are migrating from, as we otherwise mostly have to guess what is going wrong.

I am assuming you are migrating from a pre-2025 SDK, that is at least what your errors imply. With 2025 we introduced our cinema namespace. Please follow our Migrating Plugins to the 2025.0 API guide. You are likely just missing a couple of using namespace cinema; at the top of your files.

Cheers,
Ferdinand

Hey,

it seems I was a bit too tightlipped here. So in more verbose: You cannot customize the chosen unit of a parameter. This is impossible as this is a globally set value (which is also just smoke and mirrors as explained in the link above). There is a UnitScale custom GUI but it does not what you want, it is the field used in the document settings and is not really meant to store a value and unit but just a unit.

image.png

When you really-really-really want this, you can implement you own custom GUI, either targeting your own custom data types or existing data types. There you could then do whatever you want. But that might not mesh so well with the rest of Cinema 4D, given that Cinema 4D does not operate like that.

Cheers,
Ferdinand

Hey @ECHekman,

thank you for reaching out to us. This GUI does not support any of these flags (DESC_DEFAULT, i.e., DEFAULT is also not for gadgets but groups).

This means that you cannot toggle the collapsed state of a link box (be it a normal one or a texture one) by setting a description flag either in a resource file or programmatically. Which makes sense, because other than for example a color field or a group, a link box is not guaranteed to have content which could be unfolded.

Cheers,
Ferdinand

Hey @qq475519905,

sorry for the delay. As I said in the beginning, you can implement your own serializer using GoZ. But there is no dedicated exporter API in ZScript. I assume you are using some RoutineCall to achieve what you are doing. You cannot escape any GUI associated with such call.

Cheers,
Ferdinand

@m_adam, Thank you!

Yes, Message(GeListNode* node, Int32 type, void* data) works for me.

I'm wondering shall my plugin just return true after processing MSG_DESCRIPTION_CHECKDRAGANDDROP in the Message() function (set the value of DescriptionCheckDragAndDrop::_result) or still call SUPER::Message(node, type, data); at the end?
It looks to me that calling SUPER::Message(node, type, data); at the end still works.
But the example in MSG_DESCRIPTION_CHECKDRAGANDDROP Message doesn't call SUPER::Message(node, type, data);.

Thanks!

@m_adam, Thank you very much, this works for me!

Oh, you've edited your previous message! Thanks! I will try it.

@ferdinand Thanks for the response.

That's what I was afraid the situation would be, I believe I have a work around that will be able to fulfill what I need it to do.

John Thomas

Hi @m_adam ,

Thank you so much! That was exactly what I needed.

Dan

Hi,
yes, this is expected, and documented in NodeData::Read() / NodeData::Write() Manual. With that's said Read/Write is supposed to serialize data of your object (most of the time member variable) to the c4d file (the HyperFile), so accessing the BaseDocument is a sign of a bad design.

May I ask why do you really want to access the BaseDocument in the Read function?

Cheers,
Maxime

edit (@ferdinand): Just to be clear here, as we briefly talked about this in our morning meeting, what the docs write there is in a certain sense legacy information. When a branch, e.g., the Xbase (shader) branch of a material is being deserialized, the to be deserialized node is inserted into the branch and with that will have access to a document.

But what @m_adam wrote is of course true, the document in this context is the fruit from the forbidden tree, as the node is not yet fully deserialized and certain parts of the GeListHead::Read, GeListNode::Read, BaseList2D::Read, ..., YourPluginLayer::Read deserialization chain might pull all sorts of tricks to carry out the deserialization, including temporarily removing the node from the scene graph.

The documentation is therefore effectively still correct, as deserializing a node should never rely on the document context and accessing the document is forbidden in that context.

Hey,

so I talked with Fritz, I got the direction right, but there are some relevant details. When you set the flag for an importer hook, it signals that you do not want Cinema 4D to carry out the automatic scene color conversion along the conversion path implied in the settings.

So, when you have a importer, and it does NOT set the flag, and you would import a scene with these settings:

c3e3d6f8-2734-41d2-abfb-f7af807c12f8-image.png

Cinema 4D would transform all scene colors from sRGB-2.1 to the Render Space. When you DO set the flag, Cinema 4D will NOT do that, and the importer is expected to handle that.

So, when you need to set this flag, this implicitly means that something with your scene data is not correct, they are not meant to be sRGB. You can of course also change the respective setting, Raw for example means as always no conversion. Without a bit more details about your scene data and its provenance, it is hard to give here good advice.

Cheers,
Ferdinand

PS: I might update the im/exporter examples at some point to showcase the custom case, but the default should be to NOT to set the flag, and let the intended color management of Cinema 4D do its work.

Thank you very much for all your detailed explanation, @ferdinand!

Thanks for helping out @spedler!

Hello @DayDreamer,

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: Asking Questions.

About your First Question

This is your first posting and you did well, but I would point you to our 'singular question' rule, as lined out above in the 'Asking Questions' link. While we usually cut user some slack regrading that, the rule exists for a reason, as topics otherwise tend to become gigantic. There are way too many questions in this topic, please split your questions into multiple topics in the future.

There is no mechanism to package and ship plugins under Cinema 4D. You can just zip a plugin folder and the user unzips it then in a path where his or her Cinema 4D instance is looking for plugins. xdl64 is the extension Cinema 4D uses for libraries under Windows, i.e., it is more or less an alias for dll (our library linking is kind of special and right between static and dynamic libraries, hence the custom name). So, no, Python plugins cannot be packaged as xdl64 because Python is not compiled into machine code but interpreted at run time. You can mix C++ and Python plugins in the sense that Python plugins can depend/interact with C++ plugins with the means of the Cinema 4D API. E.g., a Python plugin can react to messages sent by a C++ plugin or data placed by a C++ plugin (or vice versa). That is how our Python API works under the hood. But C++ and Python code cannot interact directly of course, as they are vastly different languages. But you can run our Python VM from C++ and eval the results. When you want to protect your intellectual property, you can use our Cinema 4D | Extensions > Tools > Source Code Protector which will encrypt a pyp Python module. But code must of course be decrypted at runtime to be sent to the Python VM, so, this will not really stop anyone who really wants your source code (a cracker for example). C++ is the by far safer option when intellectual property is important (but also C++ can be decompiled).

Cheers,
Ferdinand

Hi Kent,
the cast is safe. In the public API, NimbusInterface is an incomplete type. Only NimbusBaseInterface is defined there. But internally, NimbusInterface is derived from NimbusBaseInterface, therefore you can safely do the cast.