According to the official document [www.sidefx.com], there are two ways to set up control shapes:

1. Set them up with Attach Joint Geo, then extract these information with APEX Configure Control. (before rigging)
2. Directly set them up with APEX Configure Control. (after rigging)

Surprisingly, I found this method to use Attach Joint Geo after rigging:



However, the syntax of the "Guide Sources" parameter is a bit mysterious.

* "Guide.skel Base.skel" - ok
* "/Guide.skel Base.skel" - ok
* "/Guide.skel /Base.skel" - not okay
* "Guide.skel /Base.skel" - not okay

The skel(s) are located at "/Guide.skel" and "/Base.skel" without doubt:


But I don't get when we need "/" and when we don't.

by just quickly looking at the logic inside for "get_guides", it seems to prepend additional "/" whenever the guide source split by "/" results in 2+ elements (even though that doesn't completely align with what you described so not sure if that's the issue, as this should break only the 3rd case)

I don't completely understand that logic and why it would have to be deferred to custom APEX graph rather than relying on Unpack Folder to already handle that robustly

Ah yes that case is simply not handled properly in the FindGraphElement subgraph in case of multi element entries. I can fix that. now the rule was that apex path patterns always require a / to indicate the current folder level even on top level folders. I am simply softening that rule for certain input parm cases without affecting the overall path pattern syntax. But I will bring the topic up if it rather makes sense to adjust the overall pattern.

esttri
I am simply softening that rule for certain input parm cases without affecting the overall path pattern syntax. But I will bring the topic up if it rather makes sense to adjust the overall pattern.

I guess this implementation makes sense when there is only one pattern, but it's causing counterintuitive result where multiple patterns like "/Guide.skel /Base.skel" doesn't work.

I'm still not sure why any intervention would be necessary, what's wrong with just following Unpack Folder pattern rules? as that's what's being used inside

tamte
I'm still not sure why any intervention would be necessary, what's wrong with just following Unpack Folder pattern rules? as that's what's being used inside

Yes I tend to agree. Consistency > convenience when the convenience is just saving one single character.

kodra

tamte
I'm still not sure why any intervention would be necessary, what's wrong with just following Unpack Folder pattern rules? as that's what's being used inside

Yes I tend to agree. Consistency > convenience when the convenience is just saving one single character.

maybe / used to be required or maybe I don't understand when it would be
but when I for example specify in Unpack Folder:
electra.char/Base.skel
I get the same result as when I do:
/electra.char/Base.skel

so to me it suggests that the Unpack Folder rules are already robust enough to handle that, I dont know what else it would assume the path to mean without /, since there is no pwd in Unpack Folder the path could have been relative to

so in this case its also convenient as well as it would be consistent if there was no extra logic in the APEX graph