Not sure if there’s a better place for this. Mainly a computer science question, but scripting seems the best place for it.
Anyway, so yeah, why splat and grey scale height maps?
I’ve been spending some of my thinking time on terrains and I keep coming back to why the maps are square and why do they use image files. It seems like using a globe with vector details would be better so that the terrain can be curved, abundent, and as detailed as needed without wasting memory.
Because it’s easy to use and efficient. 99% of the time you aren’t doing globes, just a relatively small section of terrain.
–Eric
I’m wondering how you would even implement vector detailing. It seems like you would need an awful lot of vectors for a terrain.
It’s obvious why globes aren’t used as often. Calculating with a globe as a base is more complicated than just handling a basic plane. And the vast majority of simulations are based on human perception, as opposed to physical reality. We can’t see the curvature of the earth from our standard human perspective, so there is less value in attempting to simulate that curvature in-game.
Yes, you absolutely can. Especially on mountains.
No, in most cases from most perspectives that are commonly used, the curvature is not particularly evident. Certainly not to the extent that it’s worth the extra complexity. If you want to go ultra-realistic and model everything 100% physically accurately, you’re welcome to do that, but keep in mind most games/simulations are about approximating stuff so it runs fast.
–Eric
I’ve always been interested in making entire worlds, round that the players can explore, perhaps with flying animals/devices or gateways. The flat maps and current way of making them don’t lend well to this at all.
They lend perfectly well to them as long as you aren’t ever going to view your world from a great distance
Height maps and splat maps were built a long time before anyone even considered the idea of making a game that simulated an entire planet. So being square and two dimensional was not a limitation when they were first introduced. The technique of storing data in images is common in computers. Check out normal maps for example. The data has little to do with a traditional image.
Images are basically a 2D array of floats (3D if you use channels on a colour image). One of the advantages of using an image format is you can then take advantage of all of the processing, compression, and optimisation techniques developed for working with real images. Images also have the advantage that they kind of look like the data they are meant to represent. Its relatively easy for a non programmer to look at a height map and figure out what is happening. You can also edit images in standard tools like paint or photoshop.
I think that I may have not represented what I was trying to suggest very well.
Let me try again:
I’m thinking that you start with a hypothetical polyhydron (most likely an icosahedron).
The vectors and the polyhydron does more detail with LOD.
So contenents are visible from a high altitude, and mountains can be seen from a distance, without bogging down the system.
If there is no game content on the distant mountains, then there are no detailed vectors loaded.
But I digress.
The thing I don’t understand is why images. I guess I can see it as something that is simple to edit and share and understand, but I’m wondering if there were any technical reasons.
I know that the image files used use the power of two rule for packing data, and I was wondering if what I’m talking about would have an effect on it.
I guess I don’t understand how game engines juggle data like that and how streaming would be effected. That’s why I’m doing this “thought experiment” to begin with, to better understand what’s going on under the hood.
What advantages would there be to using a custom format to store essentially the same data as a normal image?
Aside from doing global maps for curved horizons and doing large worlds, vectors could allow for infinite detail while using potentially less data. On top of that, you could easily do maps with regard to more than just height for 90 degree cliffs, caves, and overhangs.
You could, say, have a line that blends a cliff face into the map and use a cheap line for it.
Or you could do another line that goes into the ground to make a cave system.
Or, maybe a line that creates an entire mountain and tweak a few parts to determin its incline, height, even erosion.
Hell, you could make entire continents with a few lines and seed procedurally generate details with some tweaking.
Oh, and while we’re at it, throw in weather patterns and seasonal changes.
And it could cost WAY less in storage with just as much performance.
For something like that, octrees/marching cubes would be more efficient and flexible. Its not that images are the only modern way to do terrain, they’re just the most efficient and simple. Most people don’t “need” the advanced methods, but they exist, and are the foundation of most of the voxel based terrain engines.
Infinite detail has to come from somewhere. Is it worth giving up processing power to save a bit on the storage aspect of things? It might be if your game is trying to fit into platforms with tight storage limits but I can’t help but feel like those platforms will be equally tight on processing power too.
There will be exceptions of course but I can’t help but feel those exceptions are so few it won’t matter if the tools are mainly designed around heightmaps.
What you could do for a globe is cover the globe in small overlapping squares. (Think of sticking post-it notes on a globe). And where the squares overlap you take the average of the height for the pixel of each square.
I’m not sure that’s possible to do in Unity’s terrain system though… It would involve recalculating terrain heights on the fly.
How about using an icosphere divided up into sections?
Yeah. If you divide a bitmap on it’s diagonal it means a single bitmap would be able to store terrain data for two of the triangles in one of the icospheres. That would work I guess.
But you’d need your own terrain implementation which can do terrain in a triangular region instead of a square region. Something for Unity 6 maybe. Like this guy suggested.
Exactly!
On, on a side note, if you were to take the earth and cover it in 1 meter x 1 meter x 1 meter triangles like that it would be about 6.5 billion triangles.
That’s when I thought “why not vectors?”
Well, this sort of thing is already solved; typically you use a cubesphere so you don’t need to deal with triangles (and you could continue to use heightmaps…BoredMormon already clearly explained “why heightmaps”, so if you missed that post, read it). Again, though, most usage of terrains doesn’t involve entire planets.
–Eric
Sorry, I don’t mean to pester.
What am I missing here? All you’re essentially doing is manipulating quads (well triangles to the engine) by using a vector (surface elevation) reference map. So this “idea” on vectors is pretty much what it does anyway…
The actual terrain no matter what you do will have to be some form of mesh, the world doesn’t necessarily have to be flat. You could segment (tile) the mesh and wrap it spherically if the connection (border edges) between the tiles glue correctly and with a heightmap you could do this all procedurally.
In fact you probably will do this procedurally and store as a reference location to be loaded from disk, the format file will be algorithmically compressed and computationally generated at a border distance (dropped out of memory past another border zone). You’d segment specific squares for “viewing” at boundary locations, which is also a vector reference from point of zero.
The main impact performance wise is heightmap resolution, which employs more vector height data manipulation per grid space.
Although generally with decent streaming, it’s not the terrain that’s the issue. It’s all the crap you put on top of it…!
