Author Hello devs. Apologies in advance if this is not the correct forum for this. I've recently been spending a lot of my free time working on an old project of mine. It originated in 2013, and after several years-long hiatuses and complete rewrites, it's now in a state that I think is worth sharing.The goal is to simulate spheroids with real-time, procedurally generated terrain on a planetary scale and beyond. My inspiration for this project are old voxel games like Comanche. I wanted to do something like that, but instead of the finite play area being enforced through artificial boundaries, have it be a natural consequence of the world's geometry.Here's a short demo I recorded: https://www.youtube.com/watch?v=8S3MPTzymX8The planet in this demo has a radius of 2^23 meters which makes it about 2.28x the size of Earth by volume. The surface can be traversed freely without loading areas as it's all sampled in real time. Admittedly, the detail in this video is not that great. I've only recently begun working on the terrain sampler, so this is in a very early stage of development.To speak briefly on the geometry; the world is an icosahedron formed by 20 recursively subdivided tetrahedra. The tetrahedra subdivide into an oct-tet truss: a lattice of octahedra and tetrahedra. This structure is also called a spaceframe, and it's the cause for the shape of the terrain.If this sort of thing intrigues you, please let me know. I have been working on generating realistic planet-scale terrain for the last 2.5 years. You can read about it on my blog (start at the bottom).I decided against the icosahedron subdivision for my planet engine because it makes lots of things more difficult. I use the cube-sphere subdivision instead, because it leads to a quadtree subdivision of each cube face. This makes it much easier to do things like determine what terrain tiles are near to a given location, or to implement erosion. Everything exists on a rectilinear grid, which makes hydraulic erosion much easier.It seems like you should increase the distance at which you subdivide the terrain, to reduce the LOD popping. As it is, terrain features materialize to near to the camera. You ideally should implement a system so that the terrain is subdivided until a certain screen-space resolution is achieved (e.g. size of a triangle in pixels). Advertisement Author Your project looks very nice, but we have chosen very different paths in our implementations of planetary terrain. There is no grid or mesh spaceframe. The surface map is a direct result of sampling. The space is recursively sampled with a binary function and vertices are emitted based on the boundary resolved between filled and empty space. The detail popping is a consequence of the size difference between shapes in finer and coarser LODs. In theory this could be mitigated with higher LODs, but that is not a practical option given how CPU intensive real time, full planet binary space partitioning and boundary resolution is. Maybe one day I'll write a GPU implementation, though. What I'm saying is that your approach, while interesting, cannot use various optimizations which can be applied to rectilinear coordinates, which may explain why it is slow and can't increase the detail as much. My approach, running entirely on a 12-year old 4-core CPU can in real time generate triangles down to 5mm resolution at an angular LOD of 4 pixels per triangle, covering an earth-sized planet (and much bigger is not a problem), using around 4GB RAM. Furthermore, I'm not just generating terrain by fractal noise, I'm also applying various erosion processes which use the majority of the compute. This is only possible by a careful choice of spatial representation of the terrain, asynchronous multithreaded generation, and by highly optimized code (nearly all uses SIMD). Since the terrain is on a 2D rectangular grid, all operations aside from final mesh generation are essentially image processing, and make good use of CPU SIMD capabilities, which provides up to 8x speedup with AVX. Unless your data is laid out in a similar compact way you will have a hard time making it fast on modern CPUs. I don't think the “space frame” is a good fit for modern CPU architectures.