Jump to content

  • Log In with Google      Sign In   
  • Create Account

Generating procedural road intersection geometry

  • You cannot reply to this topic
4 replies to this topic

#1 ssb   Members   -  Reputation: 113


Posted 17 August 2014 - 08:06 AM

There's a thread here that poses the exact questions I need help with, but it was ignored at the time. Basically, I am trying to make a system of roads based on splines. These will be generated by the user at runtime, so all of the generation needs to be done dynamically and on the fly. I can create the curve and create an extruded mesh based on that, but I can only get as far as the rectangluar shape. Basically this means plopping vertices at offsets along the curve and triangulating it. This is simple enough, but I have absolutely no idea where to begin thinking about how to create an intersection, specifically in creating the geometry for it. Think SimCity.


For example this video. It uses Houdini to create the mesh beforehand, but what I basically need help with is the most basic theory behind how Houdini does what it does in this particular case.


I apologize for the lack of detail in this question. I am just lost regarding how best to proceed from here. Thank you.


#2 Postie   Members   -  Reputation: 914


Posted 17 August 2014 - 10:08 AM

I haven't done dynamic road generation myself yet (though my current project will eventually need it). I came across this article a while back at noted it down for future reference. See if its helpful to you.

Currently working on an open world survival RPG - For info check out my Development blog: ByteWrangler

#3 ssb   Members   -  Reputation: 113


Posted 18 August 2014 - 06:39 PM

I have seen that article and it was helpful for me in formulating my basic road creation tools, but it doesn't do much for me with regard to creating an actual intersection. Procedural generation is still a bit of a mystery for me, so I'm not sure how to piece together something like an intersection. Even if I can imagine the steps necessary I have no idea how to actually implement them.

#4 ankhd   Members   -  Reputation: 1216


Posted 18 August 2014 - 08:35 PM


It Took a while but I found the link I spotted a couple of days ago, May help here

#5 haegarr   Crossbones+   -  Reputation: 4171


Posted 19 August 2014 - 02:39 AM

(A warning ahead: I'm not familiar with road terminology. I'm using "country road", "freeway", "interstate", "junction", "feeder road", "road surface", "kerbstone" and similar words without being sure whether I'm doing that correctly.)


So the designer places splines by hand. The splines by themselves just define geometry, what is not sufficient by itself. Besides geometry, such a spline need to have meta data associated with it. The geometry and the meta data together is modeled as a piece of your internal representation of the road network.


Each node in the network can be understood as a model for a distinguishable piece of the road network. A node that represents a line of road refers to two other nodes, namely one at the beginning and one at the end of the line. A T junction refers to three other nodes, a crossing to four other nodes. Also a bridge is possible, showing 2 pairs of references but not as a crossing. Lets use the abbreviations I-node, T-node, X-node, and B-node in the following. Notice that in this network, when looking at it as a graph, the edges exist explicitly.


When the designer places a spline, the system tracks the geometry, creates a new I-node in the network and attaches the spline. The tool that the designer has used defines the kind of the road (e.g. country road, interstate, freeway; this belongs to the said meta data) or else the designer declares the kind of road after creating the geometry.


Then the system detects whether the new I-node's spline hits a formerly existing node. If so, and the formerly node is an I-node, and the new line ends at the geometry of the former one, then a new T-node, X-node, or B-node need to be inserted. For now the splines are split, a new "undefined" node is inserted, and all the references are set up. Before the system is able to actually create the road, the designer need to specify what kind of node s/he actually wants there. According to the kinds of participating roads, some possibilities may be excluded. It may further be the case that geometric constraints may exclude possibilities, e.g. the intersection should be in-between 75° and 90° to allow for an X-node. Or there is not enough area left to model the junctions where a country road hits a freeway.


After the above steps are done, an abstract road network exists. The concrete network then requires the generation of concrete geometry for road surface, kerbstone, and perhaps some accessory. Parameters for this (like e.g. road width) are stored in the meta data, initially derived from the kind of road but perhaps overwritten by manual input. T-nodes and X-nodes are defined to have terminals (correct word w.r.t. roads? I don't know) so that the actual connection is part of them (rather than part of the referred I-nodes).


Now the "intelligence" is put into the nodes. If you have an X-node with country roads on all connections, the node is modeling its concrete surface as 2 crossing straight pieces of road, where the transitions are smoothed by inscribing circular arcs. Some node set-ups need prefab support: Bridges, junctions, crossing of interstates, ... show characteristics that need to be a-priorily integrated. E.g. an X-node coming from an intersection of a freeway and a country road is not modeled as a crossing; instead it is modeled so that the country road is bridged over the freeway, and four feeder roads are set into the tangents. Placing accessories like traffic lights, traffic signs, vegetation, ... is also based on the nodes.


Well, the above is a coarse description of a framework. It s hopefully a suitable foundation of how to start.