Design : A Gaffer Light Editor

[themissingcow]

A Gaffer Light Editor

This issue covers the high-level design and initial considerations for a Gaffer Light Editor. It is deliberately missing any fine feature detail. This will come later. It aims to illustrate the basic approach, and outline some key topics for further discussion.

Other topics

There are several topics that need further consideration, that aren't covered here, including:

• Facility customisation (layout, light creation)
• Managing a large numbers of lights (see comments from @DanieleTosti).
• Applying relative edits to multiple lights.

Artwork.zip

[DanieleTosti]

Thank you for investing into this! It is incredibly exciting to see the progress on the project. It will be an incredible addition. It all sounds quite promising!

I apologize for the short and generic notes, which Im sure you have all been considering already. But I hope some food for thoughts, plan validation or not, is better than none. And this is the only time i may have available at this moment. ;)

Having spent years on this side of the fence, the few things that come up to mind:

1- troubleshooting is not a common event but always a crucial consideration It is often that leads and supervisors have to jump into other's shots. Supporting troubleshooting (ie: verification of lights at given graph locations; isolating group of lights; modification history; notes; finding where the light was created; constraints; animated attributes; ... ) will go a long way. It sounds like you are taking this in account already.

2- scope of scenes A panel should be reliable and efficient independently on the scope of the scene. It is not uncommon to have scenes with one hdri vs dozen or more lights nowadays. Filtering or isolating lights, filtering or isolating attributes, dealing with multiple nested groups, sharing attributes, driving expressions, changing attribute settings across entire groups (ie: exposure, temperature, ) , and so on... could be as important for small and large scenes alike. Having some "high level" functionality within the same panel that controls individual lights could be quite beneficial. If not critical.

3- modularity I like the consideration you have about making the panel to view specific attributes. With such a wide scope of elements as in lights there is always the risk to overpopulate the UI. It would be nice to consider some 'user templates' to allow various artists (ie: lighting vs lookdev; character vs environment lighters) customize the panel to their needs. Along some predefined common attributes...

Ill add more as i see it evolving.. Thank you kindly for such a support!

[themissingcow]

Thanks for the kind words and great ideas @DanieleTosti - your thoughts are very much valued.

2- scope of scenes A panel should be reliable and efficient independently on the scope of the scene. It is not uncommon to have scenes with one hdri vs dozen or more lights nowadays. Filtering or isolating lights, filtering or isolating attributes, dealing with multiple nested groups, sharing attributes, driving expressions, changing attribute settings across entire groups (ie: exposure, temperature, ) , and so on... could be as important for small and large scenes alike. Having some "high level" functionality within the same panel that controls individual lights could be quite beneficial. If not critical.

Yeah, aside from the multi-selection behaviour that should carry over from the SceneView Inspector, we haven't thought a lot yet about other abstractions for driving multiple parameters or lights from a single place. It definitely needs some attention before we get too far down the line with any particular direction.

3- modularity I like the consideration you have about making the panel to view specific attributes. With such a wide scope of elements as in lights there is always the risk to overpopulate the UI. It would be nice to consider some 'user templates' to allow various artists (ie: lighting vs lookdev; character vs environment lighters) customize the panel to their needs. Along some predefined common attributes...

Absolutely, the columns, aspects of creation etc. definitely need to be configurable.

thanks again - and please keep the good ideas and feedback coming!