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

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

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

This is how I’ve implemented it at the moment, although users can’t drag and drop selection tags in the same way as with C4D’s built-in generator. Hope there are plans to expose the proxy tags. Thanks for tour time!

There seems to be some solution, please stay tuned until the RS team has sorted out things. I will then update this topic.

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

What I meant was to use the Cineware Unreal bindings, but I am not sure if they support it. Going the export route is a big backwards when Cinema has specific bindings. https://www.maxon.net/en/cineware I will give the Unreal dev a bump when I see him again.

Yes I wanted submenu with Icon, thanks for Up to Date clarification.

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

Hey @Kantronin, you might want to look at geometry_polgyon_edges_2024.0.py, it should answer all your questions. The TLDR is: full-edge maps as you hint at in your posting do exist in Cinema via helper functions, but they are often also not very useful. Internally, Cinema is operating as any other DCC application with the concept of what is often called a "half-edge" data structure. So, when you have the two polygons A and B: a---b---e | A | B | d---c---f Which share an edge over the vertices b and c, this is actually two edges and not one, due to how normals work. For both polygons to have a normal facing in the same direction, they must have opposite winding orders, which means that the edge b-c is actually two edges: b->c and c->b. So, A could for example index the edge as bc, and B as cb. The example goes into more detail with this. Cheers, Ferdinand

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.

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