Hi everyone!

I would like to control the way the operation stacks of my Xforms are written in my USD layers (the ‘xformOpOrder’ property).
More precisely, I would like Xforms to follow the assumptions surrounding the UsdGeomXformCommonAPI schema [graphics.pixar.com] and be correctly interpreted by it.
However, some LOP nodes directly work with matrix operations (e.g. the ‘Duplicate’ LOP node), thus producing transforms unrecognized by UsdGeomXformCommonAPI.

Is there any way of controling how the ops of the Xforms I create are described in the USD layers?
Could using a ‘Python script’ LOP node be a solution?

Thanks in advance for your help.
Pierre.

LOP built-in tools don't make any effort to use the xform common API. As you mention, in LOPs, transforms are generally output as 4x4 matrices. Since the xform common API just uses the standard USD capabilities for authoring xforms, Houdini will perfectly interpret and understand xforms authored to this standard. And you can write your own tools that author xforms according to this standard (either using Python, or probably VEX as well). But that will cut you off from using some Houdini tools, unless you write a tool that runs as a post-process and re-authors all prim xforms according to that standard…

Thank you for your answer!

As you suggested, I would rather have a post-process that converts all the Xforms generated by my LOP network right before it gets written down as USD layers.
Is there any mechanism that Houdini provides for calling custom code over a stage that is about to get ‘rendered’?
Ideally, I would look for something along the lines of the output processors that are used to process asset paths prior saving.

Output processors don't let you do anything like this because really this is what nodes are for… I would suggest using a python LOP, and wrap it into an HDA along with the USD ROP.

mtucker
Output processors don't let you do anything like this because really this is what nodes are for… I would suggest using a python LOP, and wrap it into an HDA along with the USD ROP.

Is there any reason the houdini nodes that author xforms from TRS parameters don't optionally write them as individual xform ops, (other than, I guess lack of demand or performance?)

Writing Euler rotations as matrices is somewhat lossy, as you might want to directly author rotations of greater than 180 degrees per frame for simplicity.

With USD going to all 64bit xforms of type matrix, sticking with sparse individual ops would produce smaller files as well, since only translate or transform matrix are always 64 bit in the new USD spec.

If we were going to do something like this (which is a possibility, provided as an option) I think we'd want to author the transforms using the UsdGeomXformCommonAPI (rather than our own split T/R/S schema…). Hopefully that is what you were suggesting? The other aspect of using the UsdGeomXformCommonAPI, is that instead of adding new xforms to the stack on a prim we would update the existing xforms already on the stack for that prim, which would also do a lot to keep file size down.

mtucker
UsdGeomXformCommonAPI (rather than our own split T/R/S schema…)

Is that something new? I've not heard of it.

I was referring to using individual usd xformops created in the order selected by the transform order menu, such as rotateXYZ, translate etc.

I hadn't either until very recently. Not sure how long it has been around. The original post has a link to the USD docs. It's basically an API for easily creating a standardized set of xform ops. Doesn't add any new functionality, just tries to be consistent about what components exist with the xform stack for a given prim.