JSON Terrain
Posted: Sun Feb 21, 2016 2:09 pm
Due to reading an SoA Article some months ago I decided that it would be nice to be able to define terrain definitions using a structured data format.
Since we already have a loader for it I picked JSON for the data format, and there's a nifty editor called JSONEdit to make dealing with it a bit easier.
The idea itself is pretty simple, you define nodes which can generate noise, provide a constant value, raise something too a power etc.
Each node can perform one of 4 operations (3 in that article) on the data like ADD, SUB, MUL, DIV, in addition to clamping the value.
Each node can have any number of children, and each child node can have it's own children, each call to a child node modifies the previous nodes output in some way until it reaches the last child in the hierarchy.
That said there are some subtleties which are currently kicking my arse :(
In fact that is why I am posting here and now :)
For example the current terrain configuration being loaded is within "\data\terrain\terra.json" which produces some cool terrain however there is a more complete version within "\data\terrain\terra_bak.json" that ... um, goes completely insane and breaks the rendering of the planet so completely that the game actually just dumps you in space somewhere... not a great result.
What would be great is if someone can spend an hour looking through that Call method and tell me if I've done something that is stupid, odd or just confusing. I ask as I have gone a little bit code blind from looking at it and will be resorting to pen & paper now to work through the logic, again.
This code/branch will not be used verbatim!
I don't want to panic anyone so just to make this clear: my branch "terrain-json" is purely for idea development and testing, it will all be completely rewritten from master when the time comes.
In fact you can ignore 99% of that branch and just take a look at the Call method within TerrainNode.cpp as this is where all of the work is done.
Thanks and hopefully once this is working we'll have a way of defining planet types without writing code, and from that, of generating terrain generating shaders again without (much) programmer input.
That's the dream, of opening up all the terrain stuff to non-coders.
Other things:
Since we already have a loader for it I picked JSON for the data format, and there's a nifty editor called JSONEdit to make dealing with it a bit easier.
The idea itself is pretty simple, you define nodes which can generate noise, provide a constant value, raise something too a power etc.
Each node can perform one of 4 operations (3 in that article) on the data like ADD, SUB, MUL, DIV, in addition to clamping the value.
Each node can have any number of children, and each child node can have it's own children, each call to a child node modifies the previous nodes output in some way until it reaches the last child in the hierarchy.
That said there are some subtleties which are currently kicking my arse :(
In fact that is why I am posting here and now :)
For example the current terrain configuration being loaded is within "\data\terrain\terra.json" which produces some cool terrain however there is a more complete version within "\data\terrain\terra_bak.json" that ... um, goes completely insane and breaks the rendering of the planet so completely that the game actually just dumps you in space somewhere... not a great result.
What would be great is if someone can spend an hour looking through that Call method and tell me if I've done something that is stupid, odd or just confusing. I ask as I have gone a little bit code blind from looking at it and will be resorting to pen & paper now to work through the logic, again.
This code/branch will not be used verbatim!
I don't want to panic anyone so just to make this clear: my branch "terrain-json" is purely for idea development and testing, it will all be completely rewritten from master when the time comes.
In fact you can ignore 99% of that branch and just take a look at the Call method within TerrainNode.cpp as this is where all of the work is done.
Thanks and hopefully once this is working we'll have a way of defining planet types without writing code, and from that, of generating terrain generating shaders again without (much) programmer input.
That's the dream, of opening up all the terrain stuff to non-coders.
Other things:
- the SoA Article only uses each file for one planet whereas I'll need to, LATER, add a way of re-using them.
- ignore the rest of the branch, much madness and hacking lies in there, stand well clear - comments on those parts will be ignored :P
- I am very aware of NevilClavain's similar work - yes, I am jealous.
- The mistake is probably simple, I have mostly likely just been dumb.