administrators group

ferdinand

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

ferdinand

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.

ferdinand

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

ferdinand

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

ferdinand

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

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.

ferdinand

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.

ferdinand

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

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)

ferdinand

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

M	maxon
J	jana
I	i_mazlov
F	ferdinand
M	m_adam

administrators

Posts

Result

Code

Member List