Have the skeleton prim to root joint mapping available in the import chaser sdf to dag node map when the skeleton prim is not named the same as the root node and maya:generated = 1

[BeardedPlatypus]

Hi all,

I've come back with another feature request/bug report, which I'm hoping you could help me with. I've submitted it as a Feature Request as the request relates to some internal behavior and what we are doing might not be encouraged. Feel free to change it around to fit your internal issue structure though.

Thanks again for all your hard work!

Is your feature request related to a problem? Please describe

In our pipeline, we import characters with skeletons into Maya (USD being used primarily as a transfer format). These characters will always have a single common root joint. Because of this, and some of the weird behavior when dealing with the automatically generated root joint in Maya, we mark the skeleton as being generated by Maya (even if it isn't), to skip the generation of a root joint with the same name as the skeleton prim:

    def Skeleton "joint1" (
        prepend apiSchemas = ["SkelBindingAPI"]
        customData = {
            dictionary Maya = {
                bool generated = 1
            }
        }
    )
    ...

This mostly works fine, however we have run into the following problem:

if the skeleton prim name does not match the root joint name, the skeleton prim / joint pair will not be added to the sdftodag map available through the recently added function in import chasers

This means that any chaser relying on the skeleton prim / joint to be present in that mapping, won't work. I realize we are abusing some of the internals of maya-usd a bit as this situation most likely wouldn't occur, hence this being a feature request and not a bug report. I have added why this seems to happen based on the source code in the additional context section.

Describe the solution you'd like

In the most ideal situation, we would have a hook to customize the behavior of the initial root skeleton, with the current behavior being the default. This would allow us to handle our situation completely in our own business logic. I realize however that this might not be feasible in the short-term. So as a stop-gap measure, I would like for it that if a skeleton prim is imported with the maya:generated=1 custom property, the mapping to be available in the sdftodag map regardless of its name. This would make adapting the skeleton in a chaser step a lot easier.

Describe the alternatives you've considered

Currently, we have modified our code to not rely on the sdftodag mapping, but it has made our code more complex. We are considering of adding a pre-import step which renames either the skeleton prim or the root joint (depending on the complexity) if we need the mapping to include the skeleton or if all else fail, adjust the behavior in the source usd when exporting from the previous step in the pipeline.

Additional Context

If my understanding is correct the following happens:

1. The skeleton hierarchy is read starting from here with the selected line being where it chooses to generate a joint for that specific skeleton. Because of the generated = 1 in our usd file, we won't create a new joint and no info is added to the cache here.
2. It then goes on to create the joints here For each joint it will call the CreateNode with the sdfpath to the joint, which in turn will add these created nodes to their internal sdf to prim mapping, here
3. This all works as expected. The problem however is that inside the chasers we do not have access to the sdf to mobject map but to a sdf to dag node map which is created here and then set in the chasers. Rather than converting the sdf paths in the original cache, it will do a traversal through the stage and gather all the relevant corresponding dag nodes into the cache. Because it tries to find the skeleton path which has a different name than the root joint, it won't find any relevant corresponding node in the original cache. If the names of the root joint and the skeleton are the same, then it happens to be the same path as was added in the skeleton path, and it adds it to the mapping we use in the chasers

Not sure if this would warrant some additional logic to handle this case, or if it is not intended to be used like this (in which case being able to customize the skeleton root node behavior would be even more important)

[wallworm]

Thanks for your suggestion. We will discuss it internally.

[barbalt]

@BeardedPlatypus We're discussing this internally and we would like to know: Would a prim reader for either the Skeleton prim or SkelRoot prim solve this problem for you? If not, what is missing in that case?

We could use your work around to fix this specific scenario, but we would like to understand the root of the problem in order to have a better fix.

Thanks!