Hi;

I have a model of a track light, like so:


I'd like to be able to aim this track light at various things around my environment, and - because I'm trying to use this as a way to learn more about the world of USD - I'm trying to accomplish this in LOPs.

I understand that by setting the "name" attribute on my lamp geometry, I can control how it ends up being represented in USD. So, I can give a sop prim a name like "light_1/light_suspension/light_canister_lower". This yields a structure in USD like this:



I end up with USD prims that are 1) broken apart nicely in preparation for various material assignments, and 2) organized hierarchically in such a way that benefits the eventual transforms I will need to apply to the various USD prims. For example, I can rotate the entire light horizontally by doing a Y-rotation on the "light_suspension" group, and adjust the up-down rotation of the canister bit by rotating the "light_canister" group.

At least...I *think* this is how I should be thinking about this.

Anyway, I would like to provide pivot information for the various components of this light. I have this pivot information in SOPs, but it's not quite clear to me what I should do with it to effectively bring it into LOPs in a tidy way. I *think* I want to have a USD attribute like "light_suspension.xformOp:translate:light_pivot", which would exist on the "light_suspension" transform. But, this transform doesn't actually exist as geometry in SOPs, it's just sort of an interim thing that 'turns into' a transform at the point where the SOPs are converted to USD.

I can stamp this pivot information as sop prim data on each lamp, in which case it comes through like "primvars:light_pivot" on each prim in USD, but that doesn't seem like where I want this information.

I'm sure my inexperience is causing me to be approaching this incorrectly; I'd love for any advice about how to do this better!

Other folks might know of a better solution, but I think you can move the geo to origin (in sops), pack it, and then move the packed prim back to the original location. The pivot in sops and lops will be whatever was the origin before packing. Once imported into lops the Xform should pivot from the correct spot using a Transform lop so long as 'Apply Transform in World Space' is unchecked. Alternatively you can use a lookatcontraint lop to aim. If aiming is what you're after it's probably easiest to have the geo axis aligned before packing and rotate the packed prim so that the constraint axis can be set properly.

Hm, I'm interested in this idea! I admit I'm not terribly familiar with packing geo; it seems like there's some complexity involved in setting up the name and path attributes for something like my light, which has several materials assigned to the various bits that need to be exposed separately as prims in USD. And further, because my aiming takes place at two different locations in the hierarchy, I think I would need, um, 'nested' packed prims? Is that a thing?

If you happen to know of an example or resource I could use to understand how I might approach this, I would be very grateful. Or even an example scene showing the general idea...when I ignorantly throw a pack node into my scene here I suddenly see a much more confusing Scene Graph, with something called "Prototypes" and what seems like some apparent recursion in the way objects are nested...

dhemberg
I think I would need, um, 'nested' packed prims? Is that a thing?

yeah, exactly. You can use the name sop to name the geometry being packed, then you can name the packed level with another name sop. These translate to the prim locations in the usd graph one to one. You can use nested packs to create hierarchical transforms as well.

dhemberg
Or even an example scene showing the general idea...when I ignorantly throw a pack node into my scene here I suddenly see a much more confusing Scene Graph, with something called "Prototypes" and what seems like some apparent recursion in the way objects are nested...

this is because packed geometry is treated as instances by default. Change the packed behavior on the sop import from native instances to create xforms. This will get rid of the instancing.

Awesome! Cool cool cool, I'm learning. Thank you so much!

So to test, I have a sphere. I add a name attribute, and call it "sphere". Then I pack it, ticking on the "name" box to use the "name" attribute.

In USD, I have:


where the, um, first-level "sphere" is the xform, and the lower-level is the mesh.

Is there a way I can name these two scene graph locations separately, for clarity? So, I might prefer this to be something like:


?

Yes the naming you suggested is possible - just add a different name attribute before and after the pack. Adjusted hip attached with nested transforms.

Also, the name attribute on the pack node isn't important in this particular case and so can be disabled. Also in the scene I attached the pivot location was set to centroid, not origin. I'm not sure why but I'm seeing the same pivot with either setting which is a little surprising. It's unfortunate the pivot can't be set from an attribute too. Packed prim don't really have true pivots though, which is why it's simpler to just move the geo around the origin although that does change the point positions which can be annoying in some situations.

The one thing I never liked about nested packed prims was that they form a hierarchy which in sops you couldn't really grok without recursively unpacking. But now that they can be imported into lops as a nice inspectable tree of xforms it makes quite a nice workflow.

Hi; I just wanted to touch base on this thread to say thank you all for all the help with this, and to effuse about how totally awesome learning this has been!

Learning how to deal with packed geo feels like a bit of a superpower, and I'm a little angry at myself for procrastinating digging into it (I had it in my head that this was primarily a destruction thing, or for massive set dressing, and so I'd mentally written it off as uninteresting/not useful for me). But learning how to apply it here has transformed an absolute hornet's nest of a scene - involving a ton of group shuffling to try to coordinate transforming each individual light in a single sop driven by some hellish math - into something that is far simpler, easier to understand, and elegant.

AND! The thing I am most terrifically excited by is that after allllllllll this rigamarole, I can embrace a note I found somewhere in the USD docs suggesting that changing prim type is as simple as dropping down a Configure Primitive node and picking a different type in a dropdown. So once I've aimed my light geometry, I can do a little switcharoo to convert the bulb geometry into actual lights! Previously I had toted around some instance points with aim vectors on them, and had used light instancing to copy USD lights onto the points. This method is WAY better!

So, yeah...thank you, again!