Add a Trail2D node

[ettiSurreal]

Describe the project you are working on

Various simple test games.

Describe the problem or limitation you are having in your project

Godot doesn't have a built-in line trail node, meaning you either need to code your own or use someone else's implementation. Particle trails do not work for use cases that require following an object.

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

A simple Trail2D node that inherits Line2D, it would be a simple line trail that follows the position of the node. Mainly used for trails that follow a node/object, like a projectile or the player.
It might also be nice to be able to preview the trail in the editor by moving the node around.
Additionally, when/if a Line3D node is added, a Trail3D node would also have to be made.

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

Implementation based on https://github.com/OBKF/Godot-Trail-System, since it's close to the implementation in Unity.

Everything regarding the visual itself is controlled in the Line2D part of the node.
Trail2D has the following settings:

• Emitting [Default ON]: Whether or not new points are being added, doesn't remove existing ones.
• Lifetime [Default 1.0]: The time after which the points are removed, setting it to 0.0 makes the lifetime infinite.
• Min Distance [Default 5.0]: The distance in pixels the trail must travel in order for a new point to be added.
• Max Segments [Default 0]: The max amount of segments of the trail, if the amount of points exceeds this value, the oldest ones get removed regardless of lifetime. Setting this to zero makes the segment amount unlimited.

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

A simple 2D trail system isn't too difficult to code, and there are already good solutions made by the community. But i believe trails are something that's very commonly used.

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

I believe trails are something that's used commonly enough that making a simple built-in solution could be worthwhile. There are already examples of this in Godot such as PathFollow2D/3D.
Additionally it it might perform better than a GDScript implementation for a large amount of trails.

[clayjohn]

Are you aware of particle trails in Godot 4.0? An example can be found in the PR implementing them here godotengine/godot#48894

I have a feeling they already meet the needs in this proposal

[ettiSurreal]

Are you aware of particle trails in Godot 4.0? An example can be found in the PR implementing them here godotengine/godot#48894

I have a feeling they already meet the needs in this proposal

Forgot to specify the use cases/how they exactly work, edited the main post.
Also particle trails are only limited to GPU Particle systems (cant use in compatibility) and overall need a bit of improvement, but that's for another proposal.

[Calinou]

Can't Line2D already be used relatively easily to create a Trail2D node?

[ettiSurreal]

Can't Line2D already be used relatively easily to create a Trail2D node?

That is very much true, i even state that it would just be inheriting Line2D for it's visual. The idea behind this proposal is that trails are probably something that's used commonly enough that making a robust drop-in solution could be worth implementing.
Besides coding more advanced features for the trail, like smoothly adding and removing points is a non-trivial task.

[QbieShay]

After spending time at work to implement a trail, YES.

Trails are sorely needed and particles trails don't work as trail replacement because they need to have a lifetime, while the usecase for trail doesn't overlap.

I was the person pushing for particle trails and it's great we have them, but they don't cover all the usecases for trails.

Additionally, like @ettiSurreal says, smoothly adding points and sliding the trail across the length is very complicated and it's unrealistic to expect users to write their own solution. We should probably discuss a node3d and a node2d that work in a similar manner. it's definitely a hard piece of tech.