Open ettiSurreal opened 1 year ago
- Removal of
Sections
, they are now controlled by the node the resource is assigned to.
A mesh resource can be assigned to several different/unrelated nodes at once. How can you keep track of this within the mesh resource?
- Possible removal of
Section Length
, i do not think there are any use cases for that, and it most likely just causes confusion, please let me know of any use cases.
I agree with removing the section count (or section subdivision), as it always felt like a second way to achieve the same thing to me (i.e. changing the detail level).
- Removal of
Sections
, they are now controlled by the node the resource is assigned to.A mesh resource can be assigned to several different/unrelated nodes at once. How can you keep track of this within the mesh resource?
Admittedly my understanding of everything is still very limited, but here's an abstraction of how i imagine it working
The sections
are the "points" of the mesh and the amount and transform of them is controlled externally by the node it is assigned to, such as Line3D
and the GPUParticles3D
trails. Everything else like the width and curve is shared across every node that the resource is attached to.
I am not sure how doable this is in the engine at the current point in time and i definitely don't know how to implement something like this myself, but sharing the same resource between Line3D lines and particle trails seems more optimal because of how similar they are.
Line3D ... Trail for me is two different things. CSGPolygon3D on fallow path mode is for me already a 3D line. If the staff merge this PR https://github.com/godotengine/godot/pull/61424 that will be mostly the same thing that what the line2d do, for 3D.
But maybe, We should move the CSGPolygon, including the fallow path mode to a new line3D node. That will be a MeshInstance3D. If we want to use this mesh as CSG, that will be easy. If we don't want break the actual CSGPolygon, we should be able to call from CSGPolygon the line3d and get the mesh to convert it to csg. Simulate the actual path fallow from the line3D class.
After that, I think we should have a new separate node, the Trail3D. Because the purpose is completly different that a Line3D. This trail node, can be inherited from the Line3D fallow path mode.
Hi all, just wanted to share this shader I made which might help with achieving the goals of this proposal.
Basically it does all the billboarding math in a vertex shader. The CPU side only has to supply points and tangents (easily calculated).
I do not believe any existing feature in Godot has a similar effect. I tried to replicate Unity's behaviour, but it's actually more stable, as you can see here:
There are a couple requirements for this to work:
I'd be happy to share more if we feel like this will be useful.
Did some additional investigation: In the trail use case, or other use cases with relatively high segmentation, this shader produces better results than Unity. But, in use cases with extremely low segmentation, it looks worse.
However, this is something we can work around with artificially introduced "corner vertices". Just one extra vertex seems to be enough to mitigate this issue. But of course, there's also the chance the vertex shader can be improved to prevent "twists" in these edge cases.
@MajorMcDoom Can you share the shader on a site such as godotshaders.com ?
@MajorMcDoom Can you share the shader on a site such as godotshaders.com ?
Seems like various parts of GodotShaders have been down for a day now, including registration and uploading, so I'm just gonna attach a zip with some files. :)
There are three files:
line_3d.gd
: This is the class that lets you manually specify points and connects them. Inherits from MeshInstance3D
.trail_3d.gd
: This inherits from Line3D
and adds trail functionality (related to #7082)line_3d.gdshader
: This is the shader that does the billboarding.This was all implemented to just a "good enough" level for my own game, but I'm just providing it here as something we can maybe test and iterate with. The actual implementation I think should support any user material/shader, with the billboarding happening "outside" somehow. I think this can be achieved either as part of the GLSL generation, or as its own base shader type, maybe.
Disclaimer on the provided tech:
Material Override
of the GeometryInstance3D
line_3d
shader.A year later, rewrote most of the proposal to be more to the point, took out the part about combining this with the existing TrailMeshes
(the idea behind this was just code reuse since it seemed "close enough").
@MajorMcDoom This is so much appreciated, thank you!
Godot Next provides a Trail3D node type which can be used for 3D lines: https://github.com/godot-extended-libraries/godot-next/blob/master/addons/godot-next/3d/trail_3d.gd
Hi all, I added an updated version which fixes some bugs and adds some new features (like texturing). It's in the form of an addon folder this time, in a GitHub repo. Hopefully it'll come in useful for whoever implements this proposal.
https://github.com/CozyCubeGames/godot-lines-and-trails-3d
New features:
It also comes by default with a material assigned now, and you can also use the MeshInstance3D
's surface material override instead of just the GeometryInstance3D
's material override.
Related: https://github.com/godotengine/godot-proposals/issues/5196_
Describe the project you are working on
Mainly testing features and making small test games for fun.
Describe the problem or limitation you are having in your project
A lack of a 3D equivalent of
Line2D
, or any sort of 3D line drawing functionality.Describe the feature / enhancement and how it helps to overcome the problem or limitation
A
Line3D
node, with the same functionality asLine2D
, and more to make it truly versatile for 3D, since at heart it's just taking a few points in 3D space and drawing a mesh between them, which can be used for many different things such as:Path3D
sDescribe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Would be defined by a
PackedVector3Array
, of course.Line3D
should have feature parity withLine2D
, having options for:Width
, and aCurve
for it, would separating X and Y be worth it?Closed
propertyCapping
andBorder
Gradient
andTexture
should be covered by shaders, might needTexture Mode
to determine if UVs tile or stretch?Line3D
Specific settings:Mesh Mode
:Ribbon
: Simple strip, meant for billboarding, but can be used without itRotation Offset
: Rotates the strip, only effective when not billboardedCross
: Two strips intersecting each other at 90 degree angles, meant for when billboarding is not an option for one reason or another.Rotation Offset
: Rotates the cross.Tube
: A tube/cylinder, meant for cables and large trails where you could see a line is flat with ribbons/crosses.Segments
: The resolution of the tube.Direction
:Follow
: Faces are rotated along the line, equivalent toPathFollow
fromCSGPolygon3D
Custom
: all faces face a specific direction, defined by aVector3
.If this enhancement will not be used often, can it be worked around with a few lines of script?
It's a relatively major feature, and far from beginner friendly to code (very intimidating).
Is there a reason why this should be core and not an add-on in the asset library?
Line2D is in core, and no way to do the things it does in 3D out of the box.