Technical solutions for dealing with in-game roads

Coding
1

I’m curious about hearing what you guys think is the best technical solutions for dealing with in-game roads.
Some issues that I want to make easier or get rid of entirely:

a) Artist/level designer having to create road meshes manually
b) Artist/level designer having to create road intersection meshes - and UV’s manually (T, X and Y -crossings)
c) Artist having to create many different road textures for blending

Road making in our current game has been fucking BAD. In a way I’m glad for getting professional insight into this issue - learning not to take things for granted. But it’s also embarassing because I know there are much clever ways to deal with it than we do now.

What we have now:
Many different kind of materials/(textures), Meshes with lots of splits to allow intersections (T, X and Y -crossing), Artists having to spend A LOT of time tweaking UV’s in intersections, Artists having to “hide away” seams with alpha planes.

What I’ve whined about for the coders to implement:
Splatmapping - so we can reduce the idiotic amount of materials used, but also so that we can cut down on the time investment for creating environments.

What I’m still a bit clueless about:
How to best get a nice workflow for the artists (me and this other guy) and our level designer, when it comes to the creation of roads in our environments: and especially how to deal with intersections.

I know what I want but I don’t understand the technical aspects of it fully. In some level editors, you draw a road spline by placing out points. Then the engine automagicly creates an alpha plane shaped like that spline, maps it’s UV’s so that they are straight (tiling either along U or V) and then use either an alpha channel, vertex alpha or splatmapping to blend the road onto the underlying surface.
All of this I can make in Maya. I just create an EP curve, a linear NURBS curve (rectangle), extrude it along the curve, convert to polygons. But here appears the first problem: aligning or “sewing” the road to the underlying environment mesh. This isn’t so problematic on flat surfaces where you can just make a boolean union but say you want to create a road in a mountain range and it becomes a lot harder. After that phase is done, I can unfold the road part along one axis only with my UV Editor, and I end up with a result like this:
http://img228.imageshack.us/img228/6521/splatmaproadtest.jpg

(this is a test scene so don’t bash down on my graphics :wink: Anyway, what you have here is a 2D plane (4 verts) with a layered shader assigned to it. Under the hood of the LS you have a splatmapping network consisting of 4 different materials and a splatmap. The asphalt part is a separate mesh for now, and uses a separate material that does not belong to the splatmapping network.)

And yea I’m still far from happy at this point. Problems as I see it:
-Blending the road with the rest of the world. Sure it can be done with vertex alpha but we wanna avoid that because it’s expensive, and it gives us problems when doing lightmaps. One solution would be to incorporate the asphalt in the splatmap network and just “paint out” the road on the splatmap texture inside photoshop. But then how do you make it so that the road is straight? Multiple UV sets? Ok, but then how do you set it up in Maya so you BOTH get the road straight AND blending with the other materials in the network? Afaik you can only have ONE primary UV-map (that the viewport displays) at a time.
-Blending the road with other roads, creating T, X and Y-crossings. This is something I don’t even know how to fix and make smooth even if everything above was implemented.

Thoughts?

EDIT: Also, I forgot to add this: We are a mobile game developer so our tech isn’t exactly high-end. We make games for tablets and smartphones so any high-end solutions are out of the question unfortunatly :frowning: Splatmapping seems like something we can “afford” though - at least that’s the impression I get…

2

You can have a dedicated UV Set for each texture if you wanted. The viewport might have trouble displaying it, but you can render it.

It depends on how your engine and exporter handle multiple UV Sets.

3

See if you can dig up a copy of the volition talk from GDC… 2010? 2009?.. about the Saints Row 3 editor. Had a lot of good stuff about roads. It’s probably in the GDC vault.

4

[QUOTE=Theodox;19688]See if you can dig up a copy of the volition talk from GDC… 2010? 2009?.. about the Saints Row 3 editor. Had a lot of good stuff about roads. It’s probably in the GDC vault.[/QUOTE]

http://www.gdcvault.com/browse
doesn’t seem like it’s been archived

5

And is it maybe posted here? : http://www.volition-inc.com/publications/

6

It’s not necessarily a technical overview of what they did, but you get to see how they dealt with roads.

http://www.gameinformer.com/b/features/archive/2011/03/25/take-a-video-tour-of-saints-row-39-s-new-city.aspx

7

Yea that looks neat - I could only dream of having a lever editor like that though (we don’t even have a basic level editor, lol).

8

I’ve started dealing with “a)” a bit and I think I’m gonna go with nCloth for making roads shape along a terrain since it seems rather easy.
So for this current experimentation I’ve created a good landscape in Maya (GeoControl2 > save out heightmap > use heightmap with plugin “iDeform” in Maya) and made a piece of road by extruding a NURBS rectangle along a 2D-NURBS curve. I then create some nCloth from the road, and make the terrain into a passive collider and yea, now I’m just toying around with nCloth presets and settings trying to figure out how to get the best results from this.

It still does not solve the thing about intersections though. But now at least it will be easier to do changes if some designer/person in charge starts complaining and want to have a right turn instead of a left turn -_-

9

Oh, that’s pretty nice, we did something similar for a ride, a curve system that builds elements on the fly (depending on what you connect to it).

10

Sounds cool. I doubt there will be much automation in my system though, but still: my suggestions will improve the workflow over here by a ton
I’m planning to have I dunno, maybe a script for extruding the curve and a script for making the nMesh stuff and then a script for creating a splatmap node network so yea… there will still be some manual labor here. These things are in no way advanced but it saves you a lot of time in the long run when all you have to think about is pressing ONE button. ^^

11

Upped a video showing of the tools, programming was done by Jeroen Hoolmans ( http://www.jeroenhoolmans.nl/ ), it is build around a custom curve system, a custom loft/extrude system, a custom geo instancer that works with VRay with an interface that allows you to place different types of assets on certain parts of the curve/rails : http://www.youtube.com/watch?v=_ZMYEJOBsAg.

The curve system was build around OpenNurbs.

Not trying to turn this into some showcase thread, but for those interested, this is a cut down version of the ride, original was 6K-ish at 50fps : http://www.youtube.com/watch?v=Ls5QacuUoQ8

12

If i hear roads i always think of this one http://www.youtube.com/watch?v=jOLhnwllpgs :slight_smile:

13

Getting back to the problem at hand, when you talk splat mapping, are we talking a dataset with transforms for sprite like splat mapping that is applied on the fly, or prior to starting the level?

Also, how accurate is the 3d engine? i have seen games (and in some extend for rendering) placing a layer with clip mapping/transparency maps for edge blending extra detail polygons (roads, foliage, decals) floating on top of the floor poly layer (close enough to give the impression of being part of the original floor geo, but not too close that z fighting occurs.)

14

If the cloth solution doesn’t work out you might try using the tool to edit your heightmap based on the spline (in effect, lowering the terrain around the spline with some soft falloff. The road should still be a separate bit of geo on top of the terrain so you have properly oriented UVs. This is pretty much what, eg. Crytek does.

15

[QUOTE=svenneve;19732]Getting back to the problem at hand, when you talk splat mapping, are we talking a dataset with transforms for sprite like splat mapping that is applied on the fly, or prior to starting the level?

Also, how accurate is the 3d engine? i have seen games (and in some extend for rendering) placing a layer with clip mapping/transparency maps for edge blending extra detail polygons (roads, foliage, decals) floating on top of the floor poly layer (close enough to give the impression of being part of the original floor geo, but not too close that z fighting occurs.)[/QUOTE]

I’m not sure I understand the concepts in your first question but I’m pretty sure the splatting will take place prior to starting up the level: Texture splatting - Wikipedia (ie: it gets combined by the engine, and then you get one draw call per material and zero alpha-sorting issues).
I’ve already created a splatmap node network in Maya and I plan on making it automated (so the user just clicks one button and then only have to worry about picking textures for the file nodes and painting the splat map). This is not needed for the exporter but is just made to visualise the texture splatting for whoever is working on an environment.
Unfortunatly Maya gets really sluggish when you have layered shaders in the viewport displaying multiple materials (all with alpha) - and that in combination with the slugginess of the 3D paint tool makes it unrealistic to paint the splatmap texture map on the fly in Maya (something I wanted at first). Even by switching to a more simple viewport view you have really sluggish 3d painting in Maya :frowning:

Regarding point two I’m pretty confident the engine is accurate enough. We’ve used 2d-planes (road textures with alpha) before to cover up seams in the road and although it does work for us - even with lightmapping in the environment - it’s time consuming. It’s just so… tacky, when we artists have to manually edit UV’s everytime we want a crossing or intersection. Additionally it’s one extra texture map and another draw call. It becomes even more frustrating when some person-in-charge comes along saying that “this and that gotta change”: back to square one doing really boring, time-consuming bullshit. It’s a bad bump in the road in regards to our pipeline! We also have issues with alpha-sorting which is really frustrating.

[QUOTE=Theodox;19736]If the cloth solution doesn’t work out you might try using the tool to edit your heightmap based on the spline (in effect, lowering the terrain around the spline with some soft falloff. The road should still be a separate bit of geo on top of the terrain so you have properly oriented UVs. This is pretty much what, eg. Crytek does.[/QUOTE]
It’s actually working better than expected. Right now I’m stuck on experimenting with the settings of the nCloth. I want it to behave like a cooked spaghetti straw but all I get is everything but that. The mesh inflates on itself, I get clipping and the entire road is floating above the ground. I’m confident this can be fixed though - it’s all in the settings. nCloth is very powerful after all.
And yes the road piece is a separate piece of geometry. But here is what I don’t get:
The layer shader is connected to a material node. Textures are already combed by it. That node is then connected to a material, which is used on a mesh. So the UV’s for the texture splatting mesh will be aligned in one way, and the road will be aligned in a completely different way because it has to tile along either U or V. This explains the problem:
http://img818.imageshack.us/img818/4130/pathingproblem.jpg
(ugly, quickly made picture I know but it shows the problem - the diagonal lines are the “ground” splatmap and the black lines the road)

Sure it can be fixed with multiple UV sets on the code side (material A to C get UV set 1, material D - the asphalt - get UV set 2) - problem is that Maya can’t display this in the viewport: Maya can only display ONE primary UV-set. So that’s a display problem: roads will be aligned with the rest of the textures inside Maya.

So I guess the only alternative is to treat the roads as decals? Make those meshes hover slightly above the ground. That wouldn’t be a problem with an ARGB-material hovering above an RGB-material but as soon as we have multiple alpha materials in layers we get problems. I dunno why exactly, because it shouldn’t be much of a problem: I get the impression that the coders are too damn lazy to fix our alpha-sorting problems, or that it got a lower prio in their minds than it has in mine. But even if we did fix those issues, this is something that our engine is very, very bad at - even considering that we create games for mobile devices. So I guess you can understand how frustrated I feel about all of this. The pipeline is… very flawed… and I feel a desperate urge to fix it. But I got my hands tied behind my back over here and don’t have many options :frowning:

16

Okay here’s an update:
After I discussed this issue with the others at the company, one of our programmers wrote a splatmap shader (CGFX) that blends materials according to vertex color information.
No splatmap texture map is used and each texture for the shader is assigned a vertex color (primary color: RGB) and a UV-set.
Me and our level designer tried it out in Maya and it’s working great. Roads get their separate UV-set (since they tile along U or V only) while the rest of the environment is mapped on the default UV-set.
It’s easy to work with, using Maya’s paint vertex color -tool… and by switching to the default viewport you can see exactly where the vertex colors are.

He haven’t written a direct X shader yet though so this hasn’t been tested in-game: but it’s scheduled for the next test.