Proposal for Road Containers

This post is a proposal that helps enable intersections, hand-crafted scenes (puzzle piece road segments), as well as improve the usability of larger road networks.

Current problems

We want to create intersections, but so far the idea has been that intersections are either fully hand crafted scenes or procedural geometry meshes, containing multiple RoadPoints as children. And yet, these intersections would need to be siblings of other RoadPoints in the network (so RoadPoints would be at different hierarchical levels).
It’s weird to think how to create prefab scenes of road segments would fit together. One the one hand, one RoadPoint going forward will “own” its own road segment, but if we want to turn that into a prefab scene, the source scene itself actually needs to contain at least two roadpoints itself, since the developer/artist creating that scene will need the anchors to show the start/end of that road semgnet, as well as be able to work with AI lanes and so forth. So duplicate roadpoints would be nested within RoadPoints and overlap once in the 3D scene? It doesn’t really make sense.
There’s also many limitations users will face in the current, very flat hierarchy. With the current setup you're either changing settings on the entire network level (e.g. material), or on individual segment level (e.g. to add railings). Most users probably want a more intermediate level of control instead of all or nothing.

A proposed solution:

Inspired by watching some of the generation tools other developers made in [Houdini here](https://www.youtube.com/watch?v=G5Iq-jxgZn0&t=1783s). The detail in particular I am taking away is that it’s very useful for both humans and computers to introduce an extra level of hierarchy within road networks.
Introduce the concept of a RoadContainer, alongside RoadIntersections
- RoadContainer: Contains all RoadPoints and geometry for one continuous road. Think of it like a named street
- RoadIntersection: The joining piece between one or more RoadContainers
An intersection is an extension of a RoadContainer, or at the very least functions pretty similarly.
Both RoadContainers and RoadIntersections are visible in the node hierarchy as a spatial, directly parented to a RoadNetwork and a direct sibling of all other RoadContainers & RoadIntersections
RoadPoints thus are universally children of these RoadContainers/Intersections - either via the direct scene, or from saved subscenes.
Now having either a procedurally generated or hand crafted intersection doesn’t matter, both would result in the same scene hierarchy, making code simpler and the concept easier to understand.
We would want to ensure that both RoadContainers and RoadIntersections allow for generation of the roads directly, even if in their own subscene.
- → So a crazy idea, maybe the current day RoadNetwork should be renamed to RoadContainer, and a new actual RoadNetwork object should be created at a higher level?
- This way it’s very easy to define materials for an entire road, since you might not want to do that for an entire road network (as it currently is set up).
- Then it’s really pivoting everything we have into multiple (current day) RoadNetworks connected to each other.
- Do we even need a RoadNetwork node? Aside from visual hierarchy (which is nice) -> Yes it's probably still worthwhile, since we might want network-wide operations including LOD level management and so forth.
How do RoadContainers connect to other RoadContainers or RoadIntersections?
- Under the hood, it should still be ultimately RoadPoints connecting to other roadpoints. But we could have the RoadContainer/Interseciton play the middleman. We could have it so that “edge” RoadPoints by default leave their connections empty in the parent scene, OR that they reference their parent as the egde. Then when instanced in a scene, they are just visualized as available to connect to.
- If we define an export array of NodePaths in the parent, the code of the RoadContainer could understand to (on runtime) auto connect in the same order as the unconnected children underneath (throwing warnings if there’s any mismatch).
- the editor tool part of this component would need to dynamically resize this array based on the child scene, so if you add an unconnected roadpoint it shows up as a connected, but if you connect one side of it, then one of those export vars goes away.
What about RoadPoints placed in the wrong position? We should give a warning label that they need to be direct children of Containers or Intersections.

Open questions

How does a user start creating a new road (RoadContainer) when an initial road is already placed?
How does creating an intersection work? If there’s no parent-most RoadNetwork, where does it get placed?

Pro’s of the proposal

Both RoadContainer’s and RoadIntersections could be easily defined as a prefab scene or directly in the current scene
- We were having a conceptual problem before where we wanted to have prefab scenes. The problem was that we couldn’t visualize roadpoint connections in a subscene without an entire road network, and that we’d have this weird situation of subscenes being directly adjacent and somehow connecting to manually added RoadPoints in the main scene hierarchy
- Therefore, any prefab scene would just be treated as a RoadContainer itself, containing one or more Segments.
RoadContainer could define all the styles and customization that someone would need, and some of the generated objects could span the entire length of the road
- We have another feature intent whereby we create curves that follow along the outside edge of the road, as well as the exact middle belonging to the median line (both would account for lane changes).
- With this new structure, we could actually make these curves continuous over the course of the entire road. Thus someone who wants to add railings or.
Consistency of treatment of RoadPoints: Regardless of how they are used (hand crafted scene, part of an intersection, or as one point along a procedural road), they are treated in a consistent way.

Con’s of the proposal:

The new RoadContainers are spatials, but their space is defined by the content they contain. So it’s ambiguous where they should be placed.
- Maybe they should just be “nodes” instead? But then that breaks the ability to easily hide children, which is something we ran into previously when we made RoadNetworks and the Points as Nodes instead (which we later changed to spatials)
- If we just put the RoadContainers at the origin (RoadNetwork pos), then it could start to lead to bad floating point calculations since there could be large difference in positions.
- Alternatively, we could define an “in” and “out” position of a road based on hierarchically it’s first RoadPoint, and always set that as the position. We’d thus introduce some restriction that the first RoadPoint of a Road or Intersection is always 0,0,0 to its parent (but what if the user moves it later? do we just let it remain at a random place, or do we try to refresh to update the RoadPoint origin to move back to the position of that first RoadPoint?)
If we define define curves that span the entire length of the road, it won’t work well for Wheel Steal since we are adding chunks at a time
- We could just make an option whereby these curves are generated optionally at the roadpoint or RoadContainer level. For wheel steal, we’d used the RoadPoint level and so we’d get new curves at each new roadpoint. We’d have to copy the segments though each time.
Someone building a road world from prefab segments will still have a flat hierarchy problem in the scene tree, unless we let them move structures around further.
- We could attempt to recognize when prefab scenes are RoadContainers with only 2 points and thus really part of the same continuous road, but what features would depend on that? Is it just for visual grouping or highlighting?

Misc feature ideas

We regardless still need a tool for connecting RoadPoints together, it just needs to handle the interface of RoadContainers now too.
Tool/ability to slice a road, so you can easily change the style halfway through (or, for instance, have a railing stop part way through).
Add a resources slot, which is populated by default with our own provided resource
- This resource could include some suggested attributes such as speed_limit, grip, and name (e.g. “4th ave”, or “I90”).
- Thus, developers could easily make their own resources to replace in which have their own needs.
Tools to export geo to obj, for easier editing in other 3D software or for references. E.g. if you mostly have the road you liie, but you need to do custom geometry on just one segment of it, can convert to obj, and then once you make a custom mesh, you can disable (on that RoadContainer only!) the instructions to generate geo, though keeping lanes etc.

Hey @bdog2112 FYI that I migrated and extended upon the private proposal doc over to this space. Still keen to hear your thoughts, but figured having a public place for discussion would also be useful

PRIMARY THOUGHTS: My sense is that we already have just about everything we need:

RoadNetwork is basically already a RoadContainer.
For all intents and purposes a creator should be able to add multiple RoadNetworks to a scene and each RoadNetwork could represent a single street.
RoadNetwork could require some modifications. But, the overall cost of this would be much lower than doing a major rewrite.
What's missing is the ability to connect two streets (RoadNetworks) together.
That could probably be addressed with small targeted changes to how RoadSegments are created and, perhaps, some subtle changes to RoadNetworks.
Some work is also needed in order to facilitate the interconnection of tiny road template scenes to form larger roads.
Lastly: RoadIntersections still need to be developed.
As it stands right now, there is nothing stopping a creator from placing a bunch of RoadSegments in close proximity to each other and then dropping a static plane into a scene to form an Intersection.
But, a more comprehensive solution is needed in order to facilitate traffic as well as any sort of auto-texturing.

SECONDARY THOUGHTS: Many of the discussed bullet points require a specific context. There are two main contexts for most of the issues:

Creating roads via code in the Wheel Steel Project.
Creating roads manually in the IDE.

It's important to know the context being discussed. At any rate, here are some additional thoughts and comments.

RoadContainer Coordinates:

Where should RoadContainers be placed in terms of coordinates? This simply requires an executive decision. First RoadPoint sounds good. World Origin also sounds good. Making them Nodes instead of Spatials also seems reasonable.
In the Wheel Steal game, will the roads always remain stationary or will the camera remain stationary at world origin while the roads move? This might be a key determining factor as to what is needed for RoadContainer coordinates.
When working in the IDE, it would be nice to be able to grab a single Spatial in order to move an entire road. But, it's not necessarily a requirement. A creator can always select the nodes they want and then move them. So, creators still have lots of freedom.

Curves:

What was the context for the curves in the discussion?
They sort of popped up without any mention of what specific curves we were talking about.
Were they AI-curves or other yet-to-be-implemented curves?

Pre-Fabs:

Let's assume the Wheel Steal game is the primary context, here.
In the current system, a RoadSegment is comprised of two RoadPoints and a RoadNetwork is made up of a series of these.
Let's say a coder wants to create a series of small road templates (saved scenes), randomly instantiate them, and stitch them together at runtime. At present, this poses a problem.
The developer needs to be able to save RoadPoints into a scene and then, later, assign them to a RoadNetwork as well as stitch other aspects of the scenes together.
A couple of solutions come to mind (this list is not comprehensive): 1 Describe the scenes in code rather than setting them up in the IDE, 2 Make it so that the Road Generator ignores RoadNetworks in child scenes.
In the 2nd scenario, the main scene has a RoadNetwork and it has some RoadPoints as direct children. But, a road template scene is also added as a child and it also has a RoadNetwork. However, the child's RoadNetwork gets ignored and its children become defacto children of the main scene's RoadNetwork. I don't even know if this is possible. I'm just brainstorming. ;-)

On the subject of RoadSegments, RoadPoints, and pre-fabs: It would be nice if we could drop a pre-fab road into a scene and have it magically link up.

What if we didn't have to explicitly assign Prev/Next RoadPoints? There's a fairly straight-forward way to implement this. Define Prev/Next RoadPoints by their order in the SceneTree.

Here is an example with two scenes: "Scene1" and "Scene2".

Scene1:

Root
- RoadNetwork
- RoadPoint1
- RoadPoint2
- RoadPoint3

Based on the node order, we can assume:

RoadPoint1 has no Prev point and a Next point of RoadPoint2
RoadPoint2 has a Prev point of RoadPoint1 and a Next point of RoadPoint3
RoadPoint3 has a Prev point of RoadPoint2 and no Next point

Now, let's create "Scene2" and incorporate Scene1 into it.

Scene2:

Root
- RoadNetwork
- Scene1
- RoadPoint4
- RoadPoint5
- RoadPoint6

The beauty of our newfound way for determining RoadPoint order is that Scene1 doesn't explicitly have to know anything about Scene2.

We can infer that the first 3 RoadPoints are the ones from Scene1 and RoadPoint3 connects to RoadPoint4 and so on... The implication, again, is that RoadPoint (and scene) placement determines the order in which RoadPoints are drawn. The RoadNetwork figures out the sequence when it refreshes.

So, to wrap up this post: The goal is to enable the use of RoadNetworks as child scenes and easily connect them to a parent scene. This approach could facilitate that use case.

Oh, I would add the following recommendation:

Leave RoadNetworks named as they are, at least for the time being, in order to avoid unnecessary confusion.

Other objects have been renamed and, for various reasons, the name change was only partially implemented. Hence, we're dealing with two different names for the same object. It would be nice to avoid that if possible.

RoadIntersections could likely be an extension of RoadNetwork. This makes sense based on the fact that RoadNetworks take care of the drawing of Segments. RoadIntersections could take care of drawing Intersections.

It would be good to dedicate some resources to the development of RoadIntersections at some point.

Perhaps, one final thought. If introducing a "RoadContainer" object, consider using IT as the top-level road object. Thus, the RoadContainer would contain the RoadNetworks and RoadNetworks would contain the RoadPoints.

It follows that the RoadIntersections would probably inherit from, or simply be patterned after RoadNetworks and sit at the same level in the hierarchy.

Thanks for sharing your comments! Responding to a few of the points here ahead of our discussion tomorrow:

What's missing is the ability to connect two streets (RoadNetworks) together.

Actually it happens to be that it does already work to connect to roads together, but it's a bit ambiguous about which one owns that segment. In any event, we essentially need to assert that the endpoints of two different RoadContainers need to exactly line up (so it's either an intersection, or one road continuously turning into another road).

Where should RoadContainers be placed in terms of coordinates? This simply requires an executive decision. First RoadPoint sounds good.

I think starting with the first RoadPoint is a good approach, and then if it gets moved, up to the user if they want to recenter or anything like that.

In the Wheel Steal game, will the roads always remain stationary or will the camera remain stationary at world origin while the roads move?

Assume roads will remain stationary, and the camera is moving.

When working in the IDE, it would be nice to be able to grab a single Spatial in order to move an entire road. But, it's not necessarily a requirement.

Agreed - user can always select multiple points. Users will mostly interact at the level of control points (ie RoadPoints) anyways, since moving entire roads as separate pieces won't really make sense since they might have starting connections which would either need to remain connected, or be disconnected after manual movement.

What was the context for the curves in the discussion?

Sorry I jumped between two thoughts. I'm referring to what I mentioned earlier in the post: "We have another feature intent whereby we create curves that follow along the outside edge of the road, as well as the exact middle belonging to the median line (both would account for lane changes)."

Think: one road will have one continuous curve object that follows the entire outside forward direction. Then someone can use the proedural geometry tools to place railings and lamp points along the entire length of the road. In Wheel Steal that gets tricky since we keep adding new segments (and removing old ones), so it could cause flicker. But, I think enabling an option to generate curves for only single segments at a time as well solves our use case problem there.

Pre-Fabs:...The developer needs to be able to save RoadPoints into a scene and then, later, assign them to a RoadNetwork as well as stitch other aspects of the scenes together.

.. addressing below

On the subject of RoadSegments, RoadPoints, and pre-fabs: It would be nice if we could drop a pre-fab road into a scene and have it magically link up.

Agreed. Essentially, I'm thinking that the ends of "RoadContainers" must always point to other RoadContainers. These ends are defined by unconnected RoadPoints within them, but essentially define the "shape" of the RoadContainer itself, and should work with composed scenes all the same. The more I think of it, the more I feel this is an intuitive and strong structure that fits all our needs.

I'll make a second post that is more addressing the structure I have in mind, will make this clearer.

So, to clarify my idea of the hierarchy with the new structure:

Scene which is a saved prefab RoadContainer

RoadContainerA
- RoadPoint1; with nextpt -> RP2, but no prior point
- RoadPoint2; with priorpt -> RP1, but no next point.
- Custom mesh geometry
- Other stuff.

Let's presume we also have RoadContainerB, with a similar setup

Scene where you want to use the prefab

root
- RoadRoot (or maybe RoadRoute) (not to be confused with the code of what we have now, but more the purpose of what we have today as something which is just the container for all RoadContainers, which themselves each contain RoadPoints
- RoadContainerA -> it's endpoint "RoadPoint2" is treated as the second endpoint index, and is marked as connected to RoadContainerB's first index endpoint
- RoadContainerB -> ditto above, but let's say its second endpoint (which again, is just an unconnected RoadPoint) is connected to an intersection:
- RoadInterSection: End point 1 (out of array size 4, due to 4 RP's nested being connected to parent) has nodepath to RoadContainerB's RP2.
  - RoadPoint1, in point as connected to parent to indicate it's an end piece
  - RoadPoint2, ditto
  - RoadPoint3, ditto
  - RoadPoint4, ditto
  - Static mesh of this intersection

The thing I really like about this structure, is that RoadPoints of intersections and normal roadcontainers are not treated differently, and they're always at the same hierarchy level, vs having RoadPoints sometimes at one level or another. In this scenario, the connected containers do need to "know" about the contained RoadPoints on the edge, but the container/intersection object can essentially manage the arrays for what those are, so it's still a clean interface.

@bdog2112 and I synced yesterday to think through this some more, and we even created a crude mockup in godot with a simple script including export array vars which would imply how the interfaces of the RoadContainer would look like.

We also mentioned trying to avoid the ambiguity of renaming RoadNetwork. It could be that something like RoadRoot (or RoadRoute, or RoadSystem). That's more of a detail in the end. With this approach, RoadContainers create a nice boundary between their own siblings in a higher level scene, and the contents of its own subscene. The interface is an export array of nodepaths to point to other roads/intersections that this road container should connect to, as well as an index variable which indicates which roadpoint within that container should be used to connect to.

With recent merges, I'm going to go ahead and close this task as done, since it is technically a "proposal" and we've started implementation.

For the interested parties, here's some additional diagramming planning I did to help illustrate how RoadPoints of one container will relate to road points in other containers.

TheDuckCow / godot-road-generator

Proposal for Road Containers #122

Scene which is a saved prefab RoadContainer

Scene where you want to use the prefab