… a piece of…
don’t do this. i mean don’t look at other solutions or other examples. most of them is not what they are in fact. all of “space” games with their “real-scale” planets and with “real physics” and bla bla bla - in fact is poor fake and pretentious.
i’m working on my own project in free time. look at some weird (quickly-made from tests) screenshots:
scaled heights:
another planet:
i have a prototype where you have a system with 2000 stars which is with procedural generated planet systems and all of that with seamless travel from one planet to another, from one star to another.
all work which i’ve done can be finished not more than one week. yep. there is far far away from something good, but there are working big-sized planets even with foliage and some kind of water.
all your main problems will be:
- optimizations for “60 fps” and good view
- collision generation at runtime
- precision problem for big planets and big world
generation of “planet” mesh is not a problem. best choise is cube mapped to sphere. okay, i know that there is an icosahedron-solution (or hexahedron… nvm) with good results. but how you will optimize them and texturing? there is not simple for icosahedron, but very simple for cubes. one more problem of icosahedron is “more calculations” and it is not obvious. cubes can be done after you take a look at them - very obvious and simple, easy in calculations.
are you need to landing? okay, are you need to walk at the planet surface? implement runtime collision generation. if your planets will be procedural that you will be use any kind of optimizations. you could not store full-precision planet on your RAM or HDD. that means you will be generate it runtime and regenerate/generate collision for it. in-engine runtime collision generation works too (too too too too too tooooooooo) slowly. just believe me, i’m using it. you can try do it with threads. okay, don’t use in-engine implementation of threads with collision generation. it is not working in package builds.
precision problem. if you are using float (you using it, look at actor location, for example) you have just 6 decimal digits, not more. that means if you will be use big planet radius and planet center will be at 1000000 (1M) coords - your planet will be shaking and moving (and spin around) with steps. it looks weird and you could not play on the planet surface with that.
so you have to do some “scale” changes for all objects: planets, stars, buildings on planet surface, foliage, space ships etc. you have to implement your own “scale-based” physics and movement. you will see problem with movement while you will change your scales.
do it alone is bad idea cause there are lot of problems with engine, with math calculations, with graphics, with gameplay etc.
spherical gravity is easy to implement. look at gravity vector implementation or just look at vector math. it is a basic math.
“real-planet like view” can be done with coherent noise or with algorithms like diamond-square.
but without good texturing planets looks like… you can see my screenshots, i’m working on it. now i have bad texturing.
more screenshots:
as you can see sometimes it looks good, but mostly weird. need more complex textures and more fine landscape setup.
start to learn how to do good textures procedurally (or manually if you want).
// –
sorry for my english. enjoy