Viewport: draw light icons using the light colors #105236
No reviewers
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105236
Loading…
Reference in New Issue
No description provided.
Delete Branch "weizhen:colorful_light_icon"
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?
Indicating light colors by coloring the light icons. Ref: #104280
@ -639,0 +645,4 @@
const bool show_light_colors = vedata->stl->pd->overlay.flag & V3D_OVERLAY_SHOW_LIGHT_COLORS;
if (show_light_colors) {
/* Get light color. */
PointerRNA lamp_ptr;
In drawing (where performance matters) we don't use RNA. You can just read the data directly from the
la
.@ -178,6 +178,7 @@ typedef struct OVERLAY_ExtraCallBuffers {
DRWCallBuffer *groundline;
DRWCallBuffer *light_icon;
I know this is just a WIP ticket and you can apply these changes whenever it's appropriate.
perhaps
light_center
should be a better description. (also for the other related methods).I am following the comment I deleted for drawing the part, it was
/* Light Icon */
. Now we draw the inner circles and the outer circle separately, it's weird to call all of them "center". If "icon" is not a good name, I could probably change them toDRW_cache_light_inner_circles_get()
,DRW_cache_light_outer_circle_get()
? Then I will also adjust it in the commit message.@ -4402,6 +4402,11 @@ static void rna_def_space_view3d_overlay(BlenderRNA *brna)
prop, "Extras", "Object details, including empty wire, cameras and other visual guides");
RNA_def_property_update(prop, NC_SPACE | ND_SPACE_VIEW3D, NULL);
prop = RNA_def_property(srna, "show_light_colors", PROP_BOOLEAN, PROP_NONE);
I am not sure if coloring the light should be default. Currently it is disabled by default.
@ -1513,0 +1557,4 @@
return SHC.drw_light_point_lines;
}
GPUBatch *DRW_cache_light_sun_lines_get(void)
Now this poor function only draws the light direction, not sure if we should rename it. I was considering adding a function that only draws the light direction because it is shared by other light types, but then other light types also draw clip start and end, so they are different.
Maybe
DRW_cache_light_sun_rays_get
is more descriptive. I think it is ok to leave it only draw the rays.The other function
DRW_cache_light_icon_sun_rays_get()
draw the rays. (I could delete the word "icon" if it's inappropriate).What's left of this
DRW_cache_light_sun_lines_get()
only draws the direction line.WIP: draw light icon using the light colorto draw light icon using the light colordraw light icon using the light colorto Viewport: draw light icons using the light colors3ddb17c59e
toe375b9714b
@ -639,0 +643,4 @@
float light_color[4] = {1.0f};
const bool show_light_colors = vedata->stl->pd->overlay.flag & V3D_OVERLAY_SHOW_LIGHT_COLORS;
if (show_light_colors) {
copy_v3_v3(light_color, &la->r);
I am unsure about using the light color as is. I think it should be normalized.
For instance, a light with color
(0.0, 0.01, 0.0)
at really high power will still give a powerful green.Not sure about getting into such details, because different light types with the same power could have quite different perceptual strength, it also depends on the size/radius and the spread of the light, a lot of things need to be considered.. we could do this in another commit if needed.
Maybe there is a misunderstanding: I'm not asking about taking light perceptual intensity into account, I'm saying that the color should be normalized as it is the "tint" we are interested in for display. Having a nearly black light overlay makes zero sense to me.
I'm just asking to replace
copy_v3_v3(light_color, &la->r);
bynormalize_v3_v3(light_color, &la->r);
.For the record: Today I discussed this with @weizhen and @fclem and we decided to go with the non-normalized display for the time being. If many users struggle to find their lights, we can still look into normalization (or other ways to make the overlay more visible).
Talked IRL to Andy about the pros and cons of each approach.
The outcome is that the current behavior (not normalized) is more intuitive and can be used as a way to replace a "custom light overlay color" without having to set a different property. It isn't quite correct but it is practical.
We might tweak the behavior after the initial implementation.
We also discussed about making the lines bigger. We could do that by doubling the lines a bit like the armatures axes points are using tons of lines for their axis end dot.
Anyway the patch is good as it is. 👍
e375b9714b
to4508c6fc6e
4508c6fc6e
toaa4201dc7f
Committed as
6fbc52bdca
Pull request closed