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: Python OCIO Example: open_color_io_2025_2.py Python OCIO Example: py-ocio_node_2025.pyp C++ Manual: Color Management C++ Manual: OCIO 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)

@ferdinand Thanks for your great examples! Very helpful!

Hey Jacob, Thank you for the added data. First of all, I have invited you to the forum to end this middle man communication, which is a bit odd. The pyz file is part of python ... I am aware of what pyz is, I just pointed this out because I of course looked inside your package and found all the py_armor obfuscated code and the injected binaries in there. So, I pointed out that this is bit more than just "packaged in a pyz file for ease of distribution [...]" as Lasse/you put it, the goal is here clearly obfuscation. Which is also relevant for support, as it limits what you and I can see (without getting hacky). My finding with the 10mb file freeze comes from my trial and error ... mean[t] when you run a script from Extensions -> User Scripts. Your code also freezes when you load it as a Script Manager script. That is what I did with the last package from Lasse, and now also yours. The code in your script is again wrong, which is why it won't freeze until you fix it. This is the code I found: [image: 1760086817339-2bd4290e-78b2-43d4-936d-1e2a7eaf366b-image.png] And I fixed it then to this. When I ran it then, Cinema 4D froze for two minutes or so, after that it opened a myriad of dialogs to then terminate into two crash dialogs (it was pure luck that I let it run for so long, Lasses previous version might have acted similar, but there I killed the C4D process, as soon as I saw the 'beach ball of death' cursor on MacOS). [image: 1760086755748-69fcb5da-ac49-477e-8f70-9daeb1daa1aa-image.png] Please read my answer below carefully, as I already pointed out most of this in my previous posting. I would STRONGLY suggest debugging this without obfuscation. Maxon also cannot debug larger sections of code or test further packages for you. I understand that obfuscation might not be your choice, but it will make your life harder in debugging this, as you always fly blind. We of course still will provide support, but you have to provide more than "it does not work/crashes/freezes, please help us", especially when this is not code tied to our APIs. Attach a debugger from the Script Manager and see why your code crashes/freezes (see link in last posting when unsure how to do this). But you need an un-obfuscated code base for this to make any sense. Defer your loading to a later point, e.g., C4DPL_PROGRAM_STARTED, when you have issues in the direct plugin registration context. In that case you would always register your plugin, but then only execute it when the your own license check succeeded. But you absolutely cannot ship a plugin which freezes Cinema 4D for multiple minutes on startup or when invoking your plugin because your licensing takes so long. When we see this in the wild, we will have to blacklist your plugin IDs, as this damages the brand Cinema 4D. Please use threading then to not block the main thread with your long running code. What I did not notice before is that you apparently try to open multiple dialogs (for me it opened multiple dialogs when I ran the script). The GUI and many other systems are not yet available when Cinema 4D is still booting, e.g., in the splash screen. You can expect all systems to be up and running when C4DPL_STARTACTIVITY is emitted, but it is better to wait for C4DPL_PROGRAM_STARTED for long running tasks (i.e., the two events I tested in my previous posting). Please also keep in mind that Cinema 4D has its own anti-piracy measures. Python plugins are sort of special in that they work slightly different than native C++ plugin modules (the Python C++ module shipped by Maxon sort of acts as a surrogate for Python plugins in the module registration phase). But Cinema 4D won't allow plugin threads to start their own processes at this point (which you might be trying to do with your injected binaries), and threading should also be avoided at this point, as the job system of Cinema 4D might be still booting. What you are meant to do in PluginStart (or the __main__ context of a pyp file), is register your plugins. You can run some quick logic there, but you are certainly not meant to start communicating with servers and opening GUIs there. You can read here a bit more about this from a C++ system perspective. I would recommend to do your license check in the background in its own thread once C4DPL_PROGRAM_STARTED has been emitted (so that you can also open dialogs to signal errors). An alternative would be to do it when the user clicks the button of your command. But you should also here put it into its own thread, so that it does not block everything else. Cheers, Ferdinand

Hey @lasselauch, We are not able to reproduce this crash on an Intel, M1, or M3 MacBook with 2024.4.0. Please provide and submit a crash report when this is still a problem for you. I would also recommend reinstalling Cinema 4D to rule out that your installation was damaged. Cheers, Ferdinand

Hello @lasselauch, without further questions or replies, we will consider this topic as solved by Monday, the 30th and flag it accordingly. Thank you for your understanding, Ferdinand

Hi @lasselauch, thank you for reaching out to us and I am sorry to hear about your problems regarding targeting multiple localizations. I am struggling however a bit to understand what is exactly going wrong for you. You tell us that the plugin "isn't behaving correctly in R23" which is a bit too broad for us to come up with an reliable answer. I am also sorry for having to point out that your proposed way of getting hold of the implementation of the plugin via aescripts.com - with the proprietary downloader you provide there to distribute your products - is a bit much for us. I would suggest that you share the relevant code more directly here, or, in case you cannot do this, share it via sdk_support(at)maxon.net confidentially with us (please note the Forum Guidelines regarding Support Procedures: Confidential Data, specifically regarding NDAs, in case they would apply here). For your actual problem: It is really hard to give any advice without knowing what exactly is going wrong. I assume you have a Japanese localization in your resource folder and it does not work for the user? I would check: If the folder has the correct ISO 639-1 language code, for Japanese it should be ja-JP, so for the strings folder it should be strings_ja-JP for example. Not providing a matching language code for a running Cinema 4D instance should result in Cinema automatically falling back to en-US. Make sure that the Japanese translation files are all UTF-8. While the manuals do not state that restriction, it could be something that is tripping Cinema up, especially considering that languages with large character sets, like for example Japanese, are not fully represented in UTF-8 due to the limited namespace. I would however had to ask our translators how they handle Japanese if this is the culprit. But in the end these are mostly shots into the dark for me, due to not knowing what is exactly going wrong. So I would also had to ask you to describe more precisely what is going wrong. Cheers, Ferdinand

Hi @lasselauch, we talked about your problem this morning. There are two ways of looking at your question: You are interested in the event of a closing document (i.e. present progressive) and you want to react to that event by making some changes before this process is finalized (i.e. the document closed). As already stated yesterday by me, there is currently no way to do that in a GeDialog. You will need some kind of node for that. It is also noteworthy that currently CommandData is bugged in this regard in Python. As @mp5gosu already pointed out, MessageData is a really good way to go, unless you do not have already something like TagData plugin where you could squeeze in that functionality. You are interested in the state of the loaded documents list, i.e. if a document has closed (past tense), but not exactly when it happens. This is possible in a dialog. You already provided your own answer here (thanks for making it visible to everyone). The basic idea is just to build some hashmap/list to compare against what Cinema considers to be loaded documents. As an added note, you might want to look at GeDialog.Timer, which will let you execute things in fixed intervals, in order to get closer to the point of when something happened. This won't be to much of a performance strain if implemented carefully. Cheers, Ferdinand

Hi, I understand that this thread has not yet come to a final conclusion, but without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

@lasselauch said in developers.maxon.net – Offline?: Had one aswell.... [image: 1606130431107-explorer_2020-11-23_12-19-58.png] a rather old one... ...haha. Slightly outdated. LOL.

Python plugins do not work reliably in R23 on OSX 10.13.6. The C4D minimum spec is for 10.14.6 as Riccardo mentioned. And even if you try to debug a plugin on 10.13.6 what you will notice is that many calls (such as print) don't even work on this OS. So you can't even write anything out to the console to see what the problem might be. No amount of re-installing C4D will help you at all. You just have to let your customers know that the minimum spec for R23 is 10.14.6 and not guarantee any support for anything below that spec.

Hi, without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly. Cheers, Ferdinand

Hey guys, just wanted to let you know, that I've cracked the case in the meantime. Here are my findings: def convert_matrix_left_to_right(m): # http://www.techart3d.com/2016/02/convert-left-handed-to-right-handed-coordinates/ # m = op.GetMg() new_m = c4d.Matrix( m.off, m.v1*-1, m.v2, m.v3) return new_m def rotate_y_axis_180(): # Construct your own matrix based on rotation of axis # https://www.mathworks.com/help/phased/ref/roty.html x = c4d.Vector(-1, 0, 0) y = c4d.Vector(0, 1, 0) z = c4d.Vector(0, 0, -1) off = c4d.Vector(0, 0, 0) return c4d.Matrix(off, x, y, z) def GetGlobalRotation(obj): m = obj.GetMg() new_m = rotate_y_axis_180() * convert_matrix_left_to_right(m) return c4d.utils.MatrixToHPB(new_m, order=c4d.ROTATIONORDER_XYZGLOBAL) Indeed you have to convert from a left-handed (c4d) (hpb) to a right-handed (houdini) (xyz) coordinate system... plus I've found that you need to add 180° to the y axis, so I constructed a matrix in rotate_y_axis_180 that I can multiply to my converted matrix. Hope it helps someone... Thank you guys for your input! Have a great weekend and stay safe! Cheers, Lasse

Hi @lasselauch sorry for the late reply, I asked about the developer responsible for it. On Windows we use the WebView control of the last iteration of iexplore MS shipped for 8.1 - Internet Explorer 11 (user-agent ID: "Trident"). It supports >most< things other modern browsers do, but sadly not everything... Especially the JS support has become a problem since IE11 is missing parts of the ECMA 6 standard and needs 'polyfills' to emulate those. Many JS frameworks / libraries don't offer IE11 compatibility and instead rely on the developer to add those polyfills themselves. One of the improvements IE11 received back then was the developer console+tools so the user could use those to track > down the JS issues and resolve them." I also forwarded your request about the ability to disable Javascript, but so far nothing planned atm, so the only workaround I see is either fix your javascript framework (maybe a huge task) or you can disable your javascript based on the user agent and if it's an IE11. Hope this help, Cheers, Maxime.

why do you think C4D has any special handling for emojis? The font rendering is OS dependent, so any kind of text - including emoji codepoints - is drawn by the underlying operating system routines. Anything else would mean a ridiculous effort by Maxon to replicate font behavior. (I do not know how Windows internally handles emojis, I doubt that every available font has all these characters so most likely certain codepoints are mapped to common glyphs regardless of the font... but that is not a C4D question anyway.)

Hi with the latest update of Cinema 4D (R24 SP1), BasePlugin.GetFilename now also return the file extension in Python. Cheers, Maxime.

@mp5gosu Whooop! Thanks, Robert! You have to return a tuple so return (c4d.NOTOK, False) does the trick for me. Thank you!!! Cheers, Lasse

Hi, @lasselauch as a rule of thumb with Python2.7 always store data as a Unicode string. Control your IO which means, for each, Input make sure you know the encoding in all cases by always calling .decode('utf-8') so you are sure to store a Unicode value and get an error if something went wrong at a loading time. Then output the content according to your need some need ASCII, some can work with unicode, but do the conversion on the fly, don't touch you stored Unicode data. For the francophone people, there is this fabulous article about unicode Encoding in Python for English I guess the best I found on this topic is A Guide to Unicode, UTF-8, and Strings in Python. Cheers, Maxime.

Okay! Thanks for the info @m_adam ! Oh, and on macOS it is General - Text - Flag Edit Saved [image: 1586176239242-bildschirmfoto-2020-04-06-um-14.28.13.png] ¯_(ツ)_/¯ Cheers, Lasse

Hi @lasselauch there is actually no plan to update ResEdit. There is the R20 Resource Editor but for the moment it's only for Node stuff. Cheers, Maxime.

Thanks @m_adam for the insights! Works like a charm!! Cheers, Lasse