Is there any way to have the active delegate drive a switch in LOPs? I have code that technically does this, but it activates too late (I want the switch to activate at the same time the delegate becomes active). My use case is that I have a setup to test different render engines, with a dome light pointing to an exr. As Renderman does not like exr files, I need to switch between domelight1 and domelight2 (which has a tex file) when the Renderman delegate is active. Otherwise Renderman will choke on the exr in domelight2 and lock up the session, requiring me to force-quit houdini.
node=hou.pwd()stage=node.editableStage()#####get list of panes####panes=hou.ui.paneTabs()sceneviewers=[]curDesktop=hou.ui.curDesktop()desktopName=curDesktop.name()#####identify scene viewers####forpinpanes:ifp.type()==hou.paneTabType.SceneViewer:sceneviewers.append(p)forvinsceneviewers:a=v.currentHydraRenderer()#print aif"RenderMan"ina:hou.parm('./lightswitch').set('2')elif"V-Ray"ina:hou.parm('./lightswitch').set('1')else:hou.parm('./lightswitch').set('0')printa
./lightswitch is a spare parm on the python LOP, and then I have a channel reference from that lightswitch parm in the switch lop
Edited by Hamilton Meathouse - July 27, 2021 13:04:44
I'd love to know this as well, but for another use case. Side note: As far as switching between different light domes in order to switch the texture; using "edit properties" node to swap the texture path parm of a single dome might be easier.
I don't thnik it's a good idea to want to modify usd stage based something as ambiguous as viewport renderer choice such functionality wouldnt be replicable after caching usd and rendering from it
I can see it being modified using Context Options for a particular branch of the LOPnet that for example leads to specific renderer or output that is meant to be used for such renderer
or such functionality would have to be part of USD logic itself not LOPs
Yeah the solution I'd recommend is instead to simply override the specific parameters (in the simple attached case, the texture map on a light) in renderer-specific branches. This way you only have to fiddle with the majority of your parameters/settings on the shared node, without any other work on your part. It's only in the where standard primitive property values like texture maps, aren't compatible between delegates. In those cases, try branching with just overrides that update the texture maps, like the attached example. It'd require moving a display flag, but having the stage re-cook based on the viewer is.... fraught with peril to say the least. Also, apart from the Edit Properties, you could also setup a Wrangle that auto-updated the texture map paths.
The majority of renderer-specific properties are namespaced, and designed to co-exist along with one another. Maybe in the future a formal convention/support for specifying namespaced alternatives will exist for these cases (i.e. instead of texture:file, something like texture:file:ri)
Also, if you haven't already it'd be good to log a bug with the RenderMan team, about hdPrman locking up when it can't understand a light's texture map!
Because I'm lazy (and evaluating a bunch of renderers at once), I decided to map the delegate switch script to a hotkey (one for each delegate). As part of the script I have rules to set the switch before the delegate is set. For PRman the switch gets set to 1, for other delegates it gets set to 0.
#####get list of panes####panes=hou.ui.paneTabs()sceneviewers=[]curDesktop=hou.ui.curDesktop()desktopName=curDesktop.name()#####identify scene viewers####hou.node('/stage/LIGHTSWITCH').parm('input').set(1)forpinpanes:ifp.type()==hou.paneTabType.SceneViewer:sceneviewers.append(p)forvinsceneviewers:a=v.setHydraRenderer("RenderMan RIS 24.0")
Edited by Hamilton Meathouse - Aug. 10, 2021 14:37:01
