Forums Solaris and Karma Recursive prim rename using RestructureSceneGraphLOP - 19.0

Recursive prim rename using RestructureSceneGraphLOP - 19.0

   2260   5   2
User Avatar
ben toogood
Member
31 posts
Joined: Feb. 2014
Offline
 
Hi all - I'm trying out the new RestructureSceneGraph to see if it will help strip namespaces from prim names.
The use-case is for bringing in content generated in other apps that like to prefix all their scene items with a namespace.

In my testing I have a scene formed of prims like:
/
|_  foo_one
           |_  foo_two
                      |_  foo_three
And I want to strip off the 'foo_' bit

If I set a restructure sg node's operation to 'Rename Primitives', specify a primitives filter of '*' (or '**'), and use an expression along the lines of 

old name: foo_*
new name: *

the top-level prim is renamed fine from 'foo_one' to 'one', but the child prims are left alone. If I chain up duplicates of the restructure node so the action is repeated they all get renamed (assuming I have enough copies of the node).
So my guess is that (in the single-node case) when the first rename operation is applied the child prims no longer match the original list of prims to operate on (as their full paths have changed) so are skipped.

Any suggestions for how to do a recursive rename? Am I just missing something on the restructure node, or does this need a different approach - possibly with a for-each? I'm having no luck with a loop and the usage is a little abstruse...

cheers

Attachments:
primRecursiveRename.hipnc (79.8 KB)
Screenshot 2021-11-01 114539.png (97.0 KB)

 Report
User Avatar
goldleaf
Staff
4159 posts
Joined: Sept. 2007
Offline
 
This is much trickier than it might appear, unfortunately. You are correct in that renaming the first primitive basically invalidates the prim pattern from continuing. Recursively renaming, or renaming the whole primitive path, will need to be handled specifically, but hasn't come up until now; and it gets much, much trickier when variants are involved. Can I ask you to log an RFE for this, please? ForEach LOP suffers from basically same issue. I tried to put together a workaround, but couldn't manage to do so.

In the mean time, another temporary workaround could be to pull the USD Prims into SOPs, and re-authoring the @path/@name attributes there. You'd then need to copy any attributes, transforms, etc... on the ancestor Xforms, but I think all the pieces are there to do that? Sorry we don't have a great solution right now, for fixing these exported prim paths.

But as for the issue you are tryin to solve, there should be a way to turn off the prefixing of scene paths in the program you're exporting from, I'd expect? It's a workflow adjustment (especially for workflows/artists/departments used to treating hierarchy as a UI), but since the prim path/hierarchy in USD is the UUID, exports should ideally be setup to export to the right prim paths. Otherwise you have to do a bunch of prim renaming/mangling, which is always prone to issues, especially with VariantSpecs in the mix. I can't remember if Blender even has this problem, but I'm positive there are ways to fix the namespace getting prefixed, coming out of Maya? Those are the two most common non-Solaris/public sources of USD data that I'm aware of...
I'm o.d.d.
 Report
User Avatar
Andy_23
Member
918 posts
Joined: March 2014
Offline
 
We, too, are in this camp. Our animatic artist and animators lack the ability to structure and name his objects within scenes thoughtfully. Therefore, the incoming Alembic from Softimage is quite a mess to serve as a base.

We preprocess and restructure everything in Solaris, which is quite involved. So the more tools the better.

Thank you.
 Report
User Avatar
daviddeacon
Member
161 posts
Joined: Jan. 2019
Offline
 
Andy_23
Our animatic artist and animators lack the ability to structure and name his objects within scenes thoughtfully

Haha, so it's not just our animators...
 Report
User Avatar
ben toogood
Member
31 posts
Joined: Feb. 2014
Offline
 
Thanks for taking a look Chris.

Appreciate that it's a tricky one to get around. We're just exploring options right now, and as a temporary measure stacking up a chain of 'renames' will be fine during testing.

You're right that it would make more sense to fix this at the source, and Maya does have the option to strip the namespace on export - but it's not super flexible right now. One specific conundrum we've come up against is with multiple references of the same asset (under different namespaces) - attempting to export them individually with stripped namespaces results in an error

# Error: RuntimeError: Multiple dag nodes map to the same prim path after stripping namespaces

It's something we'll take up with the Autodesk devs, as in USD land there are no prim conflicts in this case but I can see the complexity from their end.

A workaround requires each referenced asset to be placed under its own parent group and then that group to be exported.


But I'm with Andy in terms of an instinct to not depend on scenes being carefully structured on the Maya end. As you said Chris, artists are used to using hierarchies as a visual interface for organising their work. If all the vital components are safely referenced and contained within a namespace, and we are able to append our target hierarchy on export I think we'd be in a good place. However, I'm not sure the Maya USD tools are quite there yet. Fingers crossed.
 Report
User Avatar
lloydwood
Member
104 posts
Joined: Nov. 2007
Offline
 
goldleaf
This is much trickier than it might appear, unfortunately. You are correct in that renaming the first primitive basically invalidates the prim pattern from continuing. Recursively renaming, or renaming the whole primitive path, will need to be handled specifically, but hasn't come up until now; and it gets much, much trickier when variants are involved. Can I ask you to log an RFE for this, please? ForEach LOP suffers from basically same issue. I tried to put together a workaround, but couldn't manage to do so.

In the mean time, another temporary workaround could be to pull the USD Prims into SOPs, and re-authoring the @path/@name attributes there. You'd then need to copy any attributes, transforms, etc... on the ancestor Xforms, but I think all the pieces are there to do that? Sorry we don't have a great solution right now, for fixing these exported prim paths.

But as for the issue you are tryin to solve, there should be a way to turn off the prefixing of scene paths in the program you're exporting from, I'd expect? It's a workflow adjustment (especially for workflows/artists/departments used to treating hierarchy as a UI), but since the prim path/hierarchy in USD is the UUID, exports should ideally be setup to export to the right prim paths. Otherwise you have to do a bunch of prim renaming/mangling, which is always prone to issues, especially with VariantSpecs in the mix. I can't remember if Blender even has this problem, but I'm positive there are ways to fix the namespace getting prefixed, coming out of Maya? Those are the two most common non-Solaris/public sources of USD data that I'm aware of...

I also running into this issue and am trying out the workaround. I renamed the prims but I end up with a new set of prims and the old set still there. I'm thinking that's correct (can't delete stuff in USD world) but not sure? I can always clean the old prims up with a restructure. The part I'm not sure about is how to copy the transforms from the old prims to the new ones?
 Report
  • Quick Links