At around 15:49 in this video by Chris Rydalch,
https://www.youtube.com/watch?v=EgTqz6y_oAs [www.youtube.com]
He demonstrates how a sphere placed into a 'inherited location' will be placed at the scene location of the parent prim.

I imagine this might be a nice way to place high res objects onto proxy objects for free, provided the hierarchies and naming setups are correct, but Im not finding a very intuitive way to do this. Ive attached a really straightforward scene with some alembic blockout objects and their high res counterparts. The blockout objects are at the correct locations in the scene, and the high res objects are at the origin. If anyone is willing to do a show and tell on this little scene id appreciate the insights thank you .

USD already has support for viewport proxies that get automatically replaced with high-res geo during render.

You can use a Component Builder to set up your asset, or if you're bringing in geometry manually from SOPs, you need do define the "usdpurpose" attribute on your geometry as either "proxy" or "render".

eikonoklastes
USD already has support for viewport proxies that get automatically replaced with high-res geo during render.

You can use a Component Builder to set up your asset, or if you're bringing in geometry manually from SOPs, you need do define the "usdpurpose" attribute on your geometry as either "proxy" or "render".

Thank you Eikon.
In this scenario these objects arent even proxies, they are just block out visualization pieces. They are laid out very quickly by a layout artist. This artist has little to no regard for the downstream component building stage in usd.

Right now the asset building team is using component builder to make the columns, the temple, etc. These final "components" are then moved manually into position on top of the blockout pieces. There is no defined relationship between the blockout bits and the actual components that's the main issue here. Our layout artists need the freedom to work quickly without regard for downstream planning, but then that leaves us with a manual repositioning of all final assets when the time comes.

I just felt like we could hijack the transform data from the blockout pieces to save us a bit of layout work if we were clever with the primitive hierarchies.......
Take for example the light column.
If the primitive xform data was in tact, and then this primitive blockout was correctly configured to be
say
'/light_column/blockout'
the hope was that we could force the finalized asset '/light_column/main' to inherit the transform data.

Apologies if I am totally missing a solve you are describing here in our specific use case! The component builder has been excellent for the asset building second stage at least. But we are not using usd assets as a starting point for our scene blockouts.

Can you include all your Alembic dependencies with the scene file you have posted? It's not apparent where the transforms to your block out geometry are actually happening.