Hi!

I have these primitives that I need to unpack in a sop modify. I want to unpack all of the primitives except for the ones under tempGeo.



(The tempGeo is the hair):



So, I figured I'd construct a sop modify that selects all the primitives except for those under tempGeo:

/scene/anim/letty/* - /scene/anim/letty/geo/tempGeo/*
However, I found that inside the SOP Modify, the hair is still unpacked:


If I explicitly select all the primitives except for tempGeo (such that it's a really long pattern like this: /scene/anim/letty/geo/catchLight_L /scene/anim/letty/geo/catchLight_R /scene/anim/letty/geo/cornea /scene/anim/letty/geo/eyelashes /scene/anim/letty/geo/eyesetc...), it does work:


However, I want to make the expression flexible such that if more primitives are added, they are still unpacked, but the tempGeo ones are not. What am I missing?

I've also tried exclusions in collections, but with the same results.

Thanks!
Anson

the pattern
is matching just primitives that single level
so if you try to exclude
there is nothing to exclude from as that deeper level primitives weren't matched

if all geo you are interested is under /scene/anim/letty/geo you can use

however if there are other primitives in ../letty, parallel to /geo you are bringin in you can try this
notice there is no / in tempGeo** and thats so that it excludes tempGeo Xform itself and not just its children


Things will start to get complicated if you are using Traversal options though

Hi! Thank you so much

Okay, this one does work like I expect, which is great!

tamte

/scene/anim/letty/geo/* - /scene/anim/letty/geo/tempGeo

In our application, we will have some geo that is parallel to /geo (well, actually we are hoping to do this for the entire anim primitive, so we'll have geo that's parallel to /letty), and the following expression didn't seem to do the trick for some reason.

tamte

/scene/anim/letty/** - /scene/anim/letty/geo/tempGeo**

Any thoughts on that?

Thanks so much for the help and the explanations, that makes a lot of sense.

/scene/anim/letty/** will bring in /scene/anim/letty/geo. Which means that not only will all of tempGeo be brought in as part of the "geo" packed prim, but every other piece of geometry under /geo will be brought in twice (once as part of the "geo" packed prim, and again as "geo/eyes", "geo/frames", etc. Generally speaking using "**" in LOP Import patterns is going to make things difficult to control because the matching can happen at many levels of the hierarchy, and matching a higher level prim will effectively bring in all lower level prims, and you'll almost definitely end up doubling up on geometry.

One way out of this (if you can't find a nice clean pattern that avoids using "**") is to use the "%noancestors" auto-collection to modify your pattern. I think "%noancestors(/scene/anim/letty/** - /scene/anim/letty/geo/tempGeo**)" might give you what you want by only returning "leaf" primitives matching that overly-inclusive pattern. But I may also be wrong about this This pattern stuff can be very difficult to reason about in your head without making mistakes. I should say "difficult to reason about in MY head". I don't mean to cast aspersions on anyone else.

Ah, thanks for helping explain that. I appreciate it!

Why does specifying pattern bring in duplicates?
What is the reasoning behind it being allowed and when is it useful?

It's clear that in case of traversing there will be child primitives of selected ones brought it, but I would expect there to be a safeguard against bringing in duplicates

Perhaps you want to apply transforms to various levels of the scene graph tree within a single SOP Modify LOP? Also, if we were to provide safeguards, should we exclude duplicates by taking the prims as high up the hierarchy or as low down the hierarchy as possible? Using the "noancestors" and "nodescendants" auto-collections lets the user decide exactly how duplicates should be avoided.

That said, I wouldn't be against a menu on the LOP Import SOP that gives options like "Match Primitive Pattern Exactly"/"Remove Duplicate Ancestor Prims"/"Remove Duplicate Descendant Prims" if someone thinks that's worth an RFE.

mtucker
Perhaps you want to apply transforms to various levels of the scene graph tree within a single SOP Modify LOP?

I don't quite follow how this would benefit from having the same primitive brought into SOPs multiple times

I understand that the Pattern + traversal will likely end up including the same primitives multiple times as one prim can be descendant of many parent prims included in the pattern, etc
but I would expect duplicates to be filtered out as they are essentially the same prim with the same path