Hey folks,

Since USD is encoding “upAxis” and “metersPerUnit” as the metadata on stage level. I'm wondering if Solaris could commit an automatic transformation while loading stages. It would be beneficial and avoiding to convert geometries to Houdini's baseline every time exporting them from other DCCs.

Cheers,
Calvin

Any attempt to globally apply such fixes is certain to end in sadness. This is a huge can of worms. Which is why USD itself doesn't make any attempt to do anything with this information. These metrics are really only useful for validation purposes (make sure that all layers loaded onto a single stage have the same up axis and meters per unit value). I'd like to add this kind of validation to LOPs, but there just isn't enough information in a USD layer to blindly apply an xform to every prim in the layer to transform it to a new orientation/scale. Which attributes/primvars need to be transformed? And then there is the question of when to apply the reverse transformation? Houdini doesn't even have a well defined “up axis” - we just have a viewport setting, which isn't even accessible in batch mode. And many studios don't use the length unit setting.

I think the only sensible place to perform this sort of transformation is going from LOPs to SOPs and then reversing it going from SOPs to LOPs. This is something that could perhaps be built into the SOP Modify LOP as an optional feature? But you'd need to provide an explicit “destination” up axis and length unit right on the SOP Modify LOP, and an explicit list of USD attributes that need to be transformed…

on top of that physical lighting (light intensity, material absorption, …) heavily depends on the scene scale
so you don't want USD to resolve as different scale when read by different DCC or renderer

LOP <-> SOP conversion may be handy though

Hey Mark,

As I learned from usdview, the “metersPerUnit” does not affect the Hydra viewport. This metrics is just for validation purposes, as you mentioned. However, the “upAxis” does change the up axis of the Hydra viewport.

Instead of reading global preferences, it might be beneficial if Houdini GL does the same thing like Hydra here. I suspect the users are expecting to see the same result while they are visualizing a stage in both LOP and usdview. Then the actual transformation could be an optional argument of LOP Import as you say… which to unify the look of SOP and LOP…

calving
Hey Mark,

As I learned from usdview, the “metersPerUnit” does not affect the Hydra viewport. This metrics is just for validation purposes, as you mentioned. However, the “upAxis” does change the up axis of the Hydra viewport.

Instead of reading global preferences, it might be beneficial if Houdini GL does the same thing like Hydra here. I suspect the users are expecting to see the same result while they are visualizing a stage in both LOP and usdview. Then the actual transformation could be an optional argument of LOP Import as you say… which to unify the look of SOP and LOP…

I would find it tremendously confusing if the displayed node affected the viewing characteristics in such a profound way. There are all kinds of ambiguities when it comes to combining nodes. I think LOPs is fundamentally incompatible with such a notion.

jsmack
I would find it tremendously confusing if the displayed node affected the viewing characteristics in such a profound way. There are all kinds of ambiguities when it comes to combining nodes. I think LOPs is fundamentally incompatible with such a notion.

Umm… Fair enough, though, the fallback solution might be having Metrics LOP to do such a conversion? Since operations like changing UpAxis isn't as easy as rotating ninety degrees but swapping Y and Z along with switching orientation. The affected attributes / primvars could be controlled by the parameters… Or having all the above functionalities as a part of the File LOP would also be an intriguing idea…

Was there any resolution to this? Some node which applied those transformations with overrides would be helpful.

Cheers

The resolution for now is that we aren't going to be dedicating any resources to it in the near term. It's a complicated and somewhat ambiguous problem to massage all the geometric data of a layer from one set or units or one oreientation to another. As I understand it the metadata available in USD is insufficient to unambiguously “do the right thing” in the general case. It is also unclear how common it will be for one studio to be dealing with data files in differing orientations that need to be combined. Presumably all data generated by any given studio will all have the same units and oreintation. And when data is coming into a studio from elsewhre, I presmume that fixing the units and the orientation will just be two among a dozen different manipulations that will need to be performaned on such data (probably as a one-time batch process, rather than something you would want live insied your LOP network).

So although we do see the clear need for these tools, they don't really fit our current primary focus of making Solaris a premiere package for _lighting_, so they will sit on the back burner.

Also wanted to give some feedback, as we are also having issues with those unit differences when importing assets from other DCCs.

So one reason for people to have scaled geometry in sops is to have simulation parameters working in a solid environment. Exporting this data results in re-scaling the data for export.

When working in LOPs we don't have to take care of the scale, as long as every asset in the pipeline has the same scale - that is true. So as you already pointed out the main difference is when communicating from SOPs to LOPs (e.g. use SOPs surface data, scatter with PointInstancer in LOPs). Geometry has to be re-scaled to have the proper scaling in LOP world to fit in with the other usd assets. This points to creating a custom SOP Import node which automatically scales the geometry to fit in with usd geometry.

Although when switch back and forth from /obj to /stage to validate if data aligns and looks fit to the generated data, one of those contexts is scaled - so comparing both worlds is hard. Having the /stage viewport run on different units would be great, but of course we understand that is quite a complex topic to face.