Edited by Sonarpulse, 26 June 2012 - 09:30 PM.
Vector field terrain
Posted 26 June 2012 - 09:29 PM
Posted 26 June 2012 - 11:59 PM
Posted 27 June 2012 - 12:11 AM
Edited by zoot, 27 June 2012 - 01:41 AM.
Posted 27 June 2012 - 01:43 AM
@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.
Posted 27 June 2012 - 01:57 AM
Edited by zoot, 27 June 2012 - 02:02 AM.
Posted 27 June 2012 - 02:39 AM
- Fake it method 1: You can chop things and pretend either the overhang or the area below it doesn't exist for game-play.
- Fake it method 2: With any surface "topological equivalent" (you know the whole donught = mug thing), you can fake it be distorting your coordinates (that's what I meant when i was joking about non-Euclidean.) However then either your pathfinder act dummer, or you need to teach it about stretching which will slow things down.
- When you can't fake it: things like bridges act are like portals in Portal if you try to stay 2D. Clearly path-finding would really need to be changed to get that to work automatically. (might be neat for pyrogenisis though beyond 0ad seeing the use of teleporters in other RTSs.)
Posted 27 June 2012 - 03:07 AM
Posted 27 June 2012 - 03:56 AM
Here's how terrain works currently, with 2D height map:
The brown rectangles are structures, though you can substitute other game concepts. The way obstructions (and thus pathfinding) work, the difference in height between the two buildings is ignored since it's a 2D obstruction map. Most of the time this works well, the only time it doesn't is when you have a building extending off a steep hill, it might block buildings underneath. But we don't allow buildings to be built on a steep hill so it doesn't cause much issue in practice.
Here's what you're proposing:
As you can see there are two buildings whose foundations only differ in height. If we still have a 2D obstruction map, then it's impossible to build both of these buildings because the one foundation's 2D obstruction would block the other And obstructions are just one example, as I said, all(?) other game logic is 2D including territories, pathfinding, vision/LOS, and range queries, so it's obvious to me anyway that we would need to extend them all to be 3D or pseudo-3D with special cases for this vector field terrain.
How else might it cause a problem? Well imagine the brown rectangles are units. One is a healer and one is a wounded soldier. Let's say the cliff is some ridiculous exaggerated height, maybe 200 game units. Well because the range manager is using 2D data structures, the healer and wounded soldier are almost on top of each other, therefor the one is in close range of the other (2D). Obviously the healer shouldn't heal the wounded soldier because it's out of 3D range, but it doesn't know that
Territories are another example, say your territory extends under the cliff to where the lower brown rectangle is. I come along and want to build on top of the cliff directly above, but I can't because territory manager uses a 2D data structure and ignores the cliff's height
Posted 27 June 2012 - 04:23 AM
Likely you have a much better understanding of the code than I do. All I'm saying is: I don't see it. I'll leave you to decide if that's just because I'm an ignorant f*ck
Edited by zoot, 27 June 2012 - 12:04 PM.
Posted 27 June 2012 - 06:29 AM
Imagine that you are replacing the terrain's heightmap with a "normalmap", where the vertical Y component of the normals is equivalent to the heightmap's height values. The simulation generally doesn't need to know about the additional XZ components, as this stretching happens during rendering. Taking historic_bruno's two pics as an example, the simulation can just see the top pic, and the bottom pic is only generated by displacing terrain vertices/model positions by the XZ amount of the normalmap when rendering. The model positions do not actually overlap in the simulation.
The stretching can cause some problems, though. It may affect unit speed, with units passing over stretched terrain going faster (we'd need to reduce that based on the magnitude of the XZ displacement vector). More importantly, it would affect mouse input, as we'd need to also displace the bounding boxes used for that. You would also find that rendered unit LOS stretches with the terrain, unit AI can see further when the terrain is stretched, projectiles are thrown farther where terrain is stretched...
Most of those are not unsolvable problems, and would be possible to fix by changing distance queries to take the stretching into account. Calculating the LOS for rendering would be a huge pain...
tl;dr What zoot is describing is probably possible, but would need a lot of intricate changes and a ton of testing.
Edited by myconid, 27 June 2012 - 06:31 AM.
Posted 27 June 2012 - 06:36 AM
Posted 28 June 2012 - 01:04 AM
And I'll stand by that statement until someone cares to demonstrate that it's as simple as zoot says (not the rendering alone but the integration with gameplay)
Though I should also mention that I'm not passionate about cliffs at all, we come close enough with the current simple height map for my liking. The texturing is ugly but myconid has shown that can be improved -- with no effects on gameplay at all, which makes me happy
Posted 28 June 2012 - 01:29 AM
Posted 28 June 2012 - 05:21 AM
Posted 28 June 2012 - 05:47 AM
Posted 28 June 2012 - 06:53 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users