Vector field terrain

[zoot]

One thing in 0 A.D. that, in my opinion, doesn't really do the rest of the modelling justice, and makes the game feel somewhat like a dying remnant from the 90's, is the terrain. If you've noticed, the terrain is always smoothened and curved in a simple, almost pastoral way:

Does this scream war and terror to you? Probably not. What you'd want is more like this:

The main problem is that the engine uses simple height maps for terrain which do not allow horizontal displacement of the terrain mesh. So while the vertical placement of the terrain vertices may vary greatly from map to map, their horizontal placement is essentially identical. This gives every map a sort of "I've seen this movie before" kind of feel, in my experience.

This all made me wonder if we could use vector fields for terrain instead of height maps/fields. Basically, this would attach a 3-dimensional displacement vector to each terrain vertex or tile, so instead of being limited to this:

... you would be able to do something like this:

I assume this displacement could be done with simple operations in a vertex shader, so the performance impact is limited. Clearly, a 3-dimensional vector requires 3 times as much memory as an 1-dimensional one, but we could probably compress it so only vertices that actually has been displaced relative to the height map will be stored 3-dimensionally.

It also has implications for the pathfinder, but not all that much, as you'd just need to extend the definition of what is passable terrain.

What could be a problem, though, is how to manipulate the vertices accurately enough in Atlas. I don't have a solution for this, but maybe someone else could come up with something.

Thoughts?

Edited June 22, 2012 by zoot

[Gen.Kenobi]

Well... I support this. 3D Terrain is really hard to do. We were talking about creating some 3d Mountains, but I'm not sure how would they blend well in the terrain.

Maybe this approach could work.

[feneur]

For part one I really don't think this is worth even thinking about. It has so many implications for other things as you say, and I'm sure a lot of them will have to be reworked significantly. It's definitely something to think of for part 2 though, but even then I wouldn't get my hopes up too high. After all, pathfinding is a big pain as it is, making the terrain much more complex is probably not going to help it.

Is there and games out there that has true 3D terrain btw? Would be interesting to see how it can work in reality.

[zoot]

Supposedly, Ensemble Studios used vector fields in Halo Wars as a direct consequence of hating the height map based system they used in AoE3.

[zoot]

Would you be able to model something like this with Atlas' height maps? Not a chance.

[howlingflute]

I think this is pretty cool but as has already been said better to save for part II. The path finder at the moment is essentially 2d so this would basically require a total re-write of the pathfinder again. (So I don't think it is worth it for part 1). Anyways at the moment you can still get some pretty steep terrain with the current system.

[zoot]

The path finder at the moment is essentially 2d so this would basically require a total re-write of the pathfinder again.

Can you give an example of a pathfinding scenario with this system that would require a complete rewrite of the pathfinder?

[Sonarpulse]

I think the issue is that with heightmaps, the horizontal and lateral coordinates of each point are fixed, so it's easier to figure out where people can go. However, as long as terrain is not deformable, you can probably bake one of your vector fields to a heightmap for pathfinding purposes pretty easily.

More importantly though, anything without overhangs can be done with heightmaps, so that big cliff for example is totally fair play. It's just requires more work making the heightmap.

[zoot]

Well, that's the thing - that big cliff does have overhangs. Even if we pretend that it just goes vertically down, we still can't do it in the current implementation, because there will always be a smoothening between the 'high' tile and the 'low' tile, which leads to the formation of a slope.

[zoot]

pathfinding how you doing with that? im very worried about that, the pathfinding controls how the game runs without some lag (optimization)

and the problem with the gates.

I think the key to successful open source development is to stop worrying and love the bomb present solutions instead. There is nothing in this suggestion, nor in the deliberations about gates, that will prevent the pathfinder from being optimized.

[Sonarpulse]

Well, that's the thing - that big cliff does have overhangs.

I guess it does a bit, but their not too important to the effect. For me, while cliffs are important, what is even more important to recognize, is that erosion shapes values into kind of tree-fractaly things,

Even if we pretend that it just goes vertically down, we still can't do it in the current implementation, because there will always be a smoothening between the 'high' tile and the 'low' tile, which leads to the formation of a slope.

Simply changing the resolution of the height map solves that.

Anyways, my general point is vector fields look nice, but let's push their present setup to it's artistic limit first. This program http://en.wikipedia.org/wiki/Terragen , is pretty well known, and checkout all the things done with it and height maps: http://www.google.com/search?tbm=isch&q=terragen .

[zoot]

Simply changing the resolution of the height map solves that.

That doesn't resolve the smoothening, it just reduces it. At lower gradients, it will still be impossible to make a truly steep surface.

Anyways, my general point is vector fields look nice, but let's push their present setup to it's artistic limit first. This program http://en.wikipedia.org/wiki/Terragen , is pretty well known, and checkout all the things done with it and height maps: http://www.google.co...isch&q=terragen .

Those kind of sceneries are great for flight simulators and that sort of thing, but they possess no "drama", as far as I'm concerned. They also seem impossible to navigate for land units and would require excessive amounts of memory to load. I also suspect they looked a lot crappier before non-real-time rendering.

[Sonarpulse]

OK, I actually look a look at atlas, I believe with the current resolution, both heightmaps and vector fields will inherently look about as unrealistic as height maps do now. You may fine some things better with vector fields, but unless you seriously "steal" vertices from flat areas, you just need more data for realistic terrain.

On a related note, I think it would be really could get an erosion in atlas (and for random map generators). http://ranmantaru.co...ghtmap-terrain/ seems to have a pretty good idea, and it includes the full source code. (though personally I think the result would be better if a few constants were tweaked).

Edited June 24, 2012 by Sonarpulse

[FeXoR]

OK, I actually look a look at atlas, I believe with the current resolution, both heightmaps and vector fields will inherently look about as unrealistic as height maps do now. You may fine some things better with vector fields, but unless you seriously "steal" vertices from flat areas, you just need more data for realistic terrain.

On a related note, I think it would be really could get an erosion in atlas (and for random map generators). http://ranmantaru.co...ghtmap-terrain/ seems to have a pretty good idea, and it includes the full source code. (though personally I think the result would be better if a few constants were tweaked).

Isn't that for erosion over time? So you could add a painter for that to Atlas and a function that can be used for random maps (though only the result counts here, not the process over time). If triggers are in terrain could really use erosion at game time ^^.

[Sonarpulse]

Game time affects would be cool too. The implementation I linked works by analyzing the path of water droplets, so as opposed to simulating a bunch at once and then deforming the terrain, one simulate a few and repeat, deforming the terrain in tandem. On the other hand erosion like this an extremely slow process, so I'm not sure how much sense it would make.

The primary goal in my mind was to allow maps to (optionally of course) mold really geometric terrain to focus on sheer gameplay (or what ever else), and then let the erosion tool make everything look natural.

[zoot]

myconid suggested something similar here:

In the long-term, there are a number of things I will/might try (sort of a wish list, in no particular order):

• ...
  
• Terrain erosion for map generation. Simulate the effects of water and/or wind erosion to create more realistic terrains and specialised terrain textures in Atlas.
  

Edited June 24, 2012 by zoot

[Gen.Kenobi]

I really support this. Maybe even, if you guys could, add some dynamic terrain deformation.

[theShadow]

you could just add a fractal brush to atlas, to allow you to deform terrain into more of a rough, natural shape.

[historic_bruno]

It also has implications for the pathfinder, but not all that much, as you'd just need to extend the definition of what is passable terrain.

I'm not sure about that, obstructions are all treated as 2D currently, but big overhanging cliffs mean you have different levels of obstruction varying by height (it's 3D). As an example, consider a cliff with a building on top right on the edge, a unit should (intuitively) still be able to walk, build, etc. directly under the cliff, but if we only have a 2D obstruction map, then the building's obstruction would block them. The converse is true as well, I have this big nice cliff to build on, why am I blocked by a house hundreds of meters below? It would affect not only obstructions but territories, vision, and range queries are probably all simplified as 2D data structures currently. I think it gets ugly in a hurry if we want full 3D terrain. IMO this raises more problems than benefits.

[zoot]

Really? I imagined the pathfinder could just operate on the vector field as if it was 2D. So if a tile has been 'stretched' over a ledge, it will visually look like an overhang, but to the pathfinder it would still 'look' like it did before the tile was stretched.

[Sonarpulse]

Well, if you have stretched tiles such as you say, then you can do 2D non-euclidean pathfinding, but I think we should keep relativity out of RTSs

Edited June 26, 2012 by Sonarpulse

[zoot]

How about 2D euclidean pathfinding?

[historic_bruno]

Really? I imagined the pathfinder could just operate on the vector field as if it was 2D. So if a tile has been 'stretched' over a ledge, it will visually look like an overhang, but to the pathfinder it would still 'look' like it did before the tile was stretched.

Well if it's just one tile stretched instead of several, I guess that would work, it would mean separate logic for handling position under the hood compared to what's visible in world. I was thinking you might have several tiles overlapping instead of stretched. We could also make cliffs a purely visual effect and not allow pathfinding, territories, or building on the stretched part -- less than ideal.

[zoot]

Well if it's just one tile stretched instead of several, I guess that would work, it would mean separate logic for handling position under the hood compared to what's visible in world.

It already is seperate, as far as I can tell. The pathfinder works on a 2D logic, the renderer works on a 3D one.

I was thinking you might have several tiles overlapping instead of stretched.

Can you give an example of a case where that might a problem? One case I can think of is if you had a ravine type of thing and then stretched ledges on either side towards each other so they would form a 'bridge'. But the map designer would almost have to be on a special mission to break the pathfinder to do something like that in the first place

Edited June 27, 2012 by zoot

[Sonarpulse]

Well for part two it would be fun to have full 3D gameplay. Even if some things (bridges, walking on walls, sapping/tunneling, etc.) can be faked without it, 3D gameplay will lead to a much more robust solution.

@zoot even the slightest overhang technically causes those problems. In minor instances, the over extended cliff or covered area below can be ignored like historic_bruno said though.

Another solution for increased detail maybe is to sorta mip-map a heightmap based on the slope of a lower resolution. So for example with really flat surfaces the game sample like 4 points for every 4 tiles (making 1 terrain tile for every 4 game types), and on cliffs it samples 9 points for every 1 tile (making 4 terrain tiles for every 1 game tile). Hopefully that makes some sense.