Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce visual clutter from lights and probe gizmos in the 3D editor #6564

Open
WickedInsignia opened this issue Mar 24, 2023 · 4 comments
Open

Comments

@WickedInsignia
Copy link

Describe the project you are working on

Graphics testing scenes for engine development.

Describe the problem or limitation you are having in your project

Godot's lights and probes are extremely clutter-prone in the 3D viewport. They show their direction, bounds, range etc. at all times, and obscure darker scenes very easily. It's not practical to keep turning gizmos on/off when legibility is needed, when we simply don't need to see all this information all the time:

LightRangeUI

Here's a screenshot from Unreal for comparison. This scene contains a dozen reflection probes and 3 lights on-screen, which would easily become cluttered in Godot:

UnrealUILegibility

Unity and Unreal have some sensible solutions to viewport clutter, and it's worth focusing on the ones that Unity employs as Godot's nearest neighbor in the game engine space.
Reflection probes are a simple orb icon, which when clicked will show their full bounds and sample point:

UnittyReflectionProbeUI

Lights are simple icons without any range information until they are clicked, that will scale smaller as the camera moves away:

UnittyLightUI_Size01

UnittyLightUI_Size02

Lights will also turn transparent when hidden behind objects:

UnittyLightUI_01

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose these solutions, which are already industry standards utilized by Unreal and Unity:

  • Only show light range/direction/angle when a light is selected.
  • Unselected lights should appear as simple icons that scale depending on the camera's distance from them.
  • Reflection probes should appear as simple icons until selected, at which point their full controls are made available.
  • Apply this UX standard to every similar case, such as collision meshes and other editor-specific objects. Controls or bounds should only be visible in the appropriate context, such as when selected for inspection.
  • Consider adding an option to show light icons transparently through objects, since Godot's default behavior here isn't problematic and it's probably best that this is left to preference.
  • Add an option to easily turn gizmos on/off as an icon in the viewport taskbar. This would save digging through the Perspective menu when further legibility is needed.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

See above

If this enhancement will not be used often, can it be worked around with a few lines of script?

No

Is there a reason why this should be core and not an add-on in the asset library?

Core engine functionality

@WickedInsignia WickedInsignia changed the title Mitigate Visual Clutter from Lights and Probes Reduce Visual Clutter from Lights and Probes Mar 24, 2023
@Calinou Calinou changed the title Reduce Visual Clutter from Lights and Probes Reduce visual clutter from lights and probe gizmos in the 3D editor Mar 25, 2023
@Calinou
Copy link
Member

Calinou commented Mar 25, 2023

I think it makes sense to hide radius gizmos for unselected Light3D and AudioStreamPlayer3D nodes.

Apply this UX standard to every similar case, such as collision meshes and other editor-specific objects. Controls or bounds should only be visible in the appropriate context, such as when selected for inspection.

Not being able to see bounds for unselected nodes can be problematic in some scenarios though. For instance, if you're resizing a ReflectionProbe based on nearby ReflectionProbes' extents (so that every part of your level is covered by at least one probe), you need to see unselected ReflectionProbes' extents. This also applies to nodes such as VoxelGI.

A middleground solution would be to only display unselected nodes' gizmos if they're of the same type as the currently selected node.

Consider adding an option to show light icons transparently through objects, since Godot's default behavior here isn't problematic and it's probably best that this is left to preference.

The x-ray gizmo mode in the View > Gizmos menu already does this, although it affects both the icon and the lines material:

image

This also doesn't display occluded icons/lines with half opacity, but this requires a dedicated material for each gizmo to be done (similar to what the 3D selection box currently uses).

@WickedInsignia
Copy link
Author

Allow the extents to be viewed/edited for all selected reflection probes in that case. In practicality this isn't an issue though, since probes blend pretty seamlessly as long as they overlap to some degree. When no blending is present, there's already a hard and visible edge between the sky reflection and the probe's extents.
Voxel GI bounds also add a great amount of visual clutter and aren't utilized to the same frequency as reflection probes.
There's no reason to see this information in objects you aren't currently editing since there are enough visual cues when an object is outside their range of effect, and it's easy enough to select multiple objects via the outliner to check.

Godot really doesn't offer an advantage with the current approach, the visual clutter from these features is incredible in comparison to Unity/Unreal.

@Calinou
Copy link
Member

Calinou commented Mar 25, 2023

I've created a project with most 3D nodes that display gizmos: test_3d_gizmos.zip

I've also toyed around with a solution that hid gizmos for all unselected nodes, but I feel it's confusing for nodes that don't have large gizmos (such as RayCast3D or VehicleWheel3D).

@WickedInsignia
Copy link
Author

I'm most familiar with the way reflection probes/lights work in other engines, so the other objects will likely come down to case-by-case proposals by others with more experience in them.
I would argue that collision meshes should only be visible when selected though since they could populate a scene fairly quickly. A setting to show all might be required for collision troubleshooting, but I've never had the need for that arise myself. I generally only needed to determine if collision was incorrect when placing it.
There's also the issue of manually-placed lightmap probes, which tend to work as object groups in other engines rather than individual probes. This is due to ease-of-use, since a unique node for every single probe can become impractical when hundreds are being utilized (alarmingly commonplace, especially in fully lightmapped scenarios). Easy enough to work around by grouping them under a Node3D, but I'll experiment with this and open a unique proposal if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants