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.

eikonoklastes
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.

Certainly Eikon!
And thank you for taking a look into this .
Not sure if I am doing this correctly or not:

the blockout assets and stand in high res assets are being exported as a single alembic from a blender file.

So, you're not actually doing any layout work in Solaris. This is not an ideal scenario for what you want to do. Ideally, you want to be creating your asset first that has the proxy and render/high-res geo set up (it doesn't matter if the render geo is not finalised, you can always update it later).

You then want to be using Solaris to lay out that asset. It will create instances of your asset, allowing you to rotate, scale and place the proxy geo as you wish, and when you hit render, you'll already get the high-res geo, no extra work needed.

I understand that your layout artist might not know how to use Solaris, in which case you'll need to use Houdini's standard toolset to replace the geo (I don't believe Solaris itself is capable of handling this, as there is no defined relationship between your proxy and render geo).

Regardless, I have set up two ways that could maybe work for you. Please check the attached scene file. Method 2 is more efficient as it will use instances, but if your scene is not that heavy, you can use Method 1.

Bear in mind that neither of these approaches are optimal, and have critical limitations. You cannot freely lay out these pieces in Solaris and will need to resort to SOPs or Blender to tweak their positions. If you want to rotate or scale the pieces, you will be required to set that up in SOPs - any incoming rotated or scaled geo from Blender will not work with this approach.

Note that your light stand geo is not in good shape, and has overlapping points. I had to delete some bad geo to prep for this example.