Add Debug -> Visible Markers option

[danboo]

Describe the project you are working on

Current project is a 2D pixel-perfect platformer.

Describe the problem or limitation you are having in your project

I often lose track of where sprites are anchored. Though their general screen position is obvious, their precise positions and anchors are difficult to locate. The current solutions are:

• use the remote scene tree view to locate them and lookup their position attributes
• manually add a custom gizmo at their origin

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

By making Marker2D nodes visible via the Debug menu, I can use the "Change Type" option on a Node2D node to get insight into its position at runtime. If the anchor node is not a Node2D node then I can just add a Marker2D as a direct child of the scene's root node.

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

A "Visible Markers" option will be added to the debug menu.

When running a scene that contains a Marker2D or Marker3D node, that marker will be visible at runtime.

I have a reference implementation of this feature for Marker2D nodes. I can extend it to Marker3D and submit a pull request if this proposal is accepted.

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

This will be used often.

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

I am unsure how to implement this behavior (affecting the visibility of Marker nodes at runtime) as an add-on.

[TheDuriel]

This makes me think that a enhancement on top of this would be "Visible Origin", for 2D and 3D both. Which simply draws a point of the origin of every node in the tree.

At the same time, this can in 2D already be achieved with a custom class. You only have to set this up once.

class_name DebugPoint
extends Node2D

func _draw() -> void:
if engine.debugmode: # This is pseudo code. But there is a simple way of getting this.
draw_circle() # a single red pixel or something

3D is a tiny bit more complicated, and there'd possibly be an actual performance impact drawing a bunch of circles.

Heck, while we're at it. "Draw Bounding Boxes"

[Mickeon]

This makes me think that a enhancement on top of this would be "Visible Origin", for 2D and 3D both. Which simply draws a point of the origin of every node in the tree.

It may sound good, but in practice it would be such a mess of draws, that it would be incredibly difficult to discern what Marker belongs to what. I feel like the proposal is much better, as it allows you to choose what to see by just adding the Markers as children of the interested Nodes.

[TheDuriel]

Yes, it could be a mess. Just like wireframe view is a mess. But it's still useful. And something I frequently find, as an avid speedrunner and glitch hunter, in other games when exploring their debugging functionality.

Also with how Godot nodes are often used, I think it'd be a lot less of a mess than you think. Any given game object or construct might consist of a dozen nodes, but they're all in the same spot.

[danboo]

As a quick test, I implemented the idea @TheDuriel mentioned about making all node origins visible. I did this with a quick copy/paste of the _draw_cross() method from Marker2D to Node2D just to get an idea of what it would look like in a couple games.

This is an example from a relatively simple scene without many visible nodes:

This is an example from a more complex scene with more visible nodes:

I like this effect in the first example as there isn't much noise, and it nicely shows the node positions, but I see how it can get quite noisy when many nodes are on the screen at once. This tends to make me favor the original approach using Marker2D nodes, giving more control over which are visible.

An additional benefit of using Marker nodes is that it would combine well with other potential efforts to improve Markers (#1009).

[TheDuriel]

I would like to add that, yeah the Position2D marker is a huge mess. And I was more thinking of a much smaller dot/square. I don't imagine that'd be nearly as problematic as this. Given that the 2D editor already implements a subdued very small white cross.

[Mickeon]

It shouldn't be too difficult to improve Marker2D/3D's looks. And perhaps someday these Nodes could have some features added to them that specialise in debugging, easy visualization and modification without needing extensions.

[dalexeev]

I had the same idea. With this option, Marker{2D,3D} nodes will at least make some sense, since they are not much different from Node{2D,3D} for now.

I have a reference implementation of this feature for Marker2D nodes.

Looks good.

I can extend it to Marker3D and submit a pull request if this proposal is accepted.

Yes, I think this option should be shared between 2D and 3D, this is consistent with the rest of the debug hints.

[danboo]

I just wanted to add that I did end up making a proof of concept implementation of the idea of a marker with more features that was visible during game execution.

[2-3-5-41]

Just putting in my two cents; I have to wonder what the purpose of the Marker2D/3D nodes are if they are only visible debug visuals in the editor, but not in the debug release of a game. Sometimes you only need a debug marker that isn't a physics shape, or a full mesh instance when debugging positions of things that shouldn't be visible in runtime.