# Idea for Planet Rendering

This topic is 4968 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm interested in having a planetary terrain, as opposed to the typical flat square heightmap terrain found in most games. So ive been thining about this.... Most sphereical terrain is based on recursivly tesselating an icosahedron. typically you use a modified ROAM approach but ROAM, and recursion, are heavy on the CPU typical square heightmap terrains use clipmaps or geomipmapping since its much more efficient with hardware square heightmaps are also easily stored in a big 2d array as opposed to tesselating geometry... which is a big advantage in iterating for triangle strip renders and collision detection and so fourth So i wonder, how can i have a spherical planet, but also have all the nice benefits typical to square heighfield terrains.... Here is my current thought: a square heightmap can easily turn into a triangular grid heightmap by skewing it along a diagonal a sphere is made by tesselating an icosahedron into many triangles -these triangles all vary slightly in size based on their location on the icosahedron, but if we are standing on this surface, we wont notice the slight error why not take our skew heightmap, and do some simple linear matrix transforms to position it onto the icosahedron triangle the player is currently standing on? *not a spherical coordinate transform, just a straight linear mappping onto one of those many tesselated icosahedron triangles even though our ground ends up being flat, at that scale on the planet, you wont notice the lack of curvature as the player travels across the surface, we can use our clipmapping scheme to scroll new data into our skew heighmap, and gradually adjust the transform to match the new location on the icosahedron what you think? is this do-able?

##### Share on other sites
I spent some time thinking about a similar system a while ago, and came to the following conclusion: there is NO WAY entire planets can be done on home computers at the moment. Even for a relatively small "planet" like the moon, the storage space needed for a heightmap of its entire surface with a 1 metre resolution is about 40 terabytes (for 1 byte per height field). Realistically at the moment you could get about 4GB on a DVD, giving you a planetary radius of 18.5km (0.0015 Earths). This would mean the horizon was ~200 metres away which I'm pretty sure would produce noticable curvature. So in answer to your question, I think we're gonna have to hold out for better hardware and LOTS more storage.

##### Share on other sites
Quote:
 Original post by ZQJI spent some time thinking about a similar system a while ago, and came to the following conclusion: there is NO WAY entire planets can be done on home computers at the moment. Even for a relatively small "planet" like the moon, the storage space needed for a heightmap of its entire surface with a 1 metre resolution is about 40 terabytes (for 1 byte per height field). Realistically at the moment you could get about 4GB on a DVD, giving you a planetary radius of 18.5km (0.0015 Earths). This would mean the horizon was ~200 metres away which I'm pretty sure would produce noticable curvature. So in answer to your question, I think we're gonna have to hold out for better hardware and LOTS more storage.

But you don't have to store a heightmap at 1 metre resolution for an entire planet. You store a heightmap at much lower resolution (a few kilometres maybe) for most of the planet, and you store high resolution height maps for any particular areas of the planet that are of interest (eg, if you're making a space game where you can land on planets, you'd store a high res heightmap for the area of the landing port). The rest of the detail can be filled in procedurally (fractals, perlin noise, or whatever)

Edit: Of course, you're right if you're talking about rendering data from real planets, where you would presumably want the entire thing to be detailed. Even there, 1m resolution isn't needed though - you can get away with less. And I would assume that some quite heavy compression can be done on the data (partly through storing lower resolution height data for areas that lack high frequency detail, partly through standard image compression techniques)

As for the original post and topic - it sounds feasible. If you only ever need to render from the planet's surface though, then you don't need your planet to be truely spherical anyway, since the curvature is too small to notice.

John B

##### Share on other sites
Quote:
 Original post by haphazardlynamedand do some simple linear matrix transforms to position it onto the icosahedron

This will not be enough since it would not be sufficient to just have one coordinate system with the origin for instance at the center of the planet. You will have no precision left when flying too far from the planet. You will need some kind of dynamic coordinate system that recenters itself around the player every so often, and transforms every object according to the realignment (no matter how far away that object is). As speeds get slower and slower approaching the planet surface, you will probably require even more precision, to the centimeter or smaller! In this case you will not have the precision you need unless the origin is placed near the surface of the planet, and is realigned as you fly along the surface.

Others have done it though, so there is no question about whether it can be done. If you have thought your idea through then you can make it happen with enough work.

##### Share on other sites
Quote:
 Original post by JohnBSmallBut you don't have to store a heightmap at 1 metre resolution for an entire planet. You store a heightmap at much lower resolution (a few kilometres maybe) for most of the planet, and you store high resolution height maps for any particular areas of the planet that are of interest (eg, if you're making a space game where you can land on planets, you'd store a high res heightmap for the area of the landing port). The rest of the detail can be filled in procedurally (fractals, perlin noise, or whatever)

That's true, but looking at orders of magnitude, you've got a factor of 10000 or so to make up in compression and procedural generation (again if we're looking at the moon). On the whole I'd say an 8 bit heightmap won't give a decent resolution which is going to increase the required space, so that's a pretty big difference to make up by compression and procedural generation, which I would've thought would take out most of the chance you've got for design. The moon has a surface area of 37 million square kilometers where most engines go for the order of hundreds. Plus of course I'm ignoring putting things like buildings, trees and other objects in (although I'm sure they could be automatically generated on-the-fly as well).

One thought I have just had though - instead of an icosphere it might be easier to use a UVsphere while varying the resolution of the heightmaps depending where you are on the planet. That would mean that most of the planet (except for the bits near the poles) was based on rectangular sections instead of triangles.

##### Share on other sites
Quote:
 Original post by ZQJThat's true, but looking at orders of magnitude, you've got a factor of 10000 or so to make up in compression and procedural generation (again if we're looking at the moon). On the whole I'd say an 8 bit heightmap won't give a decent resolution which is going to increase the required space, so that's a pretty big difference to make up by compression and procedural generation, which I would've thought would take out most of the chance you've got for design. The moon has a surface area of 37 million square kilometers where most engines go for the order of hundreds. Plus of course I'm ignoring putting things like buildings, trees and other objects in (although I'm sure they could be automatically generated on-the-fly as well).

Well, I'd certainly agree that with current hardware, you couldn't display an entire planet with any real detail except in a few places where you absolutely need it, but even so, you can get the major large-scale features in. Take a look at planet engine if you haven't seen it already (although you probably have, since you've obviously thought about this). Certainly it doesn't give you realism, but the major features are there.

John B

##### Share on other sites
As JohnBSmall said, it is certainly possible to render potentially gigabyte-sized datasets on relatively high-spec computers assuming that you have a sufficiently large dataset (for example Blue Marble from NASA). You can make up for the lack of surface detail by introducing procedural noise.

The best engines I've seen that accomodate existing datasets with procedural noise are Lutz Justen and Ysaneya.

Lutz uses a subdivided cube (rather than an icosahedron) for simplicity of regular grids, combined with Hoppe's Geometry Clipmaps to generate procedural data on the fly to increase surface detail.

I'm not entirely sure about Ysaneya's engine (Flavien himself can provide a better description), but from his videos I *think* he generates chunks/patches on the fly in a seperate thread as opposed to primitive-level caching of individual vertices as in a clipmap.

Both authors are extremely helpeful members of this community, and can provide a far better description than I can.

If you want to render extremely large datasets without the addition of procedural noise, then you may want to consider P-BDAM however thats probably over the top and involves a huge amount of pre-processing.

Final word about using an icosahedron as a basis for subdivision. Advantage is that the 20 triangular faces are more uniform in size and will show less distortion than say a cube. You could possibly represent the entire planet using 10 rectangular heightmaps by grouping triangular faces into pairs (i.e. sort of parallelograms). Apologies if this is what you already intended.

Problems that I encountered using an icosahedron - accessing/manipulating vertices in a triangle is less trivial than a regular grid (i.e. a cube), and you may have texture addressing problems near the edges of chunks. Fingers_ managed to overcome these problems with awesome results using an icosahedron, so perhaps its best to talk to him.

Here is one final link about how you can represent a planet using an icosahedron.

I've got a ton more links if you want them, just shout. Hope that helps.

*EDIT*
Sod it, here's a bunch of random links that may help (in no particular order).

Planet Rendering: Part 1 - The Basics
Planet Rendering: Part 2 - Generating The Data
A Real-Time Procedural Universe, Part Three: Matters of Scale
Planet Engine
A Real-Time Procedural Universe, Part Two: Rendering Planetary Bodies

##### Share on other sites
Thanks, but "awesome" is definitely a relative term here :)

My planet engine didn't do anything near Earth size terrain so I didn't have to tackle some of the headier issues like floating point accuracy and streaming a large dataset. The planet was all in RAM, at 100-200 megs as I recall. Other planets, moons and the sun visible in the sky would use a downsampled version of their texture mapped to a simple sphere model.

It was/is intended for a non-realistic game involving ground, air and space travel that cannot take so long that the player will get bored... An orbit takes about a minute, driving across a continent maybe 15 minutes, that sort of thing. You could compare it to the size of the world map in Morrowind.

Now, back to the actual thread :)

When texturing the icosahedral faces with one texture each, I simply placed one corner of the triangle at the middle of the top edge of the texture and the other two in the bottom corners. The parts of the texture that aren't in this triangle are filled by repeating the colors at the (diagonal) edges of the triangle. The sectors of the planet are matched so that the flat edge of the texture always meets another flat edge. Because the pixels at the edge of neighboring textures are based on the same datapoints (terrain vertices) they'll be the same color and the textures will look continuous.

It worked, but wasted 50% of the texture space. One experiment I just never found time to do was pairing two neighboring sectors in the same texture diagonally. The most obvious way is pairing each "pole triangle" (five at each pole) with its neighboring "equatorial triangle". This would cause a bit more distortion in the texture (the dividing edge has 40% higher texel density) but all the seams between textures should be really easy to correct and this would save a bunch of VRAM so it'd be worth doing anyway.

Like Cheese said, this approach naturally leads to making those two triangles into one (skewed) square heightmap as well. At the very least it should make it easier to adapt existing square heightmap rendering techniques into your planet renderer.

Now that I'm thinking about this, it might be even better to start with a dodecahedron (12-sided solid with pentagonal faces) with a vertex inserted in the center of each face. The resulting 60 triangles are combined to 30 quadrangles across the edge of the original faces. The "sharp" angle of these quads would be wider than the 60 degrees you get with an icosahedron so it should look more natural.

It would be difficult to display the resulting heightmaps in a vanilla (non-spherical) terrain renderer because of what happens where the heightmaps meet. Even though a single sector could be used like any other heightmap, its corners may touch two or four neighbors instead of three so you'll need to do some kind of a distortion effect that varies based on where you are.

##### Share on other sites
Thank you all for your replies

I dont think anyone totally understood my idea though, thats my fault really
Wait a while, I will make some diagrams.... this could take up to a few days

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 10
• 11
• 13
• 9
• 11
• ### Forum Statistics

• Total Topics
634092
• Total Posts
3015447
×