My road system is coming along nicely but I need some guidance. Currently, the user clicks on the terrain to add control nodes. If the road type is looped, 4 nodes will create a loop and any further nodes will add road sections to that loop between the 1st control node and the previously placed one. For non-looped roads, the road forms after 4 control nodes between node 2 and 3 and then any successive clicks adds between 3-4, 4-5, etc. as you can guess, I'm using a spline curve. It all works very nicely, the road mesh is created to nicely cover the terrain (a few points above it), and once you've laid down your nodes, you can move them around and stetch and bend the road as you'd expect from a simple spline curve.

The 2 problems I've got come when the road gets bigger. Firstly, the road is one big mesh and I'm wondering whether it would be more prudent to split this up into chunks. If the road has fairly high section content, i.e. there are more sections between control nodes, the mesh starts getting very big the longer the road gets. I'm using 32 bit indices so there's no problem there but I'm using some fairly keen terrain LODding so I'm not sure whether all that effort would be wasted for roads you're not going to see - I'm likely to chop the road up into manageable sections - is this usually how it's done?

Secondly, and the most important, when you're editing a simple 4 point road that covers a small section of the terrain (say 32x32 terrain tiles), it's very smooth and fast. When you extend the road out towards 256x256 and beyond upto 8192, it gets impossibly slow to edit.

I feel like I've streamlined my code a fair amount but some of the roads I'm envisaging for my game will be relatively long. Here's the breakdown of what I do each frame:

When the user adds a node and the current number for the current road is 4 or more, or the user moves one of the control points around after laying down the points:

Recompute the entire spline curve

For each control point section (the road between two control points), compute the length using a rudimentary 4 lerp points (keeps it quick). This allows me to keep the road sections (the numerous points along the arc) nicely spaced (user configurable).

Create a basic mesh of the road sections (this is for a visual guide only and doesn't include any geometry from the terrain but serves as the "cookie cutter" for the terrain/road geometry). This is done using cross products for each point along the curve. Whilst doing this, I also store the points of this mesh in an array for quicker reference later (for cookie cutting the terrain tiles).

Using each road section, I compute which terrain tiles (triangles) lie under it and add them to a "splittable" vector. I then take this splittable vector and pass it to a method which splits them against the 4 planes of the road section. These triangles are added to the final triangles vector. I then repeat this step for each road section in the entire road curve. Once I have this final list, I run through it getting the exact terrain height and UV coordinates and add it to the final mesh.

It's quite a complex and lengthy procedure that I feel like I've trimmed down quite a bit but it's still too slow. Am I generally on the right track with my steps? (No pun intended).. I'm wondering if I've missed something really obvious. After profiling, a sizeable portion of the time is spent cutting up the triangles against the road section planes and obviously if there are a lot of them to cut, it just makes it even slower.

I can post snippets of code if easier...

Any thoughts?

I think I might cut the road up into separate meshes. If I create a road mesh per control point span and only dynamically rebuild the meshes affected by the control point I'm moving, it should be much faster

That would be the usual strategy.L. Spiro

Thanks L. Spiro. This is running much more smoothly now, but I think it's mostly down to using fixed arrays rather than vectors for the triangles. I had no idea vectors were so inappropriate for code that needs to be quick. I mean I knew they'd be slightly slower but using arrays gave me at least at 400% speed up. Must be the allocations when pushing

You can always call reserve() on the vector to presize it, so that push_back() does not trigger allocations (and the subsequent copy of all elements, and deallocation of the previous allocation!)

Its typically the copy from the previous buffer into the new buffer that causes the slow down. Even the built in memory allocator isn't /that/ slow :)