UsdGeom attribute to Hydra SceneIndexPrim

Community Hydra
1

Hi All,

I’ve been working on Generative procedurals which consume meshes and generate woven or knitted cloth using the generative procedural API. The procedural references meshes & curves within the sceneIndex and generates lovely knitted sweaters or cool denim jackets. Often the geometry I’m processing requires a few custom attributes to be able to execute the procedural.

What is the preferred way of passing this kind of Mesh & Curve attribute data into SceneIndexPrims.

  1. primvars (as standard adaptors copy this data into SceneIndexPrims)
  2. APISchema + Associated adaptor
  3. A FilteringSceneIndex (not sure of the correct base class) which is initialized using a stage and performs the UsdPrim attribute reads and merges this into SceneIndex (or the merge happens in another MergingSceneIndex)

Currently I’m using (1) but I’m increasing coming up to limitations of this approach, but it does seem like excessive boilerplate is required in approaches (2) & (3) just to pass a few attributes into hydra. So much boilerplate, in fact that I think I might have gotten the wrong end of the stick.

(2) seems quite clean but I have to apply schemas to meshes & curves I want a few attributes to the available in the generative procedural

(3) This wouldn’t require any USDStage data changes but I’m unsure of how query which stage should be referenced & how to initialize the filter in a DCC host applications.

Thanks
Don

2

FWIW, we use a combination of both #1 and #2 for the transport of custom data through Hydra. We’ve been favouring #2 (API Schema+SchemaAdapter) in general, but as we explore and dabble with HdGp we see the implied/suggested transport mechanism there is primvar-based.

3

Thanks for the info Rob.

Are you able to give me a few specifics of what you mean here?

4

I’d favor #2 as well, as it provides a nice interface for the attributes. The HdGenSchema script can be helpful to manage the boilerplate. The HdSchemaDefs.py files show how it can be used.

IMO, primvars are fine as well if the plugin doesn’t need the interface a schema provides

5

All the proc inputs (including relationships) are pulled from primvars: