I am working on a personal project to create a game, in which you can fly in space to various planets and land on said planets. I was originally using a script to create an IcoSphere which I stored using recursive chunks which worked as a LOD. The results looked good from space, however, after creating a player on the planet, the triangles were still very large. The IcoSphere was only subdivided 5 or 6 times due to the lengthy processing times. I was going to base the texturing of the magnitude of the point on the sphere taking into account various factors.

Is there a better method to generate planets without these processing times?


I am only interested in generating the planet surface, not the positioning in the galaxy/universe

I have done research online into different techniques. I've seen people using cube spheres however that looked to have caused a lot of distortion around the corners. I've also seen Octohedrons which were subdivided but I think that'd give the same problems as my icosphere technique

  • \$\begingroup\$ This is not a question with a straightforward answer. \$\endgroup\$
    – Almo
    May 8 '17 at 19:13
  • \$\begingroup\$ The position in the galaxy would have been the least broad of the two meanings.. \$\endgroup\$
    – Gnemlock
    May 8 '17 at 20:26
  • \$\begingroup\$ It sounds like you need a method to generate a given set of triangles at a specific level of detail on demand, rather than recursively subdividing the whole containing 20th of the planet. There are various non-recursive grid-based methods that would give you this capability. \$\endgroup\$
    – DMGregory
    May 9 '17 at 1:18

There is no perfect method for procedural generation of planets, but you should be why they are used, in order to be best armed for selecting a method for yourself.

Consider why planets are generated procedurally:

Storage issues. If you have potentially thousands of planets, with, as you desire, complex and high resolution geometry, that would make for very large file sizes.

Load times. Large files need a long time to load. Enough said about this really.

Rendering times. Larger, more complex(high poly) models require more time to render, especially when lighting them.

Physics & collision detection. More triangles = more planes of collision = more work for the physics & collision systems to do.

The "best" solution would address the highest number of these concerns.

The storage and loading issues can be largely dealt with by having planets generated from a "seed" value, which, when used as an argument in the generation algorithm, will always produce the same result. Thus, no need for large files, but at the cost of computation time.

Rendering and loading can be addressed by using the above technique, in conjunction with polygon tessellation, but this leaves issues with physics and collision, which requires accurate knowledge of the geometry at it's highest detail level.

As you can see, there is no silver bullet for this sort of thing, and, is still debated amongst space sim coders.

Bottom line, do your own research into as many techniques as you can, understand their drawbacks and benefits, and choose the one that most meets your needs, or adapt existing techniques to suit.

  • \$\begingroup\$ Okay thank you I will continue looking. Do you have any good starting points? \$\endgroup\$ May 8 '17 at 19:31
  • \$\begingroup\$ Most companies that make space sims keep proprietary tech like this secret, so it's hard to get concrete information, but I would begin by looking for articles and academic papers on general procedural generation of "worlds". Start small and build towards what you want to do. \$\endgroup\$
    – Ian Young
    May 8 '17 at 19:33
  • \$\begingroup\$ That makes sense. I'll start on Scholar then \$\endgroup\$ May 8 '17 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.