Programmatically created Redshift Lights in an Object Plugin converts lights into Null-Objekts without an function after making Objekt-Plugin editable

ThomasB

Sorry first, I am not sure if this is the right place to post this. The Redshift forum was apparently not the right place.

I don't know if this behavior is intentional or unavoidable, but there is a problem with Redshift lights in my opinion.

Situation:
When you create a Redshift light and press 'C', it converts it into a standard Cinema 4D light—or, if generated programmatically, into a useless Null object.
It is programmatically impossible to generate a light (e.g., within an object plugin). When the object plugin is made "Editable"—for instance, to get the geometry—all Redshift lights are converted into Null objects and lose their functionality. Unlike the standard behavior, they aren't even converted into Cinema 4D lights.

Steps:

The plugin loads a virtual scene containing prepared scene elements and lights.
It returns in a container all the needed elements
When the plugin is made "Editable" to recieve the geometry, all Redshift lights are converted into Null objects.
️ result: Light functionality is lost.

Visual Examples:
Plugin creates a building for night view:

as long as the plugin is running lights are working
a light in code looks like this in a virtual temp_doc:
after converting the plugin into geometry (c to make it editable) it converts the lights into this:

Plugin Example:
Here is a trivial plugin example which basically loads a scene and returns an element with a light.
The scene structure of the document looks like that. The plugin returns the base element

After making the plugin editabel the light_flurescent is converted into a null object, and not even a Cinema 4D light remains.
Ideally, of course, the Redshift light would be fully preserved. That makes sense if you want to render with Redshift.

It uses a temporary Plugin ID
Download Plugin

I don't need to explain the code in detail here; an element is simply returned in the GetVirtualObjects method:

    def GetVirtualObjects(self, op: BaseObject, hh: object) -> Optional[BaseObject]:

        cdirty = False
        for child in op.GetChildren():

            cdirty = child.CheckCache(hh) or child.IsDirty(c4d.DIRTYFLAGS_DATA)
            if cdirty:

                break

        dirty = op.CheckCache(hh) or op.IsDirty(c4d.DIRTYFLAGS_DATA | c4d.DIRTYFLAGS_ALL) or cdirty
        if not dirty:
            return op.GetCache(hh)


        if self._temp_doc:
            container = c4d.BaseObject(c4d.Onull)

            base: c4d.BaseObject = self._temp_doc.GetFirstObject().GetDown().GetClone()
            base.InsertUnder(container)

            return container
        else:
            return None

Cheers
T.B.

ferdinand

Hello @ThomasB,

I am sorry that you had a bad experience in the RS forum. Can you show me the actual code where you add the RS light object in code? Because I see no Orslight in your snippet? Or when you load an asset, share that asset? When I do a quick test with a Python generator object, this works fine for me.

Cheers,
Ferdinand

PS: The plugin link you shared only contains an encrypted plugin (pypv) which not only makes it harder for me to get to the source code, I also cannot run such plugin on company hardware before I cracked it and can reasonably say that it does not contain dangerous code. Could you please share an unencrypted version?

ThomasB

@ferdinand

Okay, thank you Ferdinand for your reply.
Okay, that's strange—it works in your video.

I don't think the issue lies with my code; it simply loads a Cinema 4D scene in which the objects are already prepared.

But here is the unprotected plugin.
As previously mentioned, this is just a simple, simplified plugin to demonstrate that the problem behaves exactly as described above when using "Make Editable."
Download unprotected plugin

and the code if this helps out:

from typing import Optional

import c4d
from c4d import plugins, bitmaps, BaseObject
import os


PLUGIN_ID = 1000200


def load_house():

    house_path = os.path.join(path, "res", "models", "build_1.c4d")
    doc = None
    if os.path.exists(house_path):
        doc = c4d.documents.LoadDocument(house_path, c4d.SCENEFILTER_OBJECTS | c4d.SCENEFILTER_MATERIALS)

    return doc




class RedshiftLightsTest(plugins.ObjectData):

    def __init__(self):
        self.SetOptimizeCache(True)

        self._temp_doc = load_house()

    def Init(self, op, isCloneInit):


        return True

    

    def GetVirtualObjects(self, op: BaseObject, hh: object) -> Optional[BaseObject]:

        cdirty = False
        for child in op.GetChildren():

            cdirty = child.CheckCache(hh) or child.IsDirty(c4d.DIRTYFLAGS_DATA)
            if cdirty:

                break

        dirty = op.CheckCache(hh) or op.IsDirty(c4d.DIRTYFLAGS_DATA | c4d.DIRTYFLAGS_ALL) or cdirty
        if not dirty:
            return op.GetCache(hh)


        if self._temp_doc:
            container = c4d.BaseObject(c4d.Onull)

            base: c4d.BaseObject = self._temp_doc.GetFirstObject().GetDown().GetClone()
            base.InsertUnder(container)

            return container
        else:
            return None

    def GetDDescription(self, op, description, flags):
        if not description.LoadDescription(op.GetType()):

            return False

        single_id = description.GetSingleDescID()
        

        return False, (flags | c4d.DESCFLAGS_DESC_LOADED)            

   

    def GetDEnabling(self, op, did, t_data, flags, itemdesc):        

        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)

ferdinand

Hey @ThomasB,

I do not think that this is an API issue. I do not meant with that that I will not help you, as this still happens in the context of a plugin, I say this simply to classify the issue.

When I try to manually open your build_1.c4d file, it loads in 2026.2.0 but when I then press C on that light in question, I get exactly the output you report. And I cannot really explain why as this is just a normal rectangle shape area light (well, I sort of can, see below ).

The plot however thickens when I try to open the file with 2026.3.1:

This file seems to be somehow corrupted. After some poking around I manged to create this build_2.c4d which loads in 2026.3. But the light still did not work correctly. I then created a new RS light instance and copied over the whole data container via Get/SetData, which again resulted in a broken light. Only when I manually recreated the light by manually copying values, I ended up with a valid light. Which then also revealed that this light should have a much different light representation in the VP.

Your light:

The manual copy:

I.e., you seem to have there a fundamentally corrupted scene and especially light objects. The fact that I could reproduce this with a fresh light instance and a Get/SetData copy indicates this the data container of the light is corrupted. We could now start comparing the data containers of your light and the manually created one, to dive deeper, but I think I stop here for now. Did you programmatically modify this scene? Because your plugin only seems to load it. The question is now if you have more scenes like this. Otherwise I would just use my fixed scene (which also contains the fixed light) and move one.

Cheers,
Ferdinand

PS: Okay, now I see it, the actual scene in much more complex.

When you want to dig deeper yourself, a great tool to debug this would be mxutils.GetContainerTreeString. You can just dump both containers and then either visually compare them or use a diff tool. Or you use mxutils.GetParameterTreeString directly on the light objects.