Hi !

I am looking at the possibility of making a custom renderview for Solaris that would better fit my needs.
I looked around the HDK and it seems I may be able to recover the composed USD Stage from the nodes outputs, but I'm wondering if SideFX would have pointers at where would be best to grab the current viewed stage ?

I vaguely remember seeing that the renderview stage was a special copy of the one executed by the cooking process, as well as some threading things that Houdini does on top of the vanilla Hydra delegate rendering. I'm wondering if there's another access point in the HDK I should be looking at ?

Thanks !

The scene viewer keeps its own copy of the composed stage generated by the LOP network. This is done using the HUSD_DataHandle class, specifying HUSD_FOR_MIRRORING as the constructor argument. This object is owned by the viewport. Then use the HUSD_DataHandle::mirror() method to make a copy of the HUSD_DataHandle returned by a call to LOP_Node::getCookedDataHandle. Once you have this "mirrored" copy of the LOP stage, you can use an HUSD_AutoReadLock to "lock" the HUSD_DataHandle and gain access to the USD Stage pointer. When the LOP stage changes, just call mirror() again with the same mirroed HUSD_DataHandle object, and this will help minimize the hydra updates triggered in your viewer.

Hopefully that's enough to get you started!

Excellent ! Thanks a lot Mark this is exactly what I was looking for I'll report back here if I hit a wall.

Hey, I'm bumping this up since this brought up a few questions.

I've got the stage access/mirroring working well thanks to Mark's tips. But I have been struggling to find the correct way to track changes on the resulting stage of the viewer lop, obtained via getViewerLop().
I have tried hooking an addOpInterest() to the viewer lop, but this is not giving me the behavior I was hoping for :
- The callback gets called, but not for the right reasons. OP_PARM_CHANGED is called when the viewer LOP itself has a parm change, but not it's input nodes (and OP_INPUT_CHANGED is not called either).
- OP_PARM_CHANGED may be called when the input nodes change but that's just luck because of a parm expression in most LOP nodes (something about guide scale). The actual parm that changed is not passed to the callback.
- Even then, when the callback is triggered, using getCookedDataHandle() yields the stage before the edit. It feels like I'm breaking evaluation here. If I edit a node again, getCookedDataHandle() will return the stage with the edit before that. Calling forceRecook() just before getCookedDataHandle() seems to work, but I've had instability with it.

I've studied the Houdini Bridge Repo trying to find clues but no luck

So my question is :
- How does one properly catches that a specific node needs to be cooked because itself or it's inputs have changed ?
- Is there anything particular to be aware of to get an up to date stage when calling getCookedDataHandle() ?

Thanks a bunch !

1. In C++, I think the best way to know if the LOP node you are "watching" is dirtied is to create your own subclass of DEP_MicroNode, and connect the lopnode->dataMicroNode() as an input to your micro node (using addExplicitInput). Then in the becameDirty() virtual function of your DEP_MicroNode subclass, you can flag your viewer as needing to update. Don't actually _do_ the update in that function. You should instead post a message to the UI event queue that will make it back to your UI gadget when the UI regains control (otherwise you can easily end up doing a huge amount of redundant work).

2. You should not need to do or be aware of anything in particular when calling getCookedDataHandle. Especially if you follow the advice above about posting to the UI thread, because then you can be sure that all processing related to the most recent user action has been completed.

Amazing, thanks for the help Mark, this makes sense ! I'll implement your suggestions and come back here should I need more help. Thanks again for the quick answer and clear guidance !