Implementing road edge curves

[bdog2112]

This is a WIP of road edge curve functionality.

[bdog2112]

Start with a basic road scene, select the RoadContainer, and check the "Create Edge Curves" checkbox in the Script Variables. Then, save and reload the scene.

Edge curves are displayed at a default distance from each RoadSegment's master curve. This is a work in progress...

[TheDuckCow]

Hey @bdog2112 thanks for sharing the early preview! Already great to see something coming together.

Not reading into anything much given the WIP status - I figure these following items are already in your plan but just to mention them:

• I gather it's a static number of lanes offset so far, like it's a 3x2 or 3x3 reference approximately?
• I notice that all edge path nodes are deleted and re-added on each transform, instead of re-using the path nodes that pre-exists. The result is that any 3D editor children get deleted (see here as I attempt to use the CSG node for adding a sort of barrier, but gets deleted on a transform). To be clear, there's no problem with clearing and re-assinging the Path3D.curve objects, as long as the Path3D node itself is left in place.

https://github.com/TheDuckCow/godot-road-generator/assets/2958461/ad17b032-9618-4bbd-9477-89fcd075b323

[bdog2112]

Just pushed an update. Deets can be found here.

[bdog2112]

Pushed latest WIP. See notes here.

[bdog2112]

Incorporated road width into edge curves. Please have a looksee and provide feedback.

In this implementation, offset calculations are simple and the result is that the edges don't always tightly hug the edge of the road. But, they're close. This is merely an offramp if you want to move on to a different issue. Let me know if you want something more precise.

I think the next step is to spend a little more time, increase complexity, and calculate the number of Forward and Reverse lanes, separately. Then calculate distinct and different offsets for each side of the road. I'm pretty sure that will make the edges match the road contours more closely.

(To provide a little more context: Edge offsets are currently calculated from the center of the road even when there are transition lanes. For greater accuracy, we could calculate offsets from the center lanes versus the center of the road.)

Let me know how you want to proceed.

[bdog2112]

I'm still trying to wrap my brain around this. I think we're up against the limits of the current curve algorithm. The only way to get more accurate edge curves is to revamp the algorithm.

[TheDuckCow]

Hey @bdog2112 I'd say this is in a really good spot, certainly sufficient for now. I haven't come across any discrepancies that are that bad, though maybe you have a specific edge case/worst case scenario in mind that is worth sharing. My testing with it:

https://github.com/TheDuckCow/godot-road-generator/assets/2958461/ac047607-e1b2-4f62-a121-5f22ad67e2e9

(btw, people seem excited about this - check out the previous post I made here)

Curious to hear about your worst case scenario (not including just typical bezier pinching, which we knew would be a limitation). And otherwise, I'd say this is ready to mark for review, though I don't expect to add that many comments.

[bdog2112]

Your image, above, depicts my worst case scenario. Lane transitions can be a little off at times. But, they can also be spot on. Given the nature of the CSG Polygons, all one has to do is increase the overlap between the CSG and the shoulder and, in most cases, boom: Problem solved!

[TheDuckCow]

Ah got it, yup I agree - by design, users can force a little more overlap if they want when it comes to placement (either by CSG, or via their own custom scripts to distribute objects along a curve via multimesh, which is what I expect we'll end up doing).

One question for you - at this present moment, how hard do you think it would be to create another curve which is intentionally just the center line matching the double yellows? I realize that this, too, could be useful for barrier making in some cases. If you think it would take less than say 5 hours, I'd say we could prioritize that as a follow up task (=another PR anyways). Otherwise, I'll put it into the backlog

[TheDuckCow]

Though I'm less concerned about the shoulder overlap since the user can attempt to modify with an offset, I'm realizing we might be having more troubles with little gaps between the segments. In the screenshot below, this was accentuated by having a "Path Interval" size of 4 on the CSG which means there would be fewer loopcuts to be more performant, but it increases this gap.

Reducing interval to 1 (but also creating 4x geometry for what otherwise looks about the same other than a substantially reduced "sliver"):

This isn't a dealbreaker for right now. When I tried to manually "correct" the curves such that the CSG edges would close and overlap, I had to really over-bend the the curve end (thus also affecting the offset approximation in the first place). So, it's probably just a limitation of CSG path following. Which is one of the original reasons we had to create this Road Generator in the first place 🤷‍♂️

[TheDuckCow]

I'll additionally add: the best possible way to solve this, actually, is our later goal of making one continuous curve that goes along an entire (continuous section of) RoadContainer. So, all the more reason to not fiddle with this for now.

[bdog2112]

One question for you - at this present moment, how hard do you think it would be to create another curve which is intentionally just the center line matching the double yellows?

We have the "edge" curves. Hence, we could totally add a "center" curve. (Albeit, not really the center.) Barring anything unexpected, 5hrs is probably enough to get it working.

We'll need rules for handling one-lane roads. That's the only unusual scenario I can think of at the moment.

[bdog2112]

Regarding "center" curves, there is some question as to how we should implement this.

Users select a RoadContainer and click the "Create Edge Curves" checkbox to show edge curves. Do we want a separate "Create Center Curves" checkbox or do we simply want to implement center curves as a so called "edge curve"?

In other words, when users enable edge curves, should we give them 3 curves: 2 edges and 1 center?

[bdog2112]

Per our discussion, I will implement "center" curves as part of the "edge" curve functionality.