impaktor wrote:Interesting article. I didn't know / hadn't really thought about, how all the noise functions separate and are combined. And he does it using a (seemingly) simple YAML-script. Is the idea to have one for each planet type? One Terra.yaml, and one Luna.Yaml for instance? We have this hard coded in pioneer, as some 20-ish different terrain types, I've heard?
I'm curious about the terrain generation branch that you have been playing with over the years for pioneer. Although I've never attempted to understand pioneer's current terrain code, I've heard it leaves a lot to be desired when it comes to code sanity, so I assume your terrain code is saner? Apart from not suffering from the spiky asteroids (I assume), does the result look better than pioneer's current terrain? Any nifty features to teas us with?
Yes, I see what you did there :)
I guess they just have another YAML file per-planetary-type. Or maybe a selection for each type. For example we have a bunch of different options for instance we have 8 combinations of noise and colours for asteroids (
Terrain.cpp, Line 115). They might have 8 YAML files. I'm not sure how many combinations we have in total but it doesn't seem to produce that great an amount of variation, they're hardcoded, difficult to iterate for developing etc.
I've tried writing a few experimental branches, doing that kind of stuff within Pioneer is time consuming so in the end I wrote an entire separate project just for trying things out. That successfully used noise but the shaders were custom written. I've learn't a lot doing stuff like that but there's still big obstacles that I need to figure out and work around.
There are different parts to Pioneers terrain code. There's the rendering part which has gotten a lot saner since I started hacking at it, that uses a lot less memory nowadays for example. There are still a lot of things that I would like to do to this part and the
terrain texturing is just one example of that.
Then there's the generation
_parts_ which are comprised of the terrain jobs and the terrain generators.
The terrain jobs are an asynchronous job system which can run on any thread in a multithreaded system, so my home PC runs 6 cores, 12 threads, Pioneer launches 11 threads and terrain generation is quite speedy since it will use all 11.
The insane, hardcoded and difficult part are those terrain generators. Essentially everything isolated within the "Terrain" project. That's the part that I would replace with a shader based system, where the shaders would need to be generated at runtime from a JSON (
instead of YAML) based system.
Not 100% sure how it'd work yet, I guess you'd build up a shader from the JSON description, and then set random values based on the JSON files ranges and the RNG using the planets seed. Generate the planet and then texture it at runtime using my terrain texturing work... or something.