Somehow this hasn't come up for us yet until now, but we're curious what we're doing wrong:

1. let's say we have a light LOP, creating a light prim and moving it around the viewer to give it some transformations
2. downstream, let's imagine a Light Edit LOP, dropped down with the intention of overriding the transform on this light
3. we point the LightEdit LOP to the light prim and select 'Set All Parameter values from USD Prim'
4. we want to override the transform, so enable 'Set or Create' on the transform parm, and move the light
5. but now let's say we want to alter the original transform on the first Light LOP: we reselect it and move the light a little, altering its "initial" position prior to the LightEdit.
6. if we now recook the LightEdit, the light is no longer in the position we had set. It has moved, presumably because its operation order is set to Append, and is additively modifying the source transforms, which were changed since we last modified the LightEdit.

If we prefer to have the LightEdit's transforms be independent of the source (i.e. adjust the LightEdit's transforms and know they will be fixed regardless of the "incoming" values on the source prim), but using the incoming light's transforms as a starting point, how can we do this?

The "Initialize" command does not seem to work with transform values, and we can't find an operation order that 1) maintains the incoming transforms as a starting value for an edit and 2) breaks that dependency so transformations done via our LightEdit LOP remain in place (in world space). All the operation order options do one of two things, seemingly: they either act as modifiers against the incoming value (like an additive effect) or they break that connection entirely, but also revert the light to the origin in the process (would totally just use this, if only the initial xform values matched the incoming, rather than 0,0,0).

Can't help wonder if the 'Initialize' option is also supposed to pick up the starting transform values, in world space?


Incidentally the same thing happens with a LightMixer.

The problem is that in a production scenario, light prims are made available to artists downstream, and they may need to override them. It's common to provide a sequence level light-rig for example, and modify light transforms at the shot level. But the problem we're having now is that if we publish an update to that sequence level light rig which modifies the transforms on the light, this affects the modifications already in place at the shot level, due to the 'Append' behavior.

Hoping we have managed to miss something obvious?

I think what you might want is the Transform LOP with "Set Absolute Transform" enabled and the SRT values pre-initialised so the object doesn't pop back to the origin? I don't think we currently have this (at least I haven't immediately spotted it), but it shouldn't be too difficult to add (famous last words, of course).

Hi Rob,

Yes, that's the essential result we would need. But in addition to the Transform LOP, this would also be supported by other LOPs that do similar things (Light LOP, LightMixer LOP, Edit LOP), to avoid having to use one node for overriding SRTs and another for lighting properties.

But I'm still curious about why the SRT values on the LightEdit LOP don't get populated when running "initialize".

EDIT: I guess it's because the default mode is 'Append', this its starting values need to be 0.

Sorry, just to keep this alive.... Has no one else flagged this? Is it just us? It seems like most production scenarios that rely on downstream mutations would run into this. Any chance there is already an RFE in place?