Road addnodes too sparse or to dense flips the road upside down

[gianlucafabris]

Creating Road with addnodes and a set of nodes too sparse or to dense flips the road upside down.
This issue affects all the road or part of it, this can't be fixed with flip_direction=True.

[gianlucafabris]

all the road, if all the nodes are added at once
partial (only the segment to spese or to dense), if the nodes are added one at a time

[dstark481]

Hello Gianluca,

I don't see the road being flipped upside down in your example, but there are glitches (folding and maybe material mapping problems). You can inspect the road a bit better if you go into the World Editor (press F11) then at the top, select the Decal Road Editor.

Your points are not monotonous in the X dimension (the first 5 go left, and the rest go right) - this describes a very sharp turn, since the Y value does change, but this may explain the 'folding' appearance. The road tool is not perfect, and this pushes it quite stiff. Also - it is probably better to create the mesh before laying the decal road on top of it (although I am not sure this matters from BeamNGPy tbh).

The internal tool which creates the roads has some known issues which we are working on (it is very old), so for now it would be best to keep points from being too close together, and to avoid very sharp turns. You shouldn't need to put points that close together anyway - internally, a spline will be fitted to them, so any detail at that resolution would likely be lost in this process.

Dave

[gianlucafabris]

thanks for the reply
the example was made by hand, here is the corrected version (monotonic)

    road.add_nodes((-307.5, 20, 0, 30)) #dense
    road.add_nodes((-307.4, 20, 0, 30))
    road.add_nodes((-307.3, 20, 0, 30))
    road.add_nodes((-307.2, 20, 0, 30))
    road.add_nodes((-307.1, 20, 0, 30))
    road.add_nodes((-307, 20, 0, 30))
    road.add_nodes((-257, 15, 1))
    road.add_nodes((-207, 25, 2, 15)) # the 4th is width of the node
    road.add_nodes((-157, 20, 1))
    road.add_nodes((-107, 20, 0)) #sparse
    road.add_nodes((97, 20, 0))

In my project i'm using a tool to generate the nodes, and some times the nodes are to dense or to sparse, here is an example with two roads monotonic both x and y

    road1.add_nodes((220.38, 0.0, 0.0),)
    road1.add_nodes((228.222, 10.388, 0.0),)
    road1.add_nodes((257.577, 58.126, 0.0),)
    road1.add_nodes((268.611, 77.357, 3.0),)
    road1.add_nodes((304.989, 137.108, 3.0),)
    road1.add_nodes((308.183, 142.592, 3.0),) #dense
    road1.add_nodes((309.842, 145.428, 3.0),)

    road2.add_nodes((-28.224, 170.02, 3.0),)
    road2.add_nodes((47.185, 119.69, 1.0),)
    road2.add_nodes((82.989, 94.664, 1.0),)
    road2.add_nodes((123.993, 65.734, 0.0),)
    road2.add_nodes((133.075, 59.684, 0.0),) #sparse
    road2.add_nodes((220.38, 0.0, 0.0),)

the lighter areas are how the road is supposed to look like, the darker areas are where it is to dense or to sparse

btw, with nodes properly spaced works fine even with non monotonic x and y, example (circle like)

    road.add_nodes((-20, 0, 0.0),)
    road.add_nodes((0, 20, 0.0),)
    road.add_nodes((20, 0, 0.0),)
    road.add_nodes((0, -20, 0.0),)
    road.add_nodes((-40, 0, 0.0),)

[dstark481]

You could try running a pass over the points, whereby if two consecutive points are too close (eg < some epsilon) then remove the 2nd, etc. To increase density, you could start adding midpoints. We do this kind of thing sometimes.

Dave

[gianlucafabris]

ok thanks, hoping for a correction of the bug in future versions

[gianlucafabris]

some updates: I've done some test to better understand the cause of the problem, here are the test and analysis github.com/gianlucafabris/BeamNGpy - Road test, hoping this might help you

[AbdelrahmanElsaidElsawy]

Hello @gianlucafabris,
did you try the road_definition example?

[gianlucafabris]

yes, those roads do not have the artefact
I'm creating a tool to import osm roads and i've noticed the there are some artefacts
example

    road1.add_nodes((220.38, 0.0, 0.0),)
    road1.add_nodes((228.222, 10.388, 0.0),)
    road1.add_nodes((257.577, 58.126, 0.0),)
    road1.add_nodes((268.611, 77.357, 3.0),)
    road1.add_nodes((304.989, 137.108, 3.0),)
    road1.add_nodes((308.183, 142.592, 3.0),) #dense
    road1.add_nodes((309.842, 145.428, 3.0),)

    road2.add_nodes((-28.224, 170.02, 3.0),)
    road2.add_nodes((47.185, 119.69, 1.0),)
    road2.add_nodes((82.989, 94.664, 1.0),)
    road2.add_nodes((123.993, 65.734, 0.0),)
    road2.add_nodes((133.075, 59.684, 0.0),) #sparse
    road2.add_nodes((220.38, 0.0, 0.0),)

then i've done some test to better understand the cause of the problem, here are the test and analysis github.com/gianlucafabris/BeamNGpy - Road test

from this analysis seams that there is no correlation with artefact and sparse/dense and also radius of curvature, although visually seams due to a tight radius of curvature (inner spline intersects itself - meaning that the curvature radius is too tight)

(now it doesn't display the texture, on previous tests this road had the artefact)

I hope I was clear enough

[dstark481]

Hello Gianluca,

Folding issues frequently occur when using 'decal roads', which can lead to UV-mapping errors during rendering. Unfortunately, these limitations are inherent to the current implementation, and we do not have a workaround available at this time.

The core of the issue lies in the way decal roads are defined: they are essentially polylines with width values assigned to each node. While this is a straightforward approach, it oversimplifies the complex structure of a road. A more sophisticated method might involve independently managing the left and right edges of the road or re-triangulating the geometry to prevent overlapping and folding.

Best,
David

[dstark481]

Btw - you might also notice some strange tangent problems in the road - especially at the start and end. This is a known bug. I don't see it in your image, though. For decal roads, we fit standard Catmull-Rom splines through the given nodes, but these splines are not the most stable. We will get to fixing it at some point, but not likely to be in the immediate future.

[dstark481]

Regarding the broader challenge of importing OpenStreetMap data:

I've experimented with this in the past but encountered inconsistent results. OSM roads are represented in a graph-based format, where all roads converge at a single point at junctions. However, real-world junctions are more complex, with lanes merging into each other rather than meeting at a single point. To address this, you'll need to implement post-processing to adjust the widths or reconfigure the roads to better reflect real-world conditions.

This is where I paused my efforts, as I found it difficult to achieve convincing results across various scenarios.

Good luck. Let us know how you get on with it.

[gianlucafabris]

thanks
this issue occurs also un road mesh and if a car runs over the artefact the physics break (pops the tyres or completely stops the car)
for an other issue, i've seen that the road architect is really well done (maybe could be possible to implement an importer also for osm with LUA api)

keep improving and keep up the good work👍

[gianlucafabris]

Regarding the broader challenge of importing OpenStreetMap data:

I've experimented with this in the past but encountered inconsistent results. OSM roads are represented in a graph-based format, where all roads converge at a single point at junctions. However, real-world junctions are more complex, with lanes merging into each other rather than meeting at a single point. To address this, you'll need to implement post-processing to adjust the widths or reconfigure the roads to better reflect real-world conditions.

This is where I paused my efforts, as I found it difficult to achieve convincing results across various scenarios.

Good luck. Let us know how you get on with it.

yeap, also noted this
for now my tool import the road with elevation so that is drivable(ish)

[dstark481]

The mesh roads work similarly (same splines etc). There is a further problem when laying decal roads on top of them (ie materials).
The tyre popping sounds like your mesh isn't deep enough. Try to ensure it is at least 0.4m deep (i am not sure what the exact limit it is - if it works, you can play about with it). If the meshes are shallow, the tyres are registering the bottom surface of the mesh and it gets confused. I have seen the tyres pop before because of this, or the car cannot be driven like it is stuck.

We generally do not use mesh roads (procedurally-generated meshes) - they are quite primitive and very costly with respect to the number of triangles, nor do they use optimisations like level-of-detail (LOD) or occlusion (the other 'static' meshes and decal roads that you see on the maps do this). For this reason, it isn't completely supported internally as a way for creating driveable roads, so problems with them are more than likely.

Regarding OSM: I was able to import the roads and project them, despite them being strange at junctions. I also imported real-world terrains from OpenDEM (https://www.opendem.info/opendemsearcher.html) and combined them with the OSM roads. This worked pretty well, although it took a bit of work to get the projections correct, and there was some <3m error there when lining up the roads and the DEM.
From there, we started to develop terraforming methods to alter the heightmap, to better fit the roads to the terrain.
Other than roads, we also imported a lot of the other data: sand, forests, trees, grass, etc, and managed to get something that way too. For us, the water bodies and rivers were more difficult.

[gianlucafabris]

great
i was using the default values for road width and depth, the tyre pops because the artefact flips the road and as you said "the tyres are registering the bottom surface of the mesh and it gets confused. I have seen the tyres pop before because of this, or the car cannot be driven like it is stuck".
i was using tarrain with lower elevation precision and road with more elevation precision
i confirm that by removing the roadmesh the road is drivable without tyres poping or getting stuck (it is just a visual artefact)
by removing the roadmesh also kinda solved the other issue
thanks

[dstark481]

It is not so much that the road is flipped - the code which handles the tyre grip just detects the bottom surface as well as the top surface and it gets conflicted (probably this gives opposing force vectors or something like this - not sure exactly).

The road meshes can technically be used, eg as in the road architect tool (very soon to be updated) or the track builder tool (which both use procedural meshes). With the road architect tool, it is unfortunately very easy to run into issues when trying to lay decals on top of meshes, although it is possible if enough care is taken. As long as the meshes are about 0.4m deep, they should be drivable, and its possible to put camber and incline into the roads.

There is no python end for this though, and it is unlikely there will be since it is a very visual tool. However, what is often a better solution is to generate or import a terrain, then lay roads onto it, which will 'terraform' or sculpt the terrain. Tools to do this kind of thing will be released shortly.

Best,
David