I want to make a large "island" with roads on it.
Usually, I would lay out roads with pre-made pieces, path deform them, weld them to pre-made intersections, or sweep new geometry between pre-made intersections and then start bridging land between the gaps to form a terrain.
All that target welding and stuff makes this tedious really fast, though the results are superb.
What I am looking for is an alternative to manually doing this. Some kind of procedurally generated method would be keen and perfecto.
It doesn't even need to produce close-up quality, something passable for a preliminary LOD place holder would be OK.
I do not work with terrains, that is, not in-engine, we work with meshes-only, including for the ground.
What I am looking for is some program or method that would allow me to quickly generate cool looking terrains with a road network already on them. Not overlayed, but part of the "terrain" mesh itself, as to avoid any real overdraw. I would then render it top down and chop it up in a bunch of little pieces and export it to the engine, chopping up an optimized clone with the top down render for LOD (assuming the results would not already be low quality).
I have considered making a terrain mesh -> selecting edges selectively and making shapes from them, basically reversing the process of roads -> land to land -> roads -> delete some land -> start welding land to sidewalks.
That seems as tedious if not moreso than the usual method.
Anyone ever made ground/terrain meshes with roads? Help a bruvva out :x
Replies
I'm looking for a solution/software that generates terrains with the roads already built into them.
But yes, basically, the workflow is exactly as you said it for the roads and their materials.
I guess it is probably better to just do the roads and fill the holes, regardless how long it takes :P
- make terrain -> export to obj (in whatever app you make terrains in)
- make road path in whatever app you choose ( i use blender and its trivial to make it, im sure its an easy thing for any app )
- now take the bottom layer of quads of your road mesh, export those as obj, now import both terrain and bottom road mesh into zbrush and use projection paint tool to make the road fit into the terrain.
- after your done , export the result and throw your road mesh ontop of the terrain that it should now fit into.
I created roads for a bunch of terrain a couple years ago, and did pretty much the manual method. Went pretty fast. Drew a spline on the terrain, lofted it with banking disabled and UVs enabled, adjusted to remove kinks, deleted the terrain faces that would intersect it, attached the road to the terrain mesh, used Bridge to connect the terrain to the road, then UVd the whole terrain including the new bridged faces (but not the road). The winding roads here: http://ericchadwick.com/img/gmts_landscape.html
I understand what you guys are saying about how to actually model the roads and merge them with the terrain, I was just curious as to how does this fit into a pipeline where the layout is entirely dependant on level design and is bound to change quite often. How do you structure the asset authoring pipeline to integrate well with an iterative level design process?
From my experience, iterative design processes tend to lean heavily on the tech/code teams. The ideal result is handing control over to the designers via whatever editor you use, or have made.
It's all well and good to develop an easy to alter system within something like Max/Maya etc, but that still requires an artist to get in there and change things when a designer wants changes made.
The only time a designer should be coming back to an artist with requests is just with wanting new art assets to use, not the actual layout of the levels. This isn't always the case, and I'm sure we've all worked on projects where the art and design have been leashed to one another, but truly iterative processes are all about reducing those bottlenecks, and that usually means a good editor from the coders, artists stock it with "goodies"... and the designers use those to build their worlds.
Heh, yeah I've worked to that model before... and while I still like the theory, it ended horribly for the studio I work for. We'd beautify a supposed finished design, and then changes would still be made. It doesn't help that with small studios the art and design (and code) are often being developed at the same time.
Also it's the job of management to minimize major rework; if they're not on top of their job then things tend to go to shit really quick.
But err.. yeah, we're not allowed to do that any more. Very long story, not for sharing!