Improve visualisation and manipulation of lights in the viewport #104280
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
14 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#104280
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The idea is to better control/visualize light parameters in the viewport. Currently we can only control the spot angle of spot lights, the size of area lights and the light direction.
Concept drawings by @eyecandy for reference, not the final design.
Tasks
Add gizmos to
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @eyecandy, @weizhen, @pablovazquez, @dfelinto, @ideasman42
This issue was referenced by
3c8c0f1094I submitted a patch in D17171 for the spot blend. The current
cagegizmo type has scaling, that we could use for single parameters such as radius/size and blend. However, that gizmo type only draws rectangles/cubes. We could add a circle/ellipse draw style, the reason I'm hesitating is how do we define the transform behaviour and where we should put the handles. Based on the current use cases, we seem to only need uniform scaling, so I could think of drawing a circle with uniform scaling, and put one handle which follows the current hover position. But I wonder if we also want an ellipse around for example ellipse area light, in which case we probably want to constrain scaling in X/Y directions, maybe also four handles for uniform scaling, just as the current rectangle one but with a different shape. Seems that all the graphics softwares I've been using adjust an ellipse shape with a rectangle cage, I'm not familiar with UX design and don't know why this is the case.Added subscriber: @silex
This is just a user opinion on the design of visualizing light color.
Transparency fill might interfere with how object and material colors are perceived. This can be problematic with big and complicated scenes with lots of objects and overlapping lights.
Outline coloring is already present in the UI as it indicates
selectedandactiveobject status. Using it for light color will make really hard to tell which orange lights are selected or active.Personally from all the designs I like second center dot the most. It really pops out, but it's not intrusive. First and third variants (from the left) have two UI elements with different colors very close to each other which can make reading color harder.
Added subscriber: @TheRedWaxPolice
Added subscriber: @zhanghua
I definitely also prefer the center dot way, it would be the least busy option in my opinion.
This issue was referenced by
fe5d54d3d0Added subscriber: @persun
Added subscriber: @Slowwkidd
First of all, thank you for adding all these quality of life updates!
I don't know how much this can create conflict with your addition of size/radius gizmos to lights, but as a user I always found confusing that scaling the lights in the 3D viewport doesn't update the size parameter in the properties, while viceversa doing it in the properties does. If we scale with both methods, the size parameter doesn't reflect anymore the actual size of the light.
2023-02-06 12-02-49.mp4
If you perform transformation on lamps (via press the S key for example), then this is done object-wise, so if you check the Object Properties tab, you'll see that the scale is updated there. This doesn't affect any other object. On the other hand, if you change the
Sizeparameter or drag the gizmo, you are changing the actual object data, that means if you have multiple instances of the same lamp, they will also be scaled accordingly. In the end the actual size is the Size parameter in the Object Data Properties tab multiplied by the Scale parameter in Object Properties tab.Some users don't like that one can scale the lamp object, they think one is only supposed to change the size in Object Data Properties, but I'm not very sure of this. I can see that the current approach makes sense if you have instances that share the same object data, and when you want non-uniform scaling for spot lights.
Ah, you are right. This is another instance where I always forget that in Blender dealing with Object vs. Object Data (and Scale vs. Dimensions) brings more things to consider. Anyway this was more of an OCD annoyance from my side, as long as I have the ease of use scaling lights with S directly in the viewport, I'm fine.
Added subscriber: @Nika-Kutsniashvili
Added subscriber: @AlexeyAdamitsky
Added subscriber: @GeorgiaPacific
I personally prefer the filled option. However, not the way it is presented in the mockup. I think we could have a gradient that leaves the center more transparent (and thus, the light icon and center dot more visible).
However this might be even more distracting so I'm still unsure between this and the size outline (or could be a combination of both?).
The transparent overlay could also be behind all other overlays (a bit like the armature capsule influence). This would avoid reducing visibility of other overlays.
When you have several lights near each others, the centers could easily overlap while the shapes might not. Having the shape colored will avoid loosing lights in this case.
I do agree it might make the scene a bit more busy but this should be an overlay option either way. Maybe it could be a slider (yay another one!) that fades the light color overlay.
But this raises a question: How would you determine the light color if there is a light nodetree? Would it be like the viewport color of materials for solid mode (workbench)?
One proposition I see missing is changing the color of the light icon itself (not covering it with a full dot).
Regarding sun lights, we need to have a way to display their dimension (this would help with the gizmos too). I propose to have a dome that opens until the sun angle (can provide mockup if needed). I don't know if scaling the shape will be enough for a half sphere to look good here. We might have to create a dedicated vertex shader path for that (I can provide detail).
Dome scale shouldn't be affected by object size and instead be defined by an object display property (like empties display size).
@fclem I somehow like the idea of changing the light icon color too :D
I probably don't want to compute the nodetree color :( I could think of drawing some rainbow color for indication, if that's possible and not to distracting.
About the sun light, that's something we still need to discuss. I was thinking just increase the size of the sun, Andy had some idea of actually drawing the angle, but he was not sure, so I didn't put the mockup here. Your mockup would be welcome!
I thing this custom color of emptys and lamps, speakers and light probe is other functionality (expanding of object color from the meshes on other object types)
Hey, super cool to see this progressing :)
This was my mockup for the angle widget/visualization. This resembles the old "hemi" light from blender internal a bit, so I'm not sure how accurate it is in terms of visualizing what cycles does. However, I think it gives more intuitive feedback on the behavior of the sun. Any thoughts?
@weizhen About using the icon color to reflect the lamp: My worry is that this will interfere with the UI theme, as the user can already change the icon/wire color on all lights. I think using a different overlay geometry is the clearer option.
Hi, wanted to give some feedback on what has been implemented so far, as well as on some of the coming features.
For some reason, the default radius of Point and Spot Lights is now set to 0, compared to 3.4, making it less discoverable.
Also for this reason, if for example we have other gizmos (e.g. Move) enabled, it makes it way more difficult to select and control (see video "Move.mp4").
If the radius is set to 0, and we zoom in a lot, there are some issues in the drawing of the radius gizmo (see video "Zoom.mp4").
COMING FEATURES
While I like a lot this, I've read that is coming also with the idea of using the Shift key for scaling uniformly.
While this is a very common and expected feature in lots of applications, in Blender using the Shift key in the 3D Viewport with transform operations always triggers Precision Mode. To me, having uniform scale with Shift only for the light gizmos breaks a lot not only consistency, but also what users would expect. What if I want to scale uniformly AND with Precision Mode? If it triggers both, what if I want to trigger only one but not the other?
I think that also scaling uniformly should be enabled with the visual gizmo (maybe the corners of the rectangle) and leave Shift to Precision Mode.
I love the idea! I'd like to see it once it's implemented to give a better feedback, but for now I'm leaning towards Icon, Center Dot or Size Outline.
Probably too OT (more of a reminder to myself to look into it again - but also because it touches the gizmo to some extend) : I also had this one: https://archive.blender.org/developer/D7971
#88246 is related as well
@Slowwkidd thank you for your feedback.
@weizhen thank you!
Well, regarding light gizmo scaling, I'll have to eat my hat: I took for granted that Precision mode with Shift had always been possible for all the look-at gizmos and for the scaling gizmo of the area light, but after checking, it never was!
But, this made me discover two interesting unconsistencies (see video for reference):
Maybe this re-design could consider 2 options for tackling this: either enabling precision mode for all kind of light gizmos (look-at, size, beam etc.), or keep it as it is but at least clear the status bar info, as it currently shows a false possible hotkey.
Still think that for area lights, instead of going for another kind of hotkey, it should be possible just with the gizmo: dragging the edges constraints scaling on x/y axis, dragging from the vertices scales uniformly.
Here is the mockup (with attached blend so you can rotate):
The size of this sphere cap should be affected by object scale (but have no effect on the lighting, just like the spot cone overlay).
About implementation details, you should start to look at how the spot cones overlays are rendered.
The gizmo would be the "horizon" circle (the bottom of the clipped sphere). I can see 2 ways of interacting with it:
Another intuitive gizmo would be to resize and drag the distant sun as it appears in the background. So not where the light object is. Interaction and mapping to user inputs would be quite easy (just have to do some projections). This should obviously be disabled in orthographic mode.
Hi, are there plans in continuing these light gizmos improvements and implement the remaining proposals? I really liked how this was going.