Gaffer.Metadata plug value registering issue

[Carlo Giesa]

Hi there!

I'm having issues with custom plug properties defined via Gaffer.Metadata.registerNode. I think that there is some conflict in the plug name resolution. Unfortunately, if I try to reproduce my issue in a simple example, all works as expected.

I have plugs on nodes that are named like following:

ufx_arg_stream_department

ufx_arg_stream_usage

...

ufx_info_stream_department

ufx_info_stream_usage

...

Those attributes are dynamic and they can be numerous. To organize them, I would like to have them shown in separate sections. So, I call Gaffer.Metadata.registerNode on a Gaffer.Node type with following code:

        "ufx_arg_stream_*": [
            "layout:section",
            "Arguments.Stream",
        ],
        "ufx_info_stream_*": [
            "layout:section",
            "Information.Stream",
        ],

In a simple example, this works, but with the rest of my pipeline code, my plugs end up in the default "Settings" section. If I hard-code each attribute name, it works.

Is there a way to figure out how Gaffer is actually resolving plug metadata based on generic names containing "*" characters? I would like to avoid hard-coding all possible plug names (even if I could do this in a dynamic way).

Thanks for any insight.

Greets,
Carlo

[John Haddon]

Hi Carlo!

Sounds very vexing. This wouldn't explain the difference between wildcard/non-wildcard registrations, but I often find the cause of metadata lookup failures is a not calling `registerRunTimeTyped()` for a custom Python node, or doing the equivalent for a custom C++ node. Is there any chance of that in this case?

There isn't really a way to introspect Gaffer's metadata resolution process. You might find it useful to peruse the code for it though, which you can find here : https://github.com/GafferHQ/gaffer/blob/main/src/Gaffer/Metadata.cpp#L963-L1072. The closest you could get to introspection would be to register unique wildcard/non-wildcard values against the node and each of the its base classes, to see which one wins.

Sorry to not have a more concrete answer at this point. What you're doing is meant to work though, so I'll be happy to fix it if we can isolate this to a problem on the Gaffer side.

Cheers...

John

--
You received this message because you are subscribed to the Google Groups "gaffer-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gaffer-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gaffer-dev/f3dff0b6-d2be-4c40-8af0-67d05f501d74n%40googlegroups.com.

[Carlo Giesa]

Hey John!

Thanks for your reply. It's no custom C++ node. Either standard Gaffer nodes or some custom nodes created in Python. I finally register Metadata on the 'lowest' node inheritence level instead of Gaffer.Node. That seems to do the trick.

Greets,

Carlo

To view this discussion visit https://groups.google.com/d/msgid/gaffer-dev/CAB8pVgKLBWXdmuavF6KJXVXw7-MODHhz%2BCaNRC%2BOTMuEXFSfLA%40mail.gmail.com.

[John Haddon]

Ah, so it sounds like maybe one of the types between your most-derived node and the Node base class had its own registration? Most-derived registrations win, so that would make sense.

Glad you got it working...

Cheers...

John

To view this discussion visit https://groups.google.com/d/msgid/gaffer-dev/CANHZvCMiMb-%2BX0q6wB_yMDMrg688vL7%2B0%2BC3sMvWec78NtGnmg%40mail.gmail.com.