godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.17k stars 98 forks source link

Only render gizmos with a fixed size when they are close by to improve visibility #10018

Open HerrSersch opened 5 months ago

HerrSersch commented 5 months ago

Describe the project you are working on

A 3D adventure game.

Describe the problem or limitation you are having in your project

Gizmos are always rendered with a fixed size on screen, regardless of their distance to the camera. This adds a lot of clutter to the screen and hinders editing. Large parts of the level can't be seen inside the editor anymore unless I get close to the location I'm working on.

Related issues: #8220, #6564

Currently, the only solution is to temporarily hide all gizmos or turn the obstructing gizmos off to see better. But this approach quickly turns into a constant chore, because I generally do need to see the gizmos, just not the ones far away.

gizmo_clutter

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

Gizmos should only be rendered with a fixed size if they are close to the camera. Otherwise, they should become smaller in the distance, like regular objects.

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

Here's an example from the Unreal 4 engine. Gizmos become smaller in the distance like regular objects, but when the camera is very close to them, they are rendered with a fixed screen size, which prevents them from filling up the entire screen.

https://github.com/godotengine/godot-proposals/assets/35151158/f96bd309-1ffb-4267-853a-bd643729afaa

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

No, this is a core feature of the editor that can't be scripted.

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

Yes, because it affects the basic usability of the 3D editor.

Calinou commented 5 months ago

I agree with this in principle, but making this work in all projects is nontrivial. The issue about this is defining the distance threshold. The distance threshold for a small-scale 3D game won't be the same as for a planetary-scale 3D simulation. We could make it relative to the editor camera's Far property as a reasonable default, but it'll surely need an editor setting to define a multiplier for the automatically determined distance.

Also, implementing this will require an addition to the BaseMaterial3D shader so that Fixed Size can be made to only apply starting from a certain distance to the camera. Alternatively, we need to make 3D editor icon materials use a custom ShaderMaterial instead of relying on BaseMaterial3D.

HerrSersch commented 5 months ago

These are really good points. Adjusting it via the Far property and an additional editor setting sound good.

Also, implementing this will require an addition to the BaseMaterial3D shader so that Fixed Size can be made to only apply starting from a certain distance to the camera.

Would that add any overhead to the BaseMaterial3D for the 99.9% of cases where this feature is not used? The compiled shaders only contain the paths that are actually in use, right?

Maybe a minimal size could come in handy too. The BaseMaterial3D could then be used for in-game HUD-style markers that keep their size within certain bounds but are still affected by the player's distance between those bounds. This way it's a useful addition to the material in general and not just added to fix this one special case.

Calinou commented 5 months ago

Would that add any overhead to the BaseMaterial3D for the 99.9% of cases where this feature is not used? The compiled shaders only contain the paths that are actually in use, right?

Yes, but we still need to be careful about UI complexity in the inspector (unless we choose not to expose the property that enables this to scripting).

Having minimum size exposed as well would this functionality more viable to expose to users, as there would be more of a reason to use it in projects as you mentioned. This would be interesting for Label3D as well.