Mark Tucker

The latest RfH builds do, I believe, allow COP-based texture maps. They are specified the same way you would do so for a karma shader using the "op:/path/to/cop" string in the "Texture File" parameter of a VOP, or Material Edit Properties LOP. This is something that needs to be implemented on the RenderMan side, so make sure you are using a version of RfH that claims to support this feature. Then build a simple hip file that gets it working with karma (using USD Preview Surface - a shader language understood by both Karma and RenderMan). Then switch to RenderMan. If it works in Karma, it should work in RenderMan too.

I believe you are mistaken about the behavior of node.geometry(). It will not cook the SOP. If the SOP has already been cooked, then yes, it will return the geometry generated by this SOP the last time it cooked. But if the SOP has not been cooked, the geometry returned by node.geometry() will be empty.

LOPs is a little different from SOPs in regards to returning the last cooked result. This is because every SOP node keeps its own copy of the geometry it generated last time it cooked. LOPs do not keep a full USD stage for each LOP node. LOP nodes in a chain will generally share a USD stage, and edit and recompose this stage when you look at the cooked stage from one node then another in a chain. In Manual mode, even this recomposing is avoided, so the stage you get back from node.stage() may not be the same stage last cooked by that node. It may be the state of that shared stage as understood by some other node in the chain of LOP nodes.

One approach that might work would be to do both the initial SOP create (which imports the first frame of the geo and sets up the material bindings), and feed that into the geo clip sequence LOP. This will override most of the opinions of the SOP Create LOP, but will leave the material binding opinions untouched.