I’m a CS student and for a school assignment we are trying to make a simple city builder interface in 3D (no game logic at all, only placing buildings/roads).
Naturally we’ve been looking into the terrain SDK that simplifies a lot of the work, but we keep bumping into the problem of creating roads.
The goal is to allow the user to freely design his road system with multiple kinds of intersections (only straight roads and right angles are out of question), and then have cars moving on them (very basic AI, no traffic handling).
Main problem: How to visually create the roads?
We thought of two approches:
Either apply a texture to the terrain, but how can you edit a texture in real time? We could not figure how to retrieve and edit the alpha map once in the game, nor did we find how to apply decals.
Or create a flat mesh that folds itself to adopt the terrain shape. We do not have a clue on how to do this.
Second problem: How could the car AI work?
We have looked into the MotionPath class, but that would mean storing the road network as a graph. This is not looking like an easy thing to do, since it would mean we have to link newly created roads to old ones if their extremities are close enough, and have a smart node placement to avoid cars clipping/floating.
It is also a problem for intersections, roads with several lanes, etc.
Are we approaching the problem from the wrong perspective? Does anyone have any idea on how to solve these in a simple or hard way?
The goal of our assignment is not necessarily to code a working game, but to at least try, and if we fail, explain why, so any piece of information is valuable!
I have plenty of ideas how to start and try to implement something like this.
Basic idea would include roads cut into pieces by terrain edges and vertices as new inner points.
You always know where “up” is facing and the UV layout of the road is under your control.
You can get the geometry of the terrain as edges and vertices somehow.
Advanced ideas would flatten the terrain or use a CSG library to “cut into the ground”.
Because the problem will later be: a road may go up hill and down hill forward, but not sideways…
The problem is: This whole thing can become complex very fast - it’s at the heart of city building and traffic simulation games. You will need some deep thoughts and a lot of 3D math and 2D math to solve this.
See this as an opportunity - prepare for long nights with pizza and coffee and start now! :chimpanzee_wink:
He uses “highways” - roads like bridges which you can often see in the US or sometimes in Europe (near bridges). A clever idea that circumvents the need for smarter solutions by using something simple. Good example of nice working low tech solution!
Second, how good are you with maths? The more complex forms you want to create “on fly”, the more complex required maths will become.
And I’ll add third problem - “how to save what user created and load it in future?”
If you want to use decals or texture painting, then you have to modify your map geometry - no one likes roads angled or even curved to side so you have to flatten it. Good if you have high resolution for terrain-map or terrain based on custom mesh and very ugly looking otherwise.
if you want to use dynamically created model as road and can’t modify terrain then you are limited to highway-style roads and roads on artificial foundation.
If it would me, I’d use fast and cheap solution:
limited set of supported intersection types, probably modelled in 3d-editing software but not necessarily so
roads from intersection to intersection generated on fly and controlled by some simple interpolation
“nodes” points used to control form and placement of roads, every intersection have a node on every side where road will be as well as dead-end roads will have such a node at the end
roads could be started only from “nodes” on intersections and try to snap to nearby nodes on intersections in placement mode
intersections could be placed anywhere on already existing road, adding some “nodes” to it and effectively splitting it
to have not only straight roads again “nodes” are used, user place and drag nodes and road is interpolated from node to node, taking all nodes between two intersections
for better display there should be some terrain modification, it may be not very aggressive compared to decals variant
for gameplay reasons it may be wise to make already built roads not editable while planning new roads should support free editing for placed but yet not constructed roads
with roads already fully described by nodes it will be easy to build any graph you want to make AI
with limited set of supported intersection types it’s easy to design them well to have no visual glitches
And yes, it’s that hard to do it right so this way could be really considered fast and cheap.
For mesh “on fly” construction - try to look at Mesh class and it’s subtypes like Sphere or Box to get basics of how things work internally. For terrain editing there should be good enough example if I remember correct. For interpolation try to look at com.jme3.math.Spline class and CatmullRom interpolation as it’s easiest one. You’ll have to make Mesh subtype and use Spline for calculations. To move car along the road use not cinematic but hand-written controller and manually update car position every frame (Splines are your friends here as they’ll help you calculate everything as long as road is built using them).
The deadline is early January, that leaves us with roughly one and a half month of work, and we have other things to do as well, namely buildings, that sound much easier to implement so we are focusing on that for the moment, but also other unrelated lessons.
We should be good enough in maths for 3D programming, but a solution that extensively uses them does not really sound easy and fast enough for what we want in our assignment.
The highway solution in Tankwart’s post looks like an easier way to do it but still seems to pose a lot of problems in terms or intersections, editor behaviour and car AI, or maybe we just lack experience.
The node system prog mentionned also sounds like a nice idea.
We cannot have a deeper look into them at the moment but we will keep them in mind. Thanks!
We are still open for more ideas.