Hey,

there is no NOT in the query syntax, if that is what you are asking for, although that could be a cool idea. What you would have to do, is apply two partial descriptions in one ApplyDescription call, one that first selects all nodes with an enabled preview and disables it, and then one which selects the end node and disables its preview. Or just carry out two successive ApplyDescription calls.

Cheers,
Ferdinand

PS: You can of course do whatever you want with your module attributes, and things like __author__, __license__, __email__, etc are not formally standardized, but the quasi standard module attribute is called __author__, there is no __authors__. When you have multiple authors, you usually put them semicolon separated into the __author__ field. When you use __authors__, tools which support that quasi standard won't find your attribute and the whole purpose of these module attributes is being machine readable, as you could otherwise also just write things into the doc string of the module.

See:
The original Python Enhancement Proposal by Guido van Rossum (the now famous pep8) which introduced the concept of module dunder attributes and one of the many guides of how people interpret this, what this has evolved into.

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

With that's said we are not a coding service, but we offer help to people to learn how to use the Cinema 4D SDK. So in the future please show us that you tried a bit at least and where are you blocked so we can help you. Let's cut your question in two.

First one, "How to change the ColorSpace" of all materials. You can find an answers in this topic: SetPortValue for Texture node ColorSpace. However this affect only the new Redshift Node Material. If you want to support the old one (xpresso based node material) let me know. You can retrieve all materials using BaseDocument.GetMaterials.

Then second one, "How to restore value", there is no magic here you need to store the value somewhere. It depends on the behavior you are expecting, if you want to support this ability even if you close and re-open the file. The best way would be store this data in the BaseContainer of the material you modified. A BaseContainer is like a Python Dictionary but it's a Cinema 4D that is attached to any objects/tags/material in Cinema 4D. Any information written into it is then saved in the c4d file. The drawback is that not all datatype are supported.

So with that's said here a possible example on how to achieve what you want:

""" This script automates the process of changing the ColorSpace of all textures in a Cinema 4D project, specifically targeting new Redshift Node materials. It performs the following tasks: 1. Iterates through all materials in the active document and identifies Redshift materials. 2. For each Redshift material, retrieves the current ColorSpace values of texture nodes (e.g., RAW, sRGB). 3. Changes the ColorSpace of the texture nodes to a predefined target (TARGET_COLOR_SPACE, default "ACEScg"). 4. Serializes and stores the original ColorSpace values in a `BaseContainer` attached to the material, ensuring persistence across sessions. 5. If needed, restores the original ColorSpace values if they were previously saved, allowing for easy reversion. 6. The process is fully automated with a single execution, and the changes are saved to the material for future use. """ import c4d import maxon doc: c4d.documents.BaseDocument # The currently active document. op: c4d.BaseObject | None # The primary selected object in `doc`. Can be `None`. # Be sure to use a unique ID obtained from https://developers.maxon.net/forum/pid UNIQUE_BC_ID = 1000000 NODESIDS_BC_ID = 0 VALUES_BC_ID = 1 TARGET_COLOR_SPACE = "ACEScg" def GetDictFromMat(mat: c4d.Material) -> dict: """ Retrieves a dictionary containing the current ColorSpace values of a material. The ColorSpace values are serialized into a `BaseContainer` and stored on the material, ensuring that the data persists even after the file is closed and reopened. This is done because node IDs are unique for each material graph, so the serialized data is specific to the material and its associated graph. Args: mat (c4d.Material): The material object whose ColorSpace values are to be retrieved. Returns: dict: A dictionary where keys are node IDs (unique to the material's graph) and values are the corresponding ColorSpace values. The dictionary is constructed from data stored in the material's `BaseContainer`, which persists across sessions. """ matBC: c4d.BaseContainer = mat.GetDataInstance() personalBC: c4d.BaseContainer = matBC.GetContainerInstance(UNIQUE_BC_ID) if personalBC is None: return {} nodeIdsBC: c4d.BaseContainer = personalBC.GetContainerInstance(NODESIDS_BC_ID) nodeValuesBC: c4d.BaseContainer = personalBC.GetContainerInstance(VALUES_BC_ID) if nodeIdsBC is None or nodeValuesBC is None: return {} dct: dict = {} for index, _ in enumerate(nodeIdsBC): nodeId = nodeIdsBC[index] colorSpaceValue = nodeValuesBC[index] dct[nodeId] = colorSpaceValue return dct def SaveDictToMat(mat: c4d.Material, dct: DictType) -> None: """ Saves the ColorSpace dictionary back to the material, ensuring that the data is serialized into a `BaseContainer` and stored on the material. This serialized data will persist across sessions, so the original ColorSpace values can be restored even after the file is closed and reopened. Since node IDs are unique for each material's graph, the data is saved in a way that is specific to that material and its texture nodes. Args: mat (c4d.Material): The material object to which the dictionary will be saved. dct (dict): A dictionary where keys are node IDs (unique to the material's graph) and values are the corresponding ColorSpace values. This dictionary will be serialized and saved in the material's `BaseContainer`. """ matBC: c4d.BaseContainer = mat.GetDataInstance() # Create containers for node IDs and their corresponding ColorSpace values nodeIdsBC = c4d.BaseContainer() nodeValuesBC = c4d.BaseContainer() # Populate the containers with the node IDs and ColorSpace values from the dictionary for index, key in enumerate(dct.keys()): nodeIdsBC[index] = key nodeValuesBC[index] = dct[key] # Create a personal container to hold the node IDs and values personalBC = c4d.BaseContainer() personalBC[NODESIDS_BC_ID] = nodeIdsBC personalBC[VALUES_BC_ID] = nodeValuesBC # Attach the personal container to the material's data container matBC[UNIQUE_BC_ID] = personalBC # Set the material's data with the updated container, ensuring the ColorSpace values are stored mat.SetData(matBC) def main() -> None: """ Main function to automate changing the ColorSpace of all textures in the project. It changes the ColorSpace to TARGET_COLOR_SPACE and stores the previous values in the BaseContainer of the material, a kind of dictionary but in Cinema 4D format so it persists across sessions. This allows for reverting the ColorSpace values back to their original state, even after closing and reopening the file. """ # Loop through all materials in the document for material in doc.GetMaterials(): # Ensure the material has a Redshift node material nodeMaterial: c4d.NodeMaterial = material.GetNodeMaterialReference() if not nodeMaterial.HasSpace(maxon.NodeSpaceIdentifiers.RedshiftMaterial): continue # Retrieve the Redshift material graph graph: maxon.NodesGraphModelRef = maxon.GraphDescription.GetGraph( material, maxon.NodeSpaceIdentifiers.RedshiftMaterial) # Retrieve the existing ColorSpace values as a dictionary from the material matDict: dict = GetDictFromMat(material) # Begin a graph transaction to modify nodes with graph.BeginTransaction() as transaction: # Define the asset ID for texture nodes in the Redshift material rsTextureAssetId = "com.redshift3d.redshift4c4d.nodes.core.texturesampler" # Loop through all the texture nodes in the material graph for rsTextureNode in maxon.GraphModelHelper.FindNodesByAssetId(graph, rsTextureAssetId, True): # Find the ColorSpace input port for each texture node colorSpacePort: maxon.GraphNode = rsTextureNode.GetInputs().FindChild( "com.redshift3d.redshift4c4d.nodes.core.texturesampler.tex0").FindChild("colorspace") # Skip the node if the ColorSpace port is invalid if not colorSpacePort or not colorSpacePort.IsValid(): continue # Get the path which is unique for each graph for this ColorSpace port colorSpacePortId = str(colorSpacePort.GetPath()) # If there's an existing ColorSpace value, restore it to the previous state if colorSpacePortId in matDict: colorSpacePort.SetPortValue(matDict[colorSpacePortId]) # Remove the entry from the dictionary after restoring, # so next time the TARGET_COLOR_SPACE will be used del matDict[colorSpacePortId] else: # Otherwise, store the current ColorSpace value and set the new target ColorSpace previousValue = colorSpacePort.GetPortValue() if previousValue.IsNullValue(): previousValue = "" matDict[colorSpacePortId] = str(previousValue) colorSpacePort.SetPortValue(TARGET_COLOR_SPACE) # Commit the transaction to apply the changes to the material transaction.Commit() # After modifying the ColorSpace values, save the updated values back to the material SaveDictToMat(material, matDict) # Refresh the scene to ensure the changes are applied c4d.EventAdd() # Run the main function when the script is executed if __name__ == '__main__': main()

Cheers,
Maxime.

Thanks, I'll test Dirty on selection.

Hi @BigRoy,

Please check our Support Procedures in regards of the question structure, namely:

Singular Question: The initial posting of a support topic must contain a singular question. Do not ask ten things at once, that makes it extremely hard to answer topics. Break up your questions into multiple topics. Asking follow-up questions is allowed but they must be bound to the initial subject.

Singular Subject: From all this follows that a topic must have a singular and sparse subject tied to a specific problem. 'My Nodes API Questions' is not a valid topic as it splits up into too many subtopics. A valid subject could be 'accessing node attributes' or 'traversing a node graph'. One could for example first ask 'how to get the name attribute of a node?' and then ask a follow up question about 'how to get the icon attribute too?'. This specifically applies to plugins, just because you have two problems with one plugin does not mean that they should be asked in the same topic.

Regarding you question, there's no high level API that allows you to get a list of all files you've mentioned at once. This effectively means that not only do you need to access this yourself, but you also need to do so for the render engines you'd like to support, as these are likely going to differ among them.

Specifically for the Redshift AOVs and output files question, please check related threads:

get the names of redshift multi passes AOV names from the render settings Add Expression Value in Render Settings Save Path

As for the takes, the only application where they make any sense is the Render Queue. If you're not using it, it's only the active take that's being rendered. Of course you can deal with it by using SetCurrentTake function.

I suggest you keeping this thread for the "render output files" part of your initial question and encourage you to make separate postings for your other questions that diverse from this topic here.

Cheers,
Ilia

Hey @Smolak,

I understood what you wanted to do, but it is still not possible. First of all, the OCIO color space enum values are dynamically assigned, i.e., the value 3 might not always mean the same space. In the OCIO API there are special conversion functions for that, but you could also do that manually by parsing the description of the document.

But you will never be able to apply such value then, because to do that, you have to call BaseDocument::UpdateOcioColorSpaces which does not exist in Python (yet). See the C++ Docs for an example.

Cheers,
Ferdinand

Thank you @ferdinand for the help!

Write raw memory does help a lot, appreciate!

thanks @ferdinand this makes perfect sense now. I appreciate the time you took to explaint he best practice.

@ferdinand You are correct, there was no further question, I was just closing the loop in case someone else ran into something similar. Thanks for the additional suggestions.
-v

@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!

I use this to Thank You Ferdinand.

This is how I imagine an SDK example should look like .... a simplest version , an altered simple version and a complex touching the boundaries of the subject.
I am thankful and praise your work .... !

cheers mogh

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

@ferdinand

It is a blocking render using Commandline.exe
Are these questions?

An information.
In reply to your statements "The advantage is that with a thread one can realize non-blocking rendering with it" and to use "CallCommand".

But when you start another Cinema 4D.exe, or CommandLine.exe, or c4dpy.exe on the same machine,
they would all have their own render queue.

But if a new instance of C4D does not use the same render queue settings, how does it come that the same render queue is availabIe if I restart C4D?
Thats what I mean. The render queue settings/items are not bound to the executable instance, they are bound to the user settings.
Which means the artist has to clear the render queue every time he starts C4D.
And he looses old items on C4D restart.
But that would be an issue on MacOS only.
And still better than wrong frames.

(not quite sure how you use the CommandLine in this context)
The only Python code which will run in a CommandLine are plugins

Yes, you did not offer to run scripts directly, therefore we have written a plugin.
Our plugin works for 11 years now, since C4D version R16.
(We still have to support older C4D versions as well, but perhaps we create some new connection with a version switch in the future. But for now adding other features is more important)

Renderings in themself are not blocking

I know, I am familiar with the multi-threading of renderers.

Your function doRender() has already implemented blocking.
So blocking is not an issue.

letting GPU render slaves run on a machine an artist is actively working on

I know. We are working with Redshift since the first beta version.
I did not mean that 2 GPUs jobs run at the same time.
(With the exception that we offer the option to split your GPUs if you have multiple installed)
But it can run at night.
And there are CPU renderer which can be assigned to some cores of the machine while an artist is working

@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

Hey @vhardy,

yes, @m_adam as supporting expressions on his Todo list for the VS Code bridge. But it is not very high in our priority list, you are the first user requesting it. I gave the subject a gentle nudge in our task tracking.

FYI: Generally we do not make any guarantees if or when we will implement something.

Cheers,
Ferdinand

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!

Hello @patrick_cue,

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

Please do not use other topics for your support requests, especially when they are bug tickets. Asking a follow-up questions such as "when will this be fixed" or "does this also apply to situation B" in a foreign topic is allowed and even encouraged.

But a specific case with your specific code and data always warrants a new thread. Please also familiarize yourself with Support Procedures: Asking Questions, as while it its clear that you put effort into make yourself understood (thanks!), this is also bordering a bit on the too much information.

The bug tracked by the other topic, is that there is currently no way in the Python API to use c4d.documents.RenderDocument in an OCIO document (i.e., every document since 2025.0) and then display that bitmap with the correct colors via c4d.bitmaps.ShowBitmap. It is important to understand that:

The bitmap data generated is just fine, when you save the bitmap to disk, everything is correct. It is just that the Picture Viewer does not display it incorrectly.

The reason for that is that in Python OCIO is not fully exposed in 2025.1.0 and you cannot set the OCIO profiles of the rendered bitmap there. Internally, we have been working on an OCIO port for Python allowing for color conversions and more things, including OCIO managing bitmaps. We also added a function to bake a display and view transform into an sRGB image - another route how this RenderDocument issue can be solved.

The goal is to publish this with an upcoming version of the Python SDK, ideally the next, but as always we cannot make any guarantees. You cannot fix this issue yourself in 2025.1.0 and lower.

Cheers,
Ferdinand

Hey @kbar,

I hope you are well! Since I just answered a similar question in another topic, I am also answering here. We never make any guarantees regarding when something will be released in SDKs. And more-over, we never name upcoming Cinema 4D versions explicitly or when they will arrive. This also includes seemingly insignificant information such as if the next version will be a minor or a major version increment.

Please note that you as Maxon Registered Developer are bound by an NDA and also cannot disclose such information to the public.

But yes, I am pretty sure Maxime meant the next upcoming release.

Cheers,
Ferdinand