this post was submitted on 02 Oct 2023
32 points (100.0% liked)

Godot

6020 readers
33 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

!roguelikedev@programming.dev

Credits

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
Feyter@programming.dev
32
Path based terrain? (suppo.fi)
submitted 1 year ago by Bezier@suppo.fi to c/godot@programming.dev
8 comments fedilink hide all child comments
 

So I've been working on this concept for a bit. The goal here is to make my game's terrain and roads in-engine, so that geometry, object spawns, traffic paths, and such are generated automatically. I'm posting this both because I wanted to share this, and to get opinions and advice.

Spoiler: more pics

Current challenge:
I have restarted this a couple times, trying different approaches. For the current iteration I have decided that I need to build the foundation properly before I bring in anything from the above screenshots.

The foundation:

The idea is to create a network of path and intersection nodes, to which I can add modifiers, such as road generator, mesh deform, or object spawn. Managing connections via editor tree became a pain very fast.

Now I need to figure out how to connect these easily, preferably via the viewport, by just dragging the path handle over the intersection handle. Any tips?

top 8 comments
sorted by: hot top controversial new old
[–] TsarVul@lemmy.world 3 points 1 year ago* (last edited 1 year ago) (1 children)

Maybe you can devise a custom gizmo for the spline nodes in your network graph. So each gizmo has an Area3D which monitors for a collider in the intersection nodes, and registers a connection when hovered over said intersection. You give two of the these gizmos to each of your ~~intersection~~ spline nodes for start and end, and you're gucci.

[–] Bezier@suppo.fi 2 points 1 year ago

Yeah, I'm trying custom gizmos, but I'm having a hard time figuring out how to detect if I'm hovering over a something when committing a handle.

[–] Feyter@programming.dev 2 points 1 year ago (1 children)

Ok so if I understood correctly you want to have one Node(of type Path3D or Curve3D) that will be used to generate a street from a given staring point to a given end point. And a second type of Node that should be handling intersections of a road?

My initial idea would be to have a area3D note for the intersection node and a area3D node as the start/endpoint of the path.

Then using the area_entered signal in the intersection area to detect if a path start/end was connected...

I have no experience of how well all of this will work in an tool script but this would be my starting point.

PS: after thinking twice about it. Why would you want to have a distinct intersection node? I think simply having a start and a endpoint of a street that can be connected to a different start/end point of a different street (or even the same to make a circle) should be enough.

[–] Bezier@suppo.fi 1 points 1 year ago* (last edited 1 year ago) (2 children)

Thanks. I actually tried Area3D, but it wasn't ideal.

  • I had to turn on physics in the editor.
  • Enter/exit are called when loading and saving the scene, and when moving either node.
  • It's not enough if the areas line up in viewport, since it's a 2D representation of a 3D scene.

Why distinct intersection nodes?
This division seems the most sensible option for geometry generation. Intersection stuff is contained in one node instead of being divided between all connected paths, and path modifiers are also simpler, because they only have to care about the path.

[–] Feyter@programming.dev 2 points 1 year ago (1 children)

Ok I guess we are talking about the same idea here. Having one node that handles "connection" and a different note handling the course of the street.

I would only argue that a connection with only on road connected should be able to exist in order to create a dead end. But don't know if this would make sense for your specific gameplay.

I'm sorry I can't help you any further here, but maybe someone else will have an idea.

[–] Bezier@suppo.fi 2 points 1 year ago* (last edited 1 year ago)

You mean capping dead ends like this?

spoiler
It's not really an issue, since adding an intersection is (supposed to be) easy, and I'd have it there regardless if I wanted to generate land patches around it, like in the post image.

Thanks anyway, though!

[–] Feyter@programming.dev 2 points 1 year ago (1 children)

I mean the workaround would be to have something like a Array defined as an export variable and "drag and drop" the nodes you want to connect in the inspector?

But I think you already had something like this in place?

[–] Bezier@suppo.fi 2 points 1 year ago

That was the initial approach, but finding the node in the list became way too much effort very quickly.