Roads that turn at only 90 degrees seem unnatural, but rendering 45 degree turns is turning into a major headache, because it means that roads cut diagonally across tiles and leave pieces of themselves in neighboring tiles. In addition to having textures to render all the various turns an intersections, we also need every combination of nearby roads sticking out in the corners of the tile. In total that seems to be 4096 road tiles just to cover all the possibilities, even when we restrict roads to only going tile-center to tile-center.

We can save memory by doing some flips and rotations in UV coordinates, but I estimate we'd still need dozens of tiles. We can also save some effort by making the tiles transparent beyond the edges of the road, and then layer together multiple tiles when appropriate, either in pre-processing or in the shader. Whatever we do, it is becoming a major headache for something which seems to be so simple in concept. Am I somehow approaching this problem from the wrong direction?

I'm misunderstanding you somewhere - you are talking about "tiles" but also mentioning tiles crossing over other tiles. Are your tiles always in a uniform, non-overlapping, axis-aligned grid, or do you depart from that?

What I mean is, if you have a diagonal road like this:

I would count that as four tiles - is that how your game works?

I'm also not understanding where you are getting the number 4096 from. Recently when I was thinking about the same concept (with grid-aligned tile-based games), I calculated it as a max of 256 for automapping tiles, and for roads specifically, it was less - and if using rotations and horizontal/vertical mirroring, less still.

46 minutes ago, Servant of the Lord said:

You are talking about "tiles" but also mentioning tiles crossing over other tiles.

Actually I meant that roads cross over neighboring tiles. The tiles are a perfectly regular, axis aligned grid as one would expect. Here's an illustration of the kind of thing I was thinking about:

Notice how when the road goes from the center tile to the bottom-left tile, it doesn't just affect those two tiles but also adds a bit of road to the center-left tile and the center-bottom tile. That's how I got to 4096, because every combination of curves and intersections has to also include every possible combination of bits of road in the corners. For example, the center tile and the center-right tile are almost identical except for a bit of road in the bottom-right corner of the center tile.

Now I see that using smaller tiles could potentially solve the problem. By chopping the road into smaller pieces, there are more ways to assemble roads from fewer pieces. The downside of this is more tiles will mean more triangles on the screen, less variety in the shape of roads, and it also turns road rendering into a jigsaw puzzle where we have to figure out how to assemble the pieces to get the road we want. One tricky point will be ensuring that diagonal roads are the same width as axis-aligned roads.

Ouch, that does complicate matters.

Can you just cheat? Draw your roads as you normally do:

And then come back and layer the corners on top of existing tiles in a second pass:

Then, while you still have a buttload of tiles, you at least simplify it somewhat by not having to worry about the tiny corners.

e.g:

8 minutes ago, Outliner said:

Now I see that using smaller tiles could potentially solve the problem. By chopping the road into smaller pieces, there are more ways to assemble roads from fewer pieces. The downside of this is more tiles will mean more triangles on the screen, less variety in the shape of roads, and it also turns road rendering into a jigsaw puzzle where we have to figure out how to assemble the pieces to get the road we want. One tricky point will be ensuring that diagonal roads are the same width as axis-aligned roads.

As far as the "more triangles on the screen", you could make the road pieces in smaller tiles, but then use a tool to programmatically assemble the different variations (including rotations and flippings) into the large/regular tiles.

Even poor videocards can output bajillions of triangles, though, so I wouldn't worry about having to draw a bunch of small triangles unless it actually proves to be a bottleneck. I don't know how many will be onscreen in your game, though.

A third option would be to split the tiles into 2x2 instead of 3x3:

Why cant you just splat the roads?

4 hours ago, h8CplusplusGuru said:

Why cant you just splat the roads?

As far as I know, splat just means having multiple textures on a mesh so we can have one texture in some places and other textures in other places by using a splat map to to define where each texture is visible. That has several issues. For one, the splat map is a raster, so it tends to pixelate unless it has hugely high resolution. For another, roads often have a direction to their texture, like the lines of a highway, or the grooves of a dirt road. I'm not aware of any way to achieve that effect with splatting.

Every combination of road directions and wat-not, that would be a lot of tiles. However, maybe it is not necessary to pre-gen them and instead generate them on the fly as a road placement is determined. Like, is your game really going to be using all those tiles such that it's necessary to worry about having so many? I said splatting: my idea is, because the actual amount of roads are probably not that high, you can have a series of tiles that contain a road, say 3x3, and then you have a splat map and it splats the road right onto that area. The splat map can be generated on the fly depending on the shape of the road, and its resolution can be high as well because you aren't stretching it across your entire terrain. As far as directions of the road go, you can use a detail map or decals or something like that to add features that give the road a particular direction. (or just bake the data into the road splat ).