Hi, I was messing around with the Magic Market Scene from
https://www.sidefx.com/contentlibrary/market-scene/ [www.sidefx.com] in H18.5.462

I just brought the full scene onto the stage with a default Sublayer node.
/stage/Sublayer(File = /path/to/LOPS_DEMO_FILES/Library/Layout/FullScene.usd) -> NULL|TO_SOPs
Everything looks to check out in the Scene Graph View, nice Assembly/Component Kind.

Now when I pulled this scene into Sops with a default LOPImport
/obj/geo/LOPImport(LopPath = /stage/TO_SOPs, Primitives=*)
and 'Unpack USD to Polygons' on the Table, I happened to notice that I had 5 overlapping sets of table by repeatedly blasting over one of the table faces.

So I started messing around with the various traversal options, and while the paths change a bit, I still seem to get additional packed geo for every entry in the path. This seems odd to me as I would expect assembly hierarchy to be empty until the leaf.
Maybe I'm missing something?

I did a usdcat on the usd file to have a look at the usda, and there looks to be single Table reference there.
Perhaps there's something I'm overlooking wrt how this usd scene was created?

At any rate, I thought id share a little code I was using to debug that prunes out some of this additional prim path geo prior to unpacking in a couple of vex vs python hdas -- if only because I love the new Versioned Digital Asset Interface.
Well done; simple, elegant, and should enlighten many in the way of the hda!

I'm pretty sure your problem is the "Primitives=*" part. You are telling it to create a USD packed prim for /world and for /world/stuff and /world/stuff/table, and /world/stuff/table/mesh_0... Then you are telling Houdini to unpack all of these to polygons. /world unpacks to a polygonal representation of all the geometry in your scene. /world/stuff unpacks to everything under the "stuff" branch, /world/stuff/table unpacks to all the meshes that make up the table, and /world/stuff/table/mesh_0 unpacks to the one mesh of the table.

Instead, you need to tell the LOP Import SOP at what level you want to deal with stuff. If you're going to be manipulating mesh geometry, you probably want to set the Traversal to "Gprims", which will look at your "*" primitives pattern, and march down each match until it fins the gprims. Or you could do this more directly (and more quickly) by setting the Primitives field to "%type:Gprim".

If you're just going to be moving around whole objects, or using the geometry for collision purposes, you will be better of using "%kind:component" as the primitives pattern, which will treat each component as a single USD packed primitive. This will make it faster to unpack (but you can't re-import these polygons to SOPs because you've lost the connection from the polygons to the specific Mesh primitive within the component.

Thanks for the quick and detailed explanation. That imports better, and makes more sense.
These primitive masks are handy. %type:Gprim looks to be specific to meshes, ignoring instances,
so I'm curious to know if there might be a similar mask that can isolate all instanced primitives on import?
cheers.

I don't understand what you mean "specific to meshes"... It will accept any Gprim (mesh, basis curve, sphere, cube, etc). See the inheritance diagram here: https://graphics.pixar.com/usd/docs/api/class_usd_geom_gprim.html [graphics.pixar.com]

It will pick up gprims whether they are instanced or not. At least it works fine in my testing.

Oh, and if you're asking about being able to find all prims marked as "instanceable", there is no "%" shortcut for that, but you can use a VEXpression (see https://www.sidefx.com/docs/houdini/solaris/pattern.html) to find all prims with this flag. Or if your scene is set up to set the instanceable flag at the component level, there is a shortcut for finding all components (described on that same help page).

Thanks again for the info and apologies if you have answered a lot of these hard to parse new to solaris type of questions.

The problem for me, as you mentioned, was naively using '*' as the Primitives pattern of the LOPImport.
This served up a lot more packed USDs than I was expecting, regardless of traversal.

Using '/*' for the Primitives pattern with Gprims traversal returned the 55 unique packed USD 'leaves', one of which is the instanced shelf 'contents'. No surprises when unpacking to polygons, all good.

I just happened to notice that using %type:Gprim as the prim pattern in an otherwise default LOPImport, left out the instanced shelf 'contents', and I wasn't sure why. Evidently, its because UsdGeomPointInstancer does not inherit from UsdGeomGPrim. Using a common base class %type:UsdGeomBoundable brought in the Gprims and the PointInstancer, but I suppose what I was looking for was an additional type pattern to union with %type:Gprim and %type:UsdGeomPointInstancer did the trick.

I appreciate the pointers and food for thought.
Cheers.

Good point about point instancers. They almost always need to be considered separately anyway, so it's probably good that they aren't included by a "%type:Gprim" pattern.