I’ve been running into some problems with a custom Hydra primitive adapter and the default behaviour of ProcessPrimResync. I started a discussion about this on the old USD Google group a couple of months ago, and it unfortunately took me a while to revisit the idea suggested in the reply to my question.
Here is the original thread: https://groups.google.com/g/usd-interest/c/3hyh9VGb-MU/m/_4fPZKy7BQAJ
Here is a summary of my original question: I have a “procedural” Hydra primitive adapter (inheriting from UsdImagingPrimAdapter). The geometry which it renders is generated and cached at render time, i.e. it does not preexist on the USD stage.
ProcessPrimResync is called when editing materials attached to the prim in Solaris, and the default implementation of ProcessPrimResync deletes the prim and re-adds it in Hydra. This is slow since it wipes the cached geometry, so it makes editing materials which are attached to these prims rather painful. I asked what options might be available to mitigate this.
Tom Cauchois replied by suggesting that I can override ProcessPrimResync, and “ignore” the resync under some conditions:
“You’ll need to manually verify that the procedural prim you’re resyncing still exists, still has the right type, and verify the input values if you don’t want to invalidate them, but if that all looks ok you’re probably fine to ignore the resync.”
I have now tried playing around with this idea, but I can’t quite get it to work. At first, I could not get the Renderman RIS viewport in Houdini Solaris (19.0.x) to refresh after a material was edited. I was able to correct this for the first edit by manually invoking MarkMaterialDirty inside of my ProcessPrimResync function. However, this somehow doesn’t work beyond the first material edit - subsequent edits won’t be picked up when the prim gets re-rendered. So it would seem that something else needs to be dirtied, but I’m not sure what that might be.