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

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.

Hey @shiryuta,

thank you for reaching out to us. There is no public Redshift for Maya SDK. There is a semi-public Redshift Core SDK, but I doubt that this will help you much in this case, as you communicate directly with the Redshift Core in the GPU (and the access is also fairly limited). The Core SDK is also semi-public, i.e., we do not give access to everyone.

I have pinged the Redshift team about your case. Please have some patience, as some key people are there currently on vacation and will only return in early August. What I can already tell you now, is that we will not meet your request in all points. We will for example never publish internal headers, and we also never write code example for non-public APIs.

But that does not necessarily mean that there will not be a solution for your problem, only the Redshift for Maya team can clear up the details.

Cheers,
Ferdinand

I have pinned this as extra tooling is always welcome Thanks for sharing it !

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 @mp-grafix,

I am not really an expert on this subject, but the Alembic format does not provide a "root uv" concept as you somewhat imply. There are zero hits for these terms in the Alembic docs. groom_root_uv is a custom Alembic attribute that is supported (and defined) by Unreal (link). This link also explains how to compute this a bit ambiguous term. One might think a root uv would be the uv coordinate on some scalp mesh, but it is actually just the spherical projection of a hair root (that is at least how it is explained in the Unreal link). Unreal will also autogenerate this attribute for your when it does not exist.

The UV computation of our hair library can be found in c4d.modules.hair.HairLibrary.GetPolyPointST but this is per polygon. You can look at this example for how to use it on a whole mesh. But as far as I understand the Unreal docs, that is not what Unreal wants from you.

The official Alembic repo also contains the Python bindings, PyAlembic, with them you could add any metadata you want after Cinema exported the file. Hurdle number one is that the Alembic repo does not seem to provide binaries, i.e., they expect you to compile this yourself, which might be a hurdle to high for some users. Hurdle number two is to match the exact format Unreal expects. That is best solved in Unreal forums.

I am not very much into Unreal, but does our Cineware Unreal binding not solve this? I would say you have much better chances to be heard there, rather than us conforming with our Alembic export to the very specific custom attribute format Unreal expects.

Cheers,
Ferdinand

edit: Our Cineware for Unreal developer is currently on vaction until the middle of August. When you bump this topic then again, I am happy to ask him what his take on this is.

I am afraid there is not really good way to do this. You could expose the tags as BaseLink's in the parameters of your object, so that users can drag them, but that is also clunky and a also a bit 'yikes' to expose the cache internals like that.

Unless the object and selections are very complex, I would simply go by creating the selections in the cache, and then either documenting them in the docs, using short names such as C1 and C2 for cap one and cap two, or alternatively display a little static text at bottom of your node in the attribute manager which lists these names. This also worked a long time for Cinema itself like this, before we got seven years ago or so the proxy concept.

Hey @Dunhou,

No, you cannot create such tags from the public C++ or Python API. You can resolve existing tags via MSG_GETREALTAGDATA to their real underlying tag, but you cannot create new ones. At least we do not expose the internal interfaces we use for this.

You can print the data container of a proxy tag, and will find something like this:

Root (None , id = -1):
├── 2003 (DTYPE_REAL): 0.5
├── 2002 (DTYPE_LONG): 0
├── 2001 (CUSTOMDATATYPE_FIELDLIST): <c4d.FieldList object at 0x000002B6CF99C8C0>
├── 1011 (DTYPE_LONG): 0
├── 1000 (DTYPE_LONG): 5673
├── 1050449 (DTYPE_SUBCONTAINER , id = -1):
│   ├── 1 (DTYPE_LONG): 4001
│   └── 3 (DTYPE_LONG): 4101
└── 1041671 (DTYPE_VECTOR): Vector(1, 0.9, 0.4)

Where 1050449 is the ID for Tcacheproxytag and this sub-container then contains two fields which represent these two IDs:

We seem to have removed the old BaseLink approach we used before. And the code for resolving the 'name' (which as you can see is actually DTYPE_LONG) is not super trivial. If I would pull out this information for you and others, I would also have to maintain it, which you can see by the deprecation of the base-link, would be ongoing work. When you can make it work with the hinted at information, go for it. But this is a private interface for now, and I cannot reveal its details.

Cheers,
Ferdinand

Hey @mogh,

It depends a bit on what you mean with 'this'. Loading menu resources still does not seem to work in Python. I just tried, and while loading for example the main menu resource in your plugin just works fine, I cannot make it work with a locally defined plugin resource. Below you can see me loading M_EDITOR, i.e., the main menu resource, into the py-cmd_gui_resources_2024 example.

That is probably what I was referring to a bit fuzzily with 'I am sorry to inform you, that this is currently not possible. Because the procedures used by Cinema internally cannot be reflected to Python at the moment.' six years ago. I would have to sit down and debug this piece by piece to see what is going wrong with loading locally defined menu resources (or if I just made a mistake in the resource files). Resources in Cinema 4D are a bit different from plugin resources, and menu resources have never been publicly documented or demonstrated, neither in C++ nor in Python. So, this being broken is not impossible.

What you can do right now, is define a string menu item with an icon. But you will not be able to use this to create submenus with an icon as the original question was about. You can only create a string menu item with an icon, but not a submenu with an icon.

Cheers,
Ferdinand

import c4d

class IconMenuDialog(c4d.gui.GeDialog):
    """
    """
    def CreateLayout(self) -> bool:
        """Called by Cinema 4D when the GUI of the dialog is being built.
        """
        self.GroupBorderSpace(5, 5, 5, 5)

        # Add a menu called "Items".
        self.MenuSubBegin("Items")
        # And a submenu called "Objects".
        self.MenuSubBegin("Objects")
        # Here we use string menu items with the &i icon embed code. This only works for items and
        # not for submenus, therefore resources are currently the only way to define icons for submenus.
        self.MenuAddString(1000, f"Item 1&i{c4d.Ocube}&")
        self.MenuAddString(1001, f"Item 2&i{c4d.Osphere}&")
        self.MenuSubEnd()

        # Same thing, but here we use commands instead of string menu items. This will automatically 
        # add the icon and label of the command to the menu item. When invoked, this will execute also 
        # the command without us having to implement this ourself.
        self.MenuSubBegin("Splines")
        self.MenuAddCommand(c4d.Osplinecircle)
        self.MenuAddCommand(c4d.Osplinerectangle)
        self.MenuSubEnd()

        self.MenuSubEnd()
       
        return True

if __name__ == "__main__":
    dialog: IconMenuDialog = IconMenuDialog()
    dialog.Open(c4d.DLG_TYPE_ASYNC, defaultw=200, defaulth=100)

Hey @ThomasB,

my bad, I did miss that. The reason why you are still having problems is that in the scene data you load from your asset file, has generator and scene building flags set on its nodes that are visible in the object manager. When you then put them into the cache of your object, this leads to buggy/unintended behavior, as these flags should not appear in caches.

Cheers,
Ferdinand

Result

The initial state:

Collapsing your generator, it now correctly preserves the nested generators:

Collapsing once more the RS Light:

Code

This builds on the cleaned up code example I posted above. But effectively you only need ResetFlags and call it on your cache before you return it. But you should also remove the reference (self.container) to your own cache in your code example from your code, as this could cause some serious issues.

    def ResetFlags(self, node: c4d.BaseObject) -> None:
        """Resets selected flags in the local hierarchy of the given node.
        """
        def ResetFlags(node: c4d.BaseObject) -> None:
            node.DelBit(c4d.BIT_CONTROLOBJECT)
            node.DelBit(c4d.BIT_EDITOBJECT)

        ResetFlags(node)
        for child in mxutils.IterateTree(node, True):
            ResetFlags(child)

        return node

    def GetVirtualObjects(self, op: BaseObject, hh: object) -> BaseObject | None:
        """
        """
        # Return the cached object if it is not dirty, otherwise rebuild it.
        dirty: bool = op.CheckCache(hh) or op.IsDirty(c4d.DIRTYFLAGS_DATA | c4d.DIRTYFLAGS_ALL)
        if not dirty:
            return op.GetCache(hh)
        
        # Returning None in an ObjectData.GetVirtualObjects() call will tell Cinema that a memory error
        # occurred, and with that cause Cinema to stop calling/building the object. This is almost never
        # what we want, return a Null object instead.
        null: c4d.BaseObject | None = c4d.BaseObject(c4d.Onull)
        if not null:
            raise c4d.BaseObject(c4d.Onull)
        
        payload: c4d.BaseObject | None = self.GetAssetPayload()
        if payload:
            payload.InsertUnder(null)

        #  --- DEBUG ---

        # Some debug code I wrote to figure out what is going on here. I then quickly figured out 
        # that the parameters were okay, but that this light always malfunctioned. And that returning 
        # a fresh light worked fine. So, the culprit must be outside of the data container of the 
        # light but still inside the light object. I.e., BIT or NBIT flags, which then directly 
        # made me think of the BIT_CONTROLOBJECT and BIT_EDITOBJECT flags.
        #
        # WARNING: The code below is highly illegal code, as we insert objects into the active 
        # document from a non-main thread. This is just for debugging purposes, as I did not mind 
        # Cinema potentially crashing, and should never be done in production code.
        #
        # for child in mxutils.IterateTree(null, True):
        #     if child.GetType() == c4d.Orslight:
        #         print("-" * 100)
        #         print(mxutils.GetParameterTreeString(child))
        #         doc: c4d.documents.BaseDocument | None = c4d.documents.GetActiveDocument()
        #         if doc:
        #             doc.InsertObject(clone)
        #             c4d.EventAdd()

        #  --- FIX ---

        # Now we reset the build flags of all objects in the hierarchy. Not doing this caused 'Make 
        # Editable' to incorrectly collapse the cache of this object, going much deeper than it 
        # should. When you have this setup, i.e., a generator within the cache of another generator:
        #
        #   SomeGenerator (Obase)
        #   └── Cache
        #       └── Null (Onull)
        #           └── CubeGenerator (Obase) // Generator that is inside the cache of SomeGenerator
        #               └── Cache
        #                   └── Null (Onull)
        #                       └── PolygonObject (Opolygon)
        #
        # then the collapsed cache of SomeGenerator should be (important is the type in parentheses, 
        # not the name in front) as follows:
        #
        #   SomeGenerator (Onull)
        #   └── CubeGenerator (Obase)         // the uncollapsed CubeGenerator generator which was 
        #                                     // before inside the cache of SomeGenerator
        #
        # And not this.
        #
        #   SomeGenerator (Onull)
        #   └── CubeGenerator (Onull)
        #       └── PolygonObject (Opolygon)
        #
        # But the former is exactly what happened when we do not reset the build flags of all objects 
        # in the hierarchy. On top of that comes some bug / side effect of when you do this nested
        # collapsing that it seems to 'forget' half of the cache, 'PolygonObject (Opolygon)' in the
        # example above, or the converted standard light from the RS light in your case.
        self.ResetFlags(null)

        return null

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.

Hey @ThomasB,

while I understand the direction, your question is a bit ambiguous. What would you consider 'reliable and secure against spoofing'? This very much a question of perspective. Everything can be faked and altered with enough knowledge and determination when the data is local. The functions you mention are based on our licensing API (and are also a bit outdated, you should use the newer endpoints). This API is used by Maxon products itself to verify licenses and is considered secure enough for that purpose. However, nothing prevents a user from patching the Cinema binary so that these functions return whatever the user wants. But that is of course expert knowledge domain.

I would recommend using the relative new Licensing Manual which also explains how to identify the current product and how to find out how many licenses of a given type are available in a user account. In the video I also touch the subject of hardening for plugin licenses, the TLDR is: Do not over-do it, it is not worth the effort. Everything can be cracked.

Cheers,
Ferdinand

Hey @spedler,

I did give this a shot. I cannot reproduce this after even quite a few attempts, but one of my colleagues (Fritz) could. There is probably some undo code missing in the color chip dialog. I assume that was what you did, Steve, right? You set the color via the popup color chip dialog and not with the inline control? Fritz could reproduce this without your plugin. So, my hunch was right, your plugin is not the culprit.

Since I cannot fix what I cannot reproduce on my machine, I have created a bug ticket for this and sent it off to the owners of the COLOR control. The ticket is ITEM#652737 Parameters of type COLOR do not always correctly invoke UNDOs in descriptions.

Out of curiosity: Can you also reproduce this on your machine with a a builtin object, e.g., the Cube object? Fritz and I were both on macOS while testing. But this being OS-specific seems a bit unlikely.

Cheers,
Ferdinand

I have moved this topic into "bugs".

edit: As always with these things now I can reproduce it too

Hey @ThomasB,

so I did a clean writing of your plugin demo code in preparation to debug the output and I cannot reproduce the issue you report. For me the light works. There were some issues with your code, but none of them should cause the light to malfunction as your reported on LoadDocument. What you did there with self.container was a bit dicey and could have caused the issue but it seems somewhat unlikely.

I am today on my Mac, it seems quite unlikely that this is an OS related issue.

The object after pressing the button in your plugin:

And the object after collapsing it:

Cheers,
Ferdinand

from c4d import plugins, bitmaps, BaseObject, GeListNode

import c4d
import mxutils
import os


PLUGIN_ID: int = 1000200
PY_ADD_LIGHTS: int = 10000


class RedshiftLightsTest(plugins.ObjectData):
    """
    """
    HOUSE_PATH: str = os.path.join(os.path.dirname(__file__), "res", "models", "build_1.c4d")

    def __init__(self) -> None:
        """
        """
        self.SetOptimizeCache(True)
        self._asset_doc: c4d.documents.BaseDocument | None = None

        # No, never store a reference to what you return as your cache in GVO!
        # self.container = None

    def Init(self, op, isCloneInit: bool = False) -> bool:
        """
        """
        if not os.path.exists(self.HOUSE_PATH):
            raise FileNotFoundError(f"House model not found at {self.HOUSE_PATH}")
        
        # For cloning it would be better to copy over the document to avoid reloading it, but since
        # we do not implement NodeData.CopyTo() we will just reload it for now.
        self._asset_doc = mxutils.CheckType(
            c4d.documents.LoadDocument(self.HOUSE_PATH, c4d.SCENEFILTER_OBJECTS | c4d.SCENEFILTER_MATERIALS))

        return True
    
    def GetAssetPayload(self) -> c4d.BaseObject | None:
        """Returns a copy of the asset payload for the plugin.
        """
        if not isinstance(self._asset_doc, c4d.documents.BaseDocument):
            raise RuntimeError("Asset not loaded correctly.") # Should not happen, but just in case.
        
        root: c4d.BaseObject = self._asset_doc.GetFirstObject()
        if not root:
            raise RuntimeError("Asset document has no root object.")
        
        payload: c4d.BaseObject = root.GetDown()
        if not payload:
            raise RuntimeError("Asset document has no payload object.")
        
        return payload.GetClone()
    

    def GetVirtualObjects(self, op: BaseObject, hh: object) -> BaseObject | None:
        """
        """
        # Return the cached object if it is not dirty, otherwise rebuild it.
        dirty: bool = op.CheckCache(hh) or op.IsDirty(c4d.DIRTYFLAGS_DATA | c4d.DIRTYFLAGS_ALL)
        if not dirty:
            return op.GetCache(hh)
        
        # Returning None in an ObjectData.GetVirtualObjects() call will tell Cinema that a memory error
        # occurred, and with that cause Cinema to stop calling/building the object. This is almost never
        # what we want, return a Null object instead.
        null: c4d.BaseObject | None = c4d.BaseObject(c4d.Onull)
        if not null:
            return c4d.BaseObject(c4d.Onull)
        
        payload: c4d.BaseObject | None = self.GetAssetPayload()
        if payload:
            payload.InsertUnder(null)

        return null

    def Message(self, node: GeListNode, type: int, data: object) -> bool:
        """
        """
        if type == c4d.MSG_DESCRIPTION_COMMAND:
            if data["id"][0].id == PY_ADD_LIGHTS:
                self.ImportLights(node)
                return True

        return True
    
    def ImportLights(self, node: GeListNode) -> bool:
        """
        """
        if not isinstance(node, c4d.BaseObject) or not c4d.threading.GeIsMainThreadAndNoDrawThread():
            return False
        
        # This is a bit tedious but each of these calls can fail, and you cannot, or better, should
        # not just do chain calls such as GetDown().GetDown().GetNext().GetNext(). One could abstract
        # this away with a function such as Traverse(node, "DDNN") where D = Down, N = Next, but for 
        # this example I just did it manually.
        doc: c4d.documents.BaseDocument = node.GetDocument()
        if not doc:
            return False
        
        payload: c4d.BaseObject | None = self.GetAssetPayload()
        if not payload:
            return False
        
        down: c4d.BaseObject | None = payload.GetDown()
        if not down:
            return False
        
        item: c4d.BaseObject | None = down.GetNext()
        if not item:
            return False
        
        light: c4d.BaseObject | None = item.GetNext()
        if not light:
            return False
        
        clone: c4d.BaseObject | None = light.GetClone()
        if not clone:
            return False

        doc.InsertObject(clone)
        c4d.EventAdd()
        return True

if __name__ == "__main__":
    path, file = os.path.split(__file__)
    file = "icon.tif"
    new_path = os.path.join(path, "res", file)
    bitmap = bitmaps.BaseBitmap()
    bitmap.InitWith(new_path)
    plugins.RegisterObjectPlugin(id=PLUGIN_ID, str="redshift_lights_test", g=RedshiftLightsTest, description="redshift_lights_test", icon=bitmap,
                                 info=c4d.OBJECT_GENERATOR)

Hey @Anlv,

thank you for the confirmation and for the precise debug report.

Cheers,
Ferdinand

Hey, could you please try again

POST https://developers.maxon.net/forum/api/post/upload 403 (Forbidden)

That is the culprit. That is the data upload endpoint and something is not letting you even talk with it. Could be NodeBB misbehaving or some shenanigans by Cloudflare. I will see if I can find out more.

edit: now I see it too, this is some cloudflare misfire

Thanks for the info @Anlv

Hey Steve,

The toast messages of NodeBB are often not very helpful. What I meant was the JS console.

I do not even see the failed upload attempts in my server logs; which in combination with "Error. Something went wrong while parsing server response" sounds a bit like a severed session? I.e., the client is sending and server does not even consider looking at the data, resulting in a timeout?

E.g. this. Here it fails because I am using an unsupported filetype.

Just right click on the page, select inspect and then go to the console tab (which is usually the selected default). All modern browsers have this.

Cheers,
Ferdinand

PS: Please also expand the call stack like so:

Hey Steve,

Something with the forum uploads is buggy. For some people it works and for some it does not, it is rather mysterious. Could you share the console output of when the upload fails? I neither see something in the server logs nor can I reproduce this from my work machines or private machines. We will replace the forum soon, so I will not put too much work into this, but maybe there is a quick fix.

Regarding your issue: That sounds indeed like a bug, I will have a look. At first glance I do neither see anything in your code that stands out, such as dangerous NodeData::SetParameter code, nor are there issues like giving multiple elements the same ID in odiamond.h. We did touch the color picker a while ago (2025.X), so I would not rule out that we added some kind of bug.

Cheers,
Ferdinand

Hey,

sorry for the delay, I did read your reply. When I set the parameter in your scene the issue disappears. I did not check the LoadDocument/MergeDocument aspect yet. But I am 99.99% sure that there is no bug in Orslight in the conventional sense, it is just that the Orslight::GetVirtualObjects method is a bit of a fever dream.

The issue is Orslight::GetVirtualObjects returns a null object in some cases and a null with a light attached in other cases. LoadDocument/MergeDocument having a significant enough impact on the scene graph that causes Orslight::GetVirtualObjects to change its cache building behaviour from "null + light" to "null" sounds a bit unlikely but is not impossible (that would mean the scene importer is buggy).

I will try to have another look tomorrow or next week. When you want to help yourself, you could just do what I did: Diff the light from the loaded scene with a light your have already in the document which you know that works.

Cheers,
Ferdinand