You likely have to call UpdateOcioColorSpaces, just follow the example. There is btw no guarantee at all that DOCUMENT_COLOR_MANAGEMENT entails a render space of ACEScg. That is just the default, the user could have changed that. I am also not sure what all that RDATA_IMAGECOLORPROFILE code is meant to do. It depends a bit on what your plugin does and what self.IsForceLinear is meant to express. Only so much: An OCIO document does not necessarily entail a bitmap with a non-linear color profile, and OCIO also does not mean that the bitmap has to be 32bit. You are however missing UNDOTYPE_PRIVATE_DOCUMENTDATA undo management for setting the color management.

@ferdinand Okay, I will handle the plugins and files at an appropriate time.Thanks reply

Hi, @ferdinand and @Anlv this is most awesome! All way beyond my capablities so thanks a lot for the scripts!

@ferdinand Thanks for your detailed explanation. Although the precision conversion leading to value changes is not an error, it is indeed not what we want in terms of the results. For example, when dealing with the weight of some points, using SetWeightMap() will update the weights of other points, resulting in numerical changes. Only using SetWeight() can at least ensure that the weights of unoperated points do not undergo numerical changes (but using SetWeight() must tolerate the print warnings outputted by the console)

@ferdinand Thanks for your detailed explanation and the implementation of the sorting function. It's very helpful！

Thanks Anlv It looks like its adding the emitter into a null is what's causing it. Fixed with deferred CallCommand(1062577) (no sub-id (1067510) silently no-ops). Emitter fields greys if the emitter/group are parented under the setup null or generator. Sibling placement below plugin object + rename works fine.

@ferdinand Yes, thanks, that indirect answer is enough for me. I was mainly wondering whether a check performed on both the client and the server is robust enough, or if it could be bypassed using Python, for instance. I’m well aware that it can be cracked somehow. I’m also already using ExportLicenses() for my node-locking system in combination. Thanks a lot for your help.

I tried with a Cube where the only way to change colour is to use the display colour in the basic tab. At first sight this doesn't cause the problem, but in fact it does. Yes, that was what I meant. Thanks for confirming. The issue likely already has vanished in the current alpha, because there I could not reproduce it. But in 2026.3.2 I can. What is a bit odd is that no one seems to have touched the relevant code in the last months. But that is something for the GUI team to figure out.

This is not common knowledge, otherwise I would have spotted that earlier. So, you are not really expected to know this as a third party dev. You can look at the geometry_caches_s26.py example and there at this line, under [2] I mention that the cache of that object is muted. But that is of course only very indirect information and not enough to deduce this. I think we also talked about it a couple of times on the forum. The flag BIT_CONTROLOBJECT is set on input objects of generators, e.g., the to be extruded spline of an Extrude object, the profile and rail spine of a Loft object, the to be cloned cube and sphere objects of a MoGraph cloner, etc. As shown in the caching example, Cinema will mute the caches of input objects. To be very formal, they are actually built but then again deleted. BIT_CONTROLOBJECT marks such input objects. Your light in that scene should not have that flag, as it is not the input for some generator. But it somehow got it anyway, there is probably somewhere a bug. For normal scene evaluation that bug is also not really a problem (because as you saw from your own test, the light still converted correctly when you inserted it on its own outside of caches). The problems start when that irregularly as BIT_CONTROLOBJECT marked object is part of a cache. 'Make Editable' then incorrectly collapses the cache. Not only does it not stop at nested generators which are incorrectly marked like this, it also seems to apply the cache muting logic for input objects (resulting in the empty null object instead of the content of the cache of the collapsed generator). I already told the relevant devs that I consider this borderline buggy but they do not seem very inclined to do anything about this. What is effectively missing somewhere in cache resolvement is the evaluation if the flag BIT_CONTROLOBJECT 'makes sense on an object'. That is of not so easy to do, as generator - input object relations can be quite complex in Cinema. Which is probably also why the modelling team does not want to touch this. Cheers, Ferdinand

This will be fixed in the next upcoming hotfix.

Hey, good news, this is fixed in the upcoming hotfix (2026.3.2).

@ThomasB That is not a misunderstanding. I am aware that MRDs can only see their own tickets. But we still needed that crash reported, so I did it. I would have done the same if you would not have been an MRD. I usually mention ticket IDs here so that I can come back and close bugs. As you might have noticed, I have moved this into the Bugs forum. You do not have to do anything regarding that ticket, it it inaccessible for non-Maxonians. But we are still very much interested in a version of your plugin or a workflow which caused the crash. Otherwise we will not be able to reproduce and fix the issue. When you cannot provide it, this is also not a biggie (please do not waste time on this), then we have at least documented that there is somewhere a problem with audio tracks and how they handle memory while post-processing audio; in case we run into the same issue in the future in another context. Cheers, Ferdinand To share plugins with us, you can either use a chat on backstage or send us a mail to sdk_support(at)maxon(dot)net. There is a good chance that when you use a binary data attachment in a mail, that our mail system will filter out that attachment. When you use backstage (and upload the plugin there in a chat) that data would be permanently in the assets of that forum. When you just give us a link, we will delete your data once we do not need them anymore for debugging.

Hey @ferdinand , Sorry I forgot click Submit button well, that is the info I need, I use same tech to get icons for CMD, and now waiting for svg part in the future. Cheers~ DunHou

I started to work last Friday on a BaseBitmap.InitWithVectorImage. It will for sure not make it into the next release of Cinema 4D, as we are too close to that, and I cannot make any promises when or if it will arrive. But I see value in this especially since I realized that you cannot even really use this in C++, as VectorImageInterface requires access to some internal components to be rasterized.

@ferdinand thanks so much, problem solved!

I do not think that DRAW_ALPHA_FROM_IMAGE should not work. I just picked DRAW_ALPHA_NORMAL because it is the "most default one" out of the DRAW_ALPHA flags. I will have a look later. But you can for now probably just use DRAW_ALPHA_NORMAL.

You very likely have not unpacked your resources. The resource folder found in an installation only contains a part of the application resources (we are doing this since release 2023 if I remember correctly). A good portion of the resources sits inside resource.zip for performance reasons and is unpacked on demand. You can just unpack the resource.zip into you resource folder without an performance or stability issues. [image: 1779175199591-b8e8db94-ae20-42b4-9a5d-e92ac928e89d-image.png] You as an MRD can also look at the Bugslife client, as it is probably the better example, as it uses more features of the quick tab GUI. But my answer above was targeted at a general audience who can see the resources for Bugslife but not Bugslife itself, and it therefore is not a good example for them. Just grep the resource folder as I did in my screen for files that match the path dialogs/*.res (i.e., are res files for dialogs) and contain the word QUICKTAB. Cheers, Ferdinand

Another small tip: you can simply use a single <br> for line breaks — there’s no need to use <b> or </b>. Also, just like in the script example, scripts can support localized language strings as well: """ Name-US:Example Name-CN:示例 Description-US:Example line 1.<br>Example line 2.<br>Example line 3. Description-CN:示例第 1 行。<br>示例第 2 行。<br>示例第 3 行。 """