existing sphere subdivision (LOD) solution?

I'm working with a group of middle school students to make a spaceflight simulator. Think KSP, but set in our actual solar system.

It's just been decided that the mission for this semester is to fly from the ISS to the Moon, land, take off, and fly back to the ISS.

Most of that is fairly straightforward... but landing on the Moon is proving thorny, because of the extreme scales involved. The Moon has a radius of about 1700 km. We can't represent it as a single object that's going to have decent resolution when you're landing on it.

I think I know what needs to be done, in theory: we start with a quad sphere, and then subdivide the quadrants as we get closer. Each subdivided mesh can then be morphed a bit according to a terrain map and/or noise function, so no matter how close you get, there's more detail to see. And as we get further away, we do the reverse: swap out four neighboring meshes at a time and replace them with one larger mesh (until we reach the limit of the original six quadrants of the sphere).

But... there's no way my middle-schoolers are going to be able to code that. I could do it, given the time, but even then I start to sweat a little when I think about ensuring that the seams always match up where a higher-resolution mesh borders a lower-resolution one.

Does anybody know of an off-the-shelf solution for this? Something that lets you provide a function for the terrain height at any point, and it takes care of the subdivision (and re-combining) for you?

Thanks,
- Joe

 

Not exactly what you're looking for but I wonder if this would be helpful at all - http://www.binpress.com/tutorial/creating-an-octahedron-sphere/162

 

Thanks, that's a fun article. It does raise the point that rather than subdividing a quad sphere, I could instead subdivide triangles starting with an octahedron.

I'm not sure whether that's actually any easier, though... the nice thing about the quad sphere is, each face is basically a square (and when you subdivide it, you just get more squares). This makes the coordinates slightly easier to think about. I don't know whether it actually makes any difference to the complexity of the code, though.