I'm hoping someone can shed some light on what I'm seeing.

I have a subnet inside which I have some Light LOPs. This subnet is part of a larger graph in /stage. Let's say I want to adjust the position of one of the lights inside that subnet, but by editing the source lights, not via an Edit or Transform node. I'm seeing different behaviors in the network when I try to transform the light and it's not clear to me what the conditions are that cause each behavior.

If I dive into the subnet context that contains the light lops and select the lop for the light I want to transform, and hit T, to begin transforming it in the viewport, I see one of the following three behaviors:

1. the light prim in the viewport gets a transform handle and I can move it around directly, with no new LOP nodes created, and the transform being reflected directly in the Light node's xform parms. With the light lop node selected, this is kinda what I would expect and hope to see, but it doesn't usually behave this way and I'm not sure what the required conditions are.

2. The second behavior I see when hitting ‘T’ with the light node selected is that a new Edit node is automatically generated, but outside the subnet, in /stage, directly after whatever node has the display flag.

3. Or… a new Lightmixer node is automatically generated, outside the subnet, in /stage, directly after whatever node has the display flag. This seems to happen if the light prim is also selected in the scenegraph.

Anyway this is all super confusing to me. My expectation was that selecting the light lop in the subnet and then firing the transform tool would adjust the transform properties on the Light LOP node directly. Sometimes it does this, sometimes it doesn't, and I can't tell what's different about each scenario.

Now if I am in /stage, have the light prim selected in the scenegraph and hit ‘T’, I totally understand that it would drop down an Edit node. That makes sense because the command is predicated on the prim, and so naturally would behave as an override step, requiring a new node. But if I just want to edit the values of the original light lop itself, interactively with a handle in the viewport, how can I do this consistently?

Insertion points are not what I'm after here because I am wanting to interactively modify the source light node itself.

Could someone demystify this for me?

I guess it's just me then. Maybe I should make a video and not use so many words.

No, not just you. The behavior of the T/R/E keys is pretty messed up in the LOP viewport. There are lots of ways to get into confusing states/situations that are hard to get out of and get to where you really want to be. It's something we're looking into, but it's a very tough nut to crack. SOPs has had similar-ish issues for the past 20 years or so

So is there a predictable way to edit the transforms on a light LOP after the fact, in the viewport?

Tim Crowson
So is there a predictable way to edit the transforms on a light LOP after the fact, in the viewport?

does clicking on the lop defining the light work? That usually puts me in a state ready to move it.

jsmack
does clicking on the lop defining the light work? That usually puts me in a state ready to move it.

Only if I am in the immediate context that contains the lop.


So if my light is inside a subnet (because I can't very well have 236 hand-placed lights in /stage) I have to dive into the subnet in order for the tool to work (whatever the name of the tool is that fires when you hit ‘Enter’ over the viewport). In that case, with that special transform tool active, and with the lop selected, I can hit E/R/T and be able to transform it at will.

But I usually need to be able to pin the Viewer so it reflects a state outside the subnet, since subsequent nodes (after my lighting subnet) may be contributing to the scene in a way that affects the lighting. So I need to see the full result of my cooked graph, in order to know what I'm making my lighting adjustments against, but I can't interact with the light LOP properly unless I'm in its immediate context.

There may be some combination of pins that can get me what I need, but like I said it's just confusing.

And obviously this doesn't pertain at all to overriding lights later on (which we have several ways of doing and which totally require separate nodes to contain those edits). I'm just wanting to edit the base light node while evaluating the change against downstream mutations (maybe some new geo is grafted into the stage 3 nodes down or something…)

In order to see the state outside the subnet while editing nodes inside the subnet, make sure that none of the nodes inside the subnet have a display flag set. In that case, without having to do any tricks with pinning, the viewport will show the LOP node in the parent network with the display flag on it.

Thanks Mark, I was under the impression it was best practice to have an Output node as the final node in a subnet, with the display flag set on that, so that has been my setup. I just went through and removed the display flag where possible in my graph and like you said, it falls back on the parent context's display flag. That kinda makes a big difference.


With those display flags removed, I'm happy to say that the transform tool works as expected when selecting the light lops inside a subnet. Sorry for the noise, I feel like this was something I must surely have seen in the docs, but I had no idea display flags worked that way. Thank you for explaining!

mtucker
SOPs has had similar-ish issues for the past 20 years or so

Yes,I also suffer this for years.
Removing TRE key and 3 buttons maybe a good workaround. One can create an edit explicitly if need.

We're running into all manner of confusing behaviors here. Everything is fine in a simple scene with a torus or whatever, of course, but in a more complex scene with lights inside subnets, and the display flag one level up, it is a nightmare to actually do a simple transform on those lights. When selecting a light node, Houdini insists on either not showing the node's handles in the LOPS viewer, period, or... if we hit any key, we get a new node created outside our subnet after the display flag, which does us not good. I am sure it's a tricky thing to solve, but it's a vital one, really.

As it is our lighters are struggling to... well.... light.

Hi Tim

My workaround is to leave everything out in the open and not in subnets. Its not as tidy but I can work faster.

Best

Unfortunately leaving light nodes out in the open isn't an option in our case.

If you can provide a scene with steps to reproduce that would be very helpful...

Attaching a quick file. Created in 18.5.596.

1. In this scene the only node that has a display flag is the final Karma node. Normally that setup should allow us to forego pinning the Scene Viewer to /stage (although I want to say we have run into situations where we still needed to pin, but I need to check). The problem I have been seeing is that diving into a subnet and selecting a Light LOP inside it would never display its handles in the viewport. I just now realized that this happens only if the Viewer is pinned to /stage. If I remove the pin (and still leave the global display flag setup alone), then selecting a light lop inside a Subnet draws the handles in the viewer, allowing me to transform it as expected, without creating additional edit nodes or whatever. I'll try this in one of our production scenarios and see how it does.

2. The Lightmixer seems to throw errors when created and when accessed after creation. You can see this in the second subnet. I was wanting to confirm that if I select a light in the light mixer, I get its handles in the viewer. But the python errors are preventing me from testing. This is the error I get when I drop down a lightmixer in this scene...

I am not sure if this is a solution for a complex network, but the RMB menu from the attached image works for me.

Probably there is a way to access this functionality with Python, so we could write a script and assign a hotkey.

I found the menu definition here:
C:\Program Files\Side Effects Software\Houdini 18.5.408\houdini\UsdStagePrimMenu.xml

With my limited knowledge, I found out that for the "inplace" transform, without creating new nodes, you can call:

l = hou.node('/stage/subnet1/light2')
l.setSelected('True','True')


For the other modes, there are functions in the loputils.py:

createEditorNode()
getPrimEditorNode()

Hello, has there been any progress or solution on this? We find it on our end as well. I have tried pinning the scene graph, going inside the sublayer network but nothing seems to work as expected. It either creates a new lightmixer or an edit light node. We need to have our lights in the sublayer network as it's not feasable to have them clutter in the /stage.

This is really annoying and makes it so much harder to work with. Can you make it so it doesn't create a lightmixer/edit node by default when editing a light inside a sublayer network but instead we can create it on demand outselves? I understand it's a hard case to crack and I've tried all the suggested solutions above, but none of them work and it's also a bit random which node it creates.

Thanks,
Damir

Hi, I came across this thread while I was searching for a solution to this very problem. I found what was causing the issue in my case so I thought I'd add my findings. All of my lights were in the main network (not in a subnet) and I was getting really confused about why a light edit node was created when I moved the light. What I found was that I had an HDA subnet down stream that creates AOV's for each of my lights, if this node was active then it would create an edit node when I moved my light. When I disable the AOV node the light moves without creating an edit node. Not a big deal to disable our light AOV node when I want to edit a light but it is a bit annoying.

So for anyone else trying to find out what is causing the random creation of light edit nodes, try disabling anything that might be referencing your light to see if it fixes the issue.