I’ve been working on a realtime procedural planet generator that’s part of a larger project which I’ll hopefully be revealing soon. The planet is generated by 3D cell and perlin noise algorithms on the GPU to generate object-space normal maps and colors while also displacing vertices on the CPU (for mesh colliders). The planet uses a quadtree LOD system for seamless transitioning from space to surface. As far as performance goes, the view shown in the screenshot above was rendered at ~80 fps and there is still plenty of optimization to be done. Currently planetary rings (check the screenshot above - I know the shadows aren’t right yet but they still look cool imho), an ocean renderer (check the most recent quick update), procedural textures, flora, asteroids, and rocks are other major features in the works and hopefully I’ll be able to show more of that stuff off soon. The screenshots above are relatively new and depict a Gaian world with rings, an ocean, and much more surface detail than in the [old] screenshots below.
Ahh yes. I was just making sure you didn’t use a polar sphere as it’s bad for UV texturing (pinching at the poles). I actually have code to generate and subdivide Icospheres but it was something I wrote for XNA which is why I was asking. I can certainly see how subdivided cube would be better for quad tree partitioning. Out of curiosity, why a QuadTree since it’s really designed more for 2D data storage? I would have that that Octree would be a better choice, although higher memory requirements and some wasted storage space (partitioning for the inside of your sphere).
Well since I’m only using 2D heightmaps to generate the terrain so quadtrees are sufficient and there would be no benefit to using octree especially because, as you said, more unecessary memory usage. If (and once) I have subsurface spaces and caves working then octrees would be worth using.
Within the past week or so I’ve optimized the code and added a crater noise module, then decided to increase the vertex density of the patches which set performance back again (but it still runs better than before). Currently I get 60-65 fps on a three year old iMac when just flying around the planet at virtually any altitude. To optimize the code I multithreaded the mesh deformation and edge stitching functions then rewrote a bit of the heightmap generation code to create a high-res texture for normal mapping and coloration and a lower-res texture for mesh deformation. Having a separate heightmap for the vertices also allowed for 32 bit precision (encoding a float into an 8 bit per channel texture) that way the camera can get closer to the ground before things get wacky.
I also began working on atmosphere scattering and ran a test with Sean O’Neil’s method which didn’t turn out as well as I hoped. It looks decent from the surface but a seamless transition from ground to space isn’t possible as separate shaders are required. I’m already in the process in implementing Eric Bruneton’s precomputed atmospheric scattering which looks far more advanced and realistic. Here are some screenshots for now though:
I’m not exactly sure what/where the “quick profiler” is but there are 100,000+ vertices and 200,000+ triangles onscreen viewing from ~2 meters off the ground, once I add horizon culling that will be reduced by a lot as many unnecessary patches of terrain are rendered which aren’t culled by frustum culling. To answer your second question, I am still deciding whether or not I’ll release it on the Asset Store.
Check the original post for images. The new atmospheric scattering is not done yet, needs some optimization, and still has bugs but so far it looks considerably better than the first atmosphere test. It’s rendered as a single post processing effect and currently runs at ~20 fps on my 5 year old hardware (256 MB Video), I need to test it on a more recent computer but I’m speculating that the framerate will be much higher on a computer with at least 1 GB of VRAM.
EDIT: I got the framerate back up to 60 fps by, paradoxically, increasing the quality settings and disabling vsync.
Yes, but if I release an Asset Store version it won’t be for a little while longer since I’m working on procedural flora, ocean rendering, and other aspects of my game at the moment in addition to handling precision issues so that a game that uses the procedural planet system will run smoothly.
I would also be interested in this potentially if it went on the store. I don’t need flora for my current project. There are several dead procedural planets plugins floating around, it would be nice to have a working one.
Really have to hand it to you: some of those planet renders and horizon renders are fantastic. I sent you a private message about that. Looking forward to hearing from you!
I actually have code to generate and subdivide Icospheres but it was something I wrote for XNA which is why I was asking. 
I can certainly see how subdivided cube would be better for quad tree partitioning. Out of curiosity, why a QuadTree since it’s really designed more for 2D data storage? I would have that that Octree would be a better choice, although higher memory requirements and some wasted storage space (partitioning for the inside of your sphere).
