I was thinking … how hard would it be to modify jmonkey’s terrain mesh so that it wraps itself into a sphere? You know … like creating a planet?
Might be a stupid idea but I can imagine an algorythm that reduces and increases the polly count as you move away or closer to the planet through an averaging algorithm and if you are close enough you effectively just get the flat mesh since at ground level a planet looks flat(ish).
Am I nuts??
Yes and no. It wont work for small planets. Where you can see the arc of the planet clearly. For example, on a small moon. I have toyed with planet generation. Take a look at aaron perkins space project. I think its called jmeplanet.
Probably as hard as it would be to write from scratch.
a) you will find that the flat-earth assumption is pretty strong… like, what do you do at the poles?
b) it’s functional but it’s not great… especially for a planet’s needs. I could go deeper into the choices I’d have made differently but regardless, quad-tree style LOD you’d need for atmosphere-to-planet travel just isn’t possible with that system. It’s LOD is based on “this tile is far away from where I’m standing so draw it lower detail”.
When doing the terrain for a round planet you have several early and critical decisions to make, the most important one is what coordinate mapping to use. Do you go with a geodetic style lat/lon where nothing is ever square and you have triangles at the poles? Or do you go with a spherized cube model where nothing is square but everything maps to a square and you never have triangles… but you do have six points shared by only three “squares” instead of four.
Having done whole-earth style visualizations before with actual earth data, I’m not really sure which one I’d use. Earth coordinate projection is super ugly but well understood. Lots of maps to use for testing, etc… however, it’s a model based on “most people don’t live near the poles” convenience. Most of the time, you end up reprojecting the square maps anyway.
Starting from purely “out of thin air” data, it’s very tempting to use the projected cube approach. You can represent your height map data as six quad trees (or fixed grid pyramid or whatever). Finding tiles, choosing LODS, etc. is just a math problem.
It’s probably the approach I’d use… and I have thought about this.
Unanswered questions my response above might generate:
If those were relatively obvious then I didn’t want to go into a deeper explanation… but I can. 
We assume you wish to fly into each world as a normal ship would. You could skip the entry and exit phases a bit like starbound, of course. Place your ship at the edge of the atmosphere and “warp” down.
Oh it was well understood but I do have a question … if I go with a sphere projected cube or tetrahedron then won’t I be actually stretching the height map? … maybe visually that does not matter.
I originally was going to just use the jmeplanet code as a launching pad but unfortunately it uses a custom jbullet collision mesh and porting it over to native bullet is beyond my native bullet skill set. So alass unless someone ports jmeplanet to 3.1 I will be starting from scratch.
Maybe I will get smoother results with a spherized octohedron? … I need to think about this a bit.
Atmosphere is not a problem. it’s the planet mesh and the dynamic hight mapped collision shape for native bullet that is the problem.
Yes, but see if you can come up with a sphere mapping that doesn’t. (hint: it’s not possible)
Think about the geodetic mapping… things get totally warped at the poles.
An octahedron is not what I’m talking about.
A cube is basically a six sided sphere. If you subdivide each face into quads and project the new points out to the sphere along their radial lines, you end up with a 24 sided figure where most of the shapes are “squarish”. Do it again you get 98 sides and so on.
The nice thing is that each of those six sides is still ‘quadish’ in shape so the math is really easy. Given some position on the globe, it’s a few dot products to find out which tile you are in.
Your data will have to be generated with this warping in mind but you solve 100 other problems that other mappings would create… and the nice thing is that the quads are, relatively speaking, equal area as compared to geodetic mapping.
Edit: here is a good illustration of the difference between geodetic and a spherized cube (called a ‘quad sphere’ apparently):
https://imgur.com/wZGNwY0.png
Edit 2: and with more subdivisions:
https://imgur.com/Opx5CJo.png
Edit 3: actually that one is a poor illustration because they seem to have normalized the quads somewhere… a real version will be a little more distorted throughout and a little less distorted at the corners.
Edit 4: I should close google images now before it’s too late!!!
https://imgur.com/7sTtMSH.png
agreed … now if I can just figure out how to create a dynamic native bullet collision shape for it I would be golden. cube is much easier math than an octohedron. The mesh seems very doable but the native bullet collision shape generator I have no clue about.
Why do you need a collision shape for an entire planet? The reason I ask is that bullet is not optimized to handle the size difference between a planet and something human/vehicle sized. Do you really need physics rigidbody calculations on that level? I think a better approach would be to create a physics space based on the things around the spaceship/player when it matters, like close to the surface when landing.
So add a quad to the local ship’s physics space when it gets real close to the planet? Interesting. How about vehicles roaming around on the planet surface?
Same thing.
Don’t collide against a whole planet when 1/100000th of a planet will do.