Godot-proposals: Improving Position3D and Position2D identification

Created on 4 Jun 2020  路  8Comments  路  Source: godotengine/godot-proposals

Describe the project you are working on:
Not project related, could apply to any 3D or 2D games.

Describe the problem or limitation you are having in your project:
Position nodes are meant to help in the editing process. When dealing with many of them, it becomes quickly a mess to know which one is which. Therefore, the more you use them the less they are useful.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
To help with this issue, the Position nodes should become visually identifiable by:

  • Making possible to change their color, for example enemy spawners are red, starting position is blue, items spawners are green, ...
  • Making possible to display the Position node's name beside the cross, for example LeftWheelAttachment/RightWheelAttachment, EasyEnemySpawner/HardEnemySpawner, ...

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
It would be easy to use by:

  • Adding a color properties the the Position nodes to change their visual appearance.
  • Adding an entry in the View menu viewport to enable/disable showing the name beside the cross

If this enhancement will not be used often, can it be worked around with a few lines of script?:
I don't think this could be done easily in script.

Is there a reason why this should be core and not an add-on in the asset library?:
I think this should be core because it is a very basic feature that would help making the Position nodes more useful for everyone.

core

Most helpful comment

It might also be a good idea to refactor Position2D/3D into more generic Gizmo2D/3D nodes, to provide users with a wider variety of visual debugging tools. This would need lots of discussion though.

All 8 comments

Making possible to change their color, for example enemy spawners are red, starting position is blue, items spawners are green, ...

In 2D this is already possible with modulate (or self_modulate)

Making possible to change their color, for example enemy spawners are red, starting position is blue, items spawners are green, ...

In 2D this is already possible with modulate (or self_modulate)

You are correct but here my arguments still in favor of a dedicated color property:

  • It is more obvious to new comers how Position2D can be used.
  • It would be more consistent with Position3D.

I have similar issues with the way Position3D is displayed:

  • it uses the same colors of the gizmo making it difficult to see them
  • it has tiny and short lines that when aligned with the grid are even less noticeable
  • it has depth culling as any objects, many times you'd like to see the points even if hidden by other objects

In general it'd be cool to implement internally an unified way to display/control point entities from this one to possibly vertices in a mesh. It would be used by the editor and plugins, possibly with shared functionality between 2D and 3D implementations.
For example we have entities like the lights and camera that have an icon with depth culling and scales based on how far you are from them in the view, the 3D position has a cross with depth culling and scaling as a normal 3D object, control nodes like in Path or CSG entities have icons without depth culling and fixed screen size.

See https://github.com/godotengine/godot/pull/28390 where a project setting was added to configure Position2D appearance. This can likely be used as inspiration for future PRs.

I'm not sure what the consensus is now, but adding more properties to Position2D/3D may be hard to justify (see the lengthy discussion in that PR).

It might also be a good idea to refactor Position2D/3D into more generic Gizmo2D/3D nodes, to provide users with a wider variety of visual debugging tools. This would need lots of discussion though.

It might also be a good idea to refactor Position2D/3D into more generic Gizmo2D/3D nodes, to provide users with a wider variety of visual debugging tools. This would need lots of discussion though.

Try to keep the topic focused on this specific proposal. If you have other ideas, post your own proposals. It helps with the efficiency of the discussions.

I agree that the goal is to have a default style that is good enough to be identified, selected with the mouse, moved and to some degree customizable.
To not add to much settings inside the scene/editor i'd do this: if the class used to render the entity in the editor still provides some other settings (like changing how big is, thickness of lines, etc) one can always create a small plugin in GDScript to change the parameters. If the look will change again in the future one can always customize changind the script (if still wants to of course).
For example if you could change the color but in the editor is not possible to do it, a plugin could set a custom color depending on some data attached to the node, isn't it? An icon or whatever the class supports internally.

Related to #906 (as it's also about adding more editor-only properties).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Dorifor picture Dorifor  路  3Comments

lupoDharkael picture lupoDharkael  路  3Comments

SleepProgger picture SleepProgger  路  3Comments

Xrayez picture Xrayez  路  3Comments

SpyrexDE picture SpyrexDE  路  3Comments