Forum wide moderators
Dear developer community,
The year 2025 comes to its end and between 15/12/2025 and 5/1/2025, the Maxon SDK Team will be short staffed. Please understand that we cannot deliver forum support in that period. For absolutely urgent matters - in the sense of business critical - please reach out via our contact form.
Happy Christmas and a happy new year to all developers,
the Maxon SDK Team
Hello @gelobui,
Welcome to the Maxon developers forum and its community, it is great to have you with us!
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.
It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions.
It depends a bit on how you mean your question. There is GetActiveNodeSpaceId which allows you to get the ID of the current node space. But there is no setting equivalent of that function. So, you cannot set a node space by its ID.
What you can do, is call the command which switches node spaces. These are however dynamically assigned and can have a different meaning, depending on how many render engines are installed. You can just check the script log after changing the space.
On this installation I have for example no extra render engines or node spaces installed, therefore Redshift is there 72000, 4.
But on this machine I have the C++ SDK installed and therefore the Example nodes space, so Redshift is now 72000, 5:
When you really want to do this in a fail safe manner, you would have to parse the menu of Cinema 4D to know with which sub-id to call CallCommand.
Cheers,
Ferdinand
Hey @lasselauch,
Thank you for reaching out to us. The issue is likely that you do not respect OCIO color management in your document. You have marked this posting as S26, but my hunch would be that you are using a newer version of Cinema 4D and an OCIO enabled document. The first implementation of OCIO showed up with S26 in Cinema 4D, although it was just some internal systems then such as the flag DOCUMENT_COLOR_MANAGEMENT_OCIO and user facing systems arrived with 2024 the earliest I think. In Python, you can only truly deal with this in 2025.0.0 and higher, as that is when we added the OCIO API to Python.
When you indeed are testing this on an S26 or lower instance of Cinema 4D, the major question would be if DOCUMENT_LINEARWORKFLOW is enabled or not. Because you cannot just blindly convert colors.
Is this the intended behavior? Should we always convert LINEAR→sRGB when drawing colors from ColorField/ColorDialog in a GeUserArea?
The question would be what you consider here this ;). But if the question is if it is intended behavior for a scene with DOCUMENT_COLOR_MANAGEMENT_BASIC and DOCUMENT_LINEARWORKFLOW enabled, to have all its scene element and parameter colors expressed as sRGB 1.0, then yes, that is the major gist of the old linear workflow. It is also intended that drawing happens in sRGB 2.2 up this day.
Issue 2: Eyedropper Roundtrip Doesn't Preserve Saturated Colors
Generally, multi question topics tend to become a mess (which is why we do not allow them). But in short: While roundtrips in the form of sRGB 1.0 -> sRGB 2.2 -> sRGB 1.0 are not absolutely lossless (you are always subject to floating point precision errors), there is no giant loss by default. I am not sure what math TransformColor is using explicitly. A simple pow(color, 2.2) and pow(color, 1/2.2) are the naive way to do this and the loss would be rather small. TransformColor might be respecting tristimulus weights which is a bit more lossy but still in a small range.
OCIO roundtrips on the other hand are generally quite lossy, because ACEScg is a very wide gamut color space and converting from ACEScg to sRGB 2.2 and back can lead to significant losses in saturated colors. Some conversion paths in OCIO are even irreversible in a certain sense (depending on what color spaces you have assigned to which transform). OCIO is rather complicated to put it mildly.
Is there a known issue with the ColorDialog eyedropper and color space conversion for saturated colors?
Not that I am aware of. But you likely just ignored OCIO. And while the default OCIO Render Space of Cinema 4D (ACEScg) is in a certain sense similar to sRGB 1.0 for low saturated colors, it diverges significantly for highly saturated colors. So, your loss of saturation is likely stemming from treating an OCIO document with an ACEScg render space as sRGB 1.0.
See also:
Last but not least, I attached an example of what you are trying to achieve, get a color from a color gadget in a dialog and draw with it faithfully in your own user area.
Cheers,
Ferdinand
"""Demonstrates how to correctly draw with OCIO colors in a dialog.
This examples assumes that you are using Cinema 4D 2025+ with an OCIO enabled document. It will also
work in other versions and color management modes, but the point of this example is to demonstrate
OCIO color conversion for drawing in dialogs (more or less the same what is already shown in other
OCIO examples in the SDK).
"""
import c4d
from c4d import gui
class ColorArea(gui.GeUserArea):
"""Draws a color square in a custom UI element for a dialog.
"""
def __init__(self):
self._color: c4d.Vector = c4d.Vector(1, 0, 0) # The color to draw, this is in sRGB 2.2
def GetMinSize(self):
return 75, 20
def DrawMsg(self, x1: int, y1: int, x2: int, y2: int, msg: c4d.BaseContainer) -> None:
"""Draw the color of the area.
"""
self.OffScreenOn()
# Draw the color.
self.DrawSetPen(self._color)
self.DrawRectangle(x1, y1, x2, y2)
class ColorDialog(gui.GeDialog):
"""Implements a dialog that hosts a color field and chooser as well as our custom color area.
The colors in the color field and chooser are in render space, so we have to convert them to sRGB
for correct display in our user area. All three color widgets are kept in sync, i.e., changing one
updates the others.
"""
ID_DUMMY_ELEMENT: int = 1000
ID_COLOR_CHOOSER: int = 1001
ID_COLOR_FIELD: int = 1002
ID_COLOR_AREA: int = 1003
SPACING_BORDER: int = (5, 5, 5, 5)
SPACING_ELEMENTS: int = (5, 5)
DEFAULT_FLAGS: int = c4d.BFH_SCALEFIT | c4d.BFV_SCALEFIT
def __init__(self) -> None:
"""Initializes the dialog.
"""
# Reinitializing the color area each time CreateLayout is called, could cause loosing its
# state when this is an async dialog docked in the UI and part of a layout, as CreateLayout
# can be called more than once when a dialog must be reinitialized on layout changes. So,
# doing it in __init__ or guarding it with a check if it is already created in CreateLayout
# is better.
self._color_area: ColorArea = ColorArea()
def CreateLayout(self) -> None:
"""Called by Cinema 4D to populate the dialog with elements.
"""
self.SetTitle("Dialog Color OCIO Demo")
# Using the same ID for dummy elements multiple times is fine, using IDs < 1000 is often
# not a good idea, as Cinema 4D usually operates in that range, and therefore an ID such
# as 0 can lead to issues (0 is AFIAK not actually used but better safe than sorry).
if self.GroupBegin(self.ID_DUMMY_ELEMENT, self.DEFAULT_FLAGS, cols=1):
self.GroupBorderSpace(*self.SPACING_BORDER)
self.GroupSpace(*self.SPACING_ELEMENTS)
# Add a color chooser and a color field.
self.AddColorChooser(self.ID_COLOR_CHOOSER, c4d.BFH_LEFT)
self.AddColorField(self.ID_COLOR_FIELD, c4d.BFH_LEFT)
# Add our user area to display the color.
self.AddUserArea(self.ID_COLOR_AREA, c4d.BFH_LEFT)
self.AttachUserArea(self._color_area, self.ID_COLOR_AREA)
self.GroupEnd()
return True
def InitValues(self) -> bool:
"""Called by Cinema 4D to initialize the dialog values.
"""
self.SetColors(c4d.Vector(1, 0, 0))
return True
def SetColors(self, color: c4d.Vector, doc: c4d.documents.BaseDocument | None = None) -> None:
"""Sets the colors of all color widgets to the given render space #color.
"""
# Just set the two color widgets first, as they expect render space colors.
self.SetColorField(self.ID_COLOR_CHOOSER, color, 1.0, 1.0, c4d.DR_COLORFIELD_NO_BRIGHTNESS)
self.SetColorField(self.ID_COLOR_FIELD, color, 1.0, 1.0, c4d.DR_COLORFIELD_NO_BRIGHTNESS)
# When the call did not provide a document, use the active document.
if not isinstance(doc, c4d.documents.BaseDocument):
doc = c4d.documents.GetActiveDocument()
# Check in which color mode the document is. Explicit OCIO color management exists in this
# form since S26 but it really only took off with 2025.
isOCIO: bool = False
if (c4d.GetC4DVersion() >= 2025000 and
doc[c4d.DOCUMENT_COLOR_MANAGEMENT] == c4d.DOCUMENT_COLOR_MANAGEMENT_OCIO):
# All colors in a document are render space colors (including the color fields in
# dialogs). GUI drawing however still happens in sRGB space, so we need to convert
# the render space color to sRGB for correct display. For that we need a document
# because it contains the OCIO config and the converted which is derived from it.
converter: c4d.modules.render.OcioConverter = doc.GetColorConverter()
# Transform a render space color to sRGB space (there are other conversion paths
# too, check the docs/examples on OCIO).
color: c4d.Vector = converter.TransformColor(
color, c4d.COLORSPACETRANSFORMATION_OCIO_RENDERING_TO_SRGB)
isOCIO = True
elif not isOCIO and doc[c4d.DOCUMENT_LINEARWORKFLOW]:
# For non-OCIO documents (older than S26 or DOCUMENT_COLOR_MANAGEMENT_BASIC), the scene
# element color space ('render space' in OCIO terms) can either be sRGB 2.2 or sRGB 1.0
# (linear sRGB), depending on whether DOCUMENT_LINEARWORKFLOW is set or not. In that
# case, we would have to convert from gamma 1.0 to 2.2. In a modern OCIO document, we
# could also use #converter for this, but for legacy reasons I am using here the old
# c4d.utils function. It might be better to use the converter when this is a 2025+
# instance of Cinema 4D. #DOCUMENT_LINEARWORKFLOW is really old, it exists at least
# since #R21 (I did not check earlier versions), so I am not doing another version check.
color = c4d.utils.TransformColor(color, c4d.COLORSPACETRANSFORMATION_LINEAR_TO_SRGB)
# Last but not least, in practice you would probably encapsulate this logic in your user
# area, similarly to how native color elements operate just in Render Space but draw in
# sRGB space. For dialogs (compared to description parameters), this is a bit complicated
# by the fact that one cannot unambiguously associate a dialog with a document from which
# to take the color management settings. A custom GUI of a description parameter can
# always get the node it is hosted by and its document. For dialog GUIs that is not possible.
# So, we have to do the active document approach I showed here.
# In a super production scenario, you would overwrite CoreMessage() of the user area or
# dialog, to catch the active document changing, to then update the color conversion, as
# with the document change, also the OCIO config could changed and with that its render
# space transform.
#
# All in all probably a bit overkill, and I would ignore this under the banner of "who
# cares, just reopen the dialog and you are fine". Because users will also rarely change
# the default render space transform of ACEScg to something else.
self._color_area._color = color
self._color_area.Redraw()
def Command(self, id: int, msg: c4d.BaseContainer) -> bool:
"""Called by Cinema 4D when the user interacts with a dialog element.
"""
if id == self.ID_COLOR_CHOOSER:
color: c4d.Vector = self.GetColorField(self.ID_COLOR_CHOOSER)["color"]
self.SetColors(color)
elif id == self.ID_COLOR_FIELD:
color: c4d.Vector = self.GetColorField(self.ID_COLOR_FIELD)["color"]
self.SetColors(color)
return True
# Please do not do this hack in production code. ASYNC dialogs should never be opened in a Script
# Manager script like this, because this will entail a dangling dialog instance. Use modal dialogs
# in Script Manager scripts or implement a plugin such as a command to use async dialogs.
dlg: ColorDialog = ColorDialog()
if __name__ == '__main__':
dlg.Open(c4d.DLG_TYPE_ASYNC, defaultw=480, defaulth=400)
I now also see that my example is buggy in the perspective view (and other views I have not implemented). For these cases you would have to do exactly what I did in my ohandlenull example, project the point into a plane placed on the origin of the object with a normal that is the inverse of the camera normal.
Given that this also affects internal code, it is quite likely that we will fix this. If I were you, I would just keep my old code and ignore this very niche edge case. When you really want this to work you would have to implement MoveHandle and handle the different view projections of Cinema 4D. This can probably be done in 50-100 lines of code or so, but it would be something I would try to avoid doing, as viewport projections can be tricky to handle.
Hey @PixelsInProgress,
so, I had a look. First of all, I came up with reproduction steps which you were lacking (see our Support Procedures). It is important to provide these, because when you just provide a 'sometimes it works, sometimes it doesn't' or a 'it is hard to reproduce' the risk is high, that I or Maxime will just declare something non-reproducible and move on (which almost happened here). We understand this is extra work and that you already put work into boiling down the issue, but it is in your own interest to be more precise with reproduction steps.
I am not 100% sure if we will consider this a bug, because I do not yet fully understand why this happens, but I have moved this into bugs for now. I also provide a workaround based on MoveHandle as already hinted at before.
Edit: Since this bug also affects objects provided by Cinema 4D, such as a cloner in linear mode or the field force object, this is now a Cinema 4D and not SDK bug anymore.
ObjectData.SetHandle code can lead to jitter issues when using HANDLECONSTRAINTTYPE_FREE.
import c4d
PLUGIN_ID = 1067013
PIP_HANDLE_EXAMPLE_POSITION = 1000
PIP_HANDLE_EXAMPLE_GROUP_STORAGE_GROUP = 2000
PIP_HANDLE_EXAMPLE_CONTAINER_INTERNAL_CONTAINER = 3000
class PIP_HandleExample(c4d.plugins.ObjectData):
def Init(self,op,isCloneInit):
self.InitAttr(op, c4d.Vector, c4d.PIP_HANDLE_EXAMPLE_POSITION)
if not isCloneInit:
op[c4d.PIP_HANDLE_EXAMPLE_POSITION] = c4d.Vector(0,0,0)
return True
def GetHandleCount(self, op):
return 1
def GetHandle(self, op, i, info):
info.position = op[c4d.PIP_HANDLE_EXAMPLE_POSITION]
info.type = c4d.HANDLECONSTRAINTTYPE_FREE
def SetHandle(self, op, i, p, info):
op[c4d.PIP_HANDLE_EXAMPLE_POSITION] = p
def Draw(self, op, drawpass, bd, bh):
if drawpass != c4d.DRAWPASS_HANDLES:
return c4d.DRAWRESULT_SKIP
bd.SetMatrix_Matrix(op, op.GetMg())
bd.SetPen(c4d.GetViewColor(c4d.VIEWCOLOR_HANDLES))
info = c4d.HandleInfo()
self.GetHandle(op, 0, info)
bd.DrawHandle(info.position, c4d.DRAWHANDLE_BIG, 0)
return c4d.DRAWRESULT_OK
if __name__ == "__main__":
if not c4d.plugins.RegisterObjectPlugin(
id=PLUGIN_ID,
str="PIP - Handle example",
g=PIP_HandleExample,
description="PIP_HandleExample",
icon=None,
info=c4d.OBJECT_GENERATOR):
raise RuntimeError("Failed to register PIP_HandleExample plugin.")
As already hinted at, you can override MoveHandle instead of SetHandle to implement your own handle movement logic. This way you have full control over how the mouse position is interpreted and can work around the jitter issue. See below for an example implementation.
Files: PIP_HandleExample.zip
# def SetHandle(self, op, i, p, info):
# """ Not required as we override MoveHandle.
# """
# op[c4d.PIP_HANDLE_EXAMPLE_POSITION] = p
def MoveHandle(self, op: c4d.BaseObject, undo: c4d.BaseObject, mouse_pos: c4d.Vector,
hit_id: int, qualifier: int, bd: c4d.BaseDraw) -> bool:
"""Called by Cinema 4D when the user interacts with a handle.
"""
# Get the mouse position in world space and then convert it to object space. The issue
# of this solution is that it will project the point down to one of the world planes (
# the plane to which the the #SetHandle code jitters). So, the axis which is perpendicular
# to the view plane will be zeroed out.
worldMousePos: c4d.Vector = bd.SW(mouse_pos)
localMousePos: c4d.Vector = ~op.GetMg() * worldMousePos
# To fix that, we must project the point into a plane we consider correct. You could do this
# brutishly by for example checking the projection of #bd and then just align the component
# of #worldMousePos that is perpendicular to that plane. You could also add some 'carry on'
# logic here which respects previous data, but I didn't do that.
projection: int = bd[c4d.BASEDRAW_DATA_PROJECTION]
if projection in (c4d.BASEDRAW_PROJECTION_TOP, c4d.BASEDRAW_PROJECTION_BOTTOM):
worldMousePos.y = op.GetMg().off.y
elif projection in (c4d.BASEDRAW_PROJECTION_FRONT, c4d.BASEDRAW_PROJECTION_BACK):
worldMousePos.z = op.GetMg().off.z
elif projection in (c4d.BASEDRAW_PROJECTION_LEFT, c4d.BASEDRAW_PROJECTION_RIGHT):
worldMousePos.x = op.GetMg().off.x
op[c4d.PIP_HANDLE_EXAMPLE_POSITION] = ~op.GetMg() * worldMousePos
return True
Cheers,
Ferdinand
Well, what I meant with feedback loop, is that you never constraint your data in any shape or form. All code examples and internal code work like this:
def GetHandle(self, op, i, info):
info.position = self.handle_position # or op[c4d.ID_INTERNAL_HANDLE_STORAGE]
info.type = c4d.HANDLECONSTRAINTTYPE_SOMETYPE
info.direction = Vector(...)
def SetHandle(self, op, i, p, info):
self.handle_position = Clamp(p)
I.e., here Clamp is called on p before it is fed back into handle_position. In my bezier handle example I used MoveHandle to project the current mouse pick point into the plane where I wanted to have it. You could also do the same in SetHandle. The viewport picking algorithm has no idea where you consider to be the 'correct' working plane. It does its best to guess, but you must still check and or help.
I haven't had a look at your code yet, will do next week (hopefully on Monday). It could be that there is a bug in the Python API, but that unbound nature of your code does strike me as incorrect.
Cheers,
Ferdinand
Hey @PixelsInProgress,
thank you for reaching out to us. That is not possible to answer like this, please provide an executable code example of what you are doing.
I guess the the reason for your problems are that you use the a bit niche constraint type HANDLECONSTRAINTTYPE_FREE and create a transform feedback loop when you feed your own user data into your handle without constraining that data. Keep in mind that handle code is called view-based. You might have to implement MoveHandle to correctly transform your point. But I have no idea what you are trying to do, so I am mostly guessing.
I have written a while ago this C++ code example which implements a camera dependent handle, which might be what you are trying to do here.
Cheers,
Ferdinand
No one might see this here, as notifications are currently broken, but there is an all new licensing manual and example in the SDK which should answer the questions asked here. Feel free to follow up, in case something remains unclear.
Dear development community,
On December the 3rd, 2025, Maxon Computer unveiled Maxon One 2026.1 in its December release. For an overview of the new features please refer to the news posting.
Alongside this release, existing APIs have been updated. For a detailed overview, please see the Cinema 4D C++ SDK, the Cinema 4D Python SDK, and ZBrush Python SDK change notes.
Head to our download section to grab the newest SDK downloads.
Happy rendering and coding,
the Maxon SDK Team
We are aware that the notifications are currently malfunctioning on the forum.
