# Procedural Planets, Heightmaps and Textures

I am currently working on an OpenGL procedural planet generator. I hope to use it for a space RPG, that will not allow players to go down to the surface of a planet so I have ignored anything ROAM related. At the moment I am drawing a cube with VBOs and mapping onto a sphere.

I am familiar with most fractal heightmap generating techniques and have already implemented my own version of midpoint displacement (not that useful in this case I know).

My question is, what is the best way to procedurally generate the heightmap. I have looked at libnoise which allows me to make tilable heightmaps/textures, but as far as I can see I would need to generate a net like this.

Leaving the tiling obvious.

Could anyone advise me on the best route to take?

Any input would be much appreciated.

-

First of all, I'm not sure why you want to implement a height map (i.e. geometry displacement) if people won't be able to land, it just seems more efficient to normal map it or something.

With that said, what you want is to convert from an arbitrary `(x, y, z)` to a `(u, v)` coordinate, which is trivial. No cubemap needed.

1. Every `(u, v)` texel has a height (heightmap `RGB = height`) and a position `(x, y, z) = pos`.
2. Find and normalize the position, `NORMAL(x, y, z) = N`.
3. New vertex = `pos+N*height`.

This will work better with a higher tessellation. Also use the proper `libnoise` spherical mapping for your heightmap, which will look something like this (but black and white):

-

I have never tried this myself, but it looks like a very interesting way to generate spherical landscapes. http://freespace.virgin.net/hugo.elias/models/m_landsp.htm

-
I found this approach very pleasing for github.com/williame/GlestNG – Will Jan 11 '11 at 6:24

Midpoint displacement height mapping is a good place to start. OP, why do you think it isn't?

OP is good to model the planet surface as a cubemap, because any flat map (e.g. mercator projection) is going to have distortions that are ugly and complicated, mathwise.

If I were OP, I would forget the large scale planet geometry at first. I would make a cubemap where each face is 2**N+1 pixels (2,3,5,9,17,33...) and each texel encodes a height [0..N) where 0 is the altitude of the expected lowest trench and N is the altitude of the expected highest mountain on the planet.

I would then calculate random heights for the eight vertices of the cube, and propagate them into the six squares of the cube map, so that each vertex shows up three times.

As I recursively generate fractal heights for the midpoints of the edges, I would make sure to propagate face edge vertices to the other face that shares them.

Once I'm done, I have a cube map where all the edge texels are doubled and all the corner texels are tripled. No need to convert it to a normal map - I'd use the algorithm in Morten Mikkelsen's paper to render normals directly from the heightmap at runtime.

At runtime I would probably render a quad that covers the projection of the planet to the screen, and do a single ray-sphere intersection test in the pixel shader to find whether I hit the planet and where. Sure beats rasterizing a highly-tessellated sphere model, and gets a nice smooth edge too.

-

Midpoint displacement noise, with the maximum displacement scaled by the absolute longitude of the pixel can produce a spherical noise map quickly. Color tables taking altitude, slope, and sunlight or longitude as paramaters can be used to shade the planet automatically.

-