dannsworldgenerator
patreon
The Terrain SDK
🕑 Added 2021-01-17 17:49:48 +0000 UTCVersion one of the SDK (engine) provided a solid structure to Dann’s World Generator and brought parallel processing and speed. It separated the responsibilities which made it easy to fully focus on an isolated aspect when developing content.
Although it was a great start, the SDK lacked features that I wanted, features that I needed if I want to push the limits of what’s possible with procedural generation. Props couldn’t see each other when generating, so a tree for example, had no information on whether it was hitting a cave wall or a cliff-side, or growing too close to another tree. The terrain scanners (used to pick a proper spot when placing a prop) were also oblivious to other props. Location scanners for prop placement could only see terrain shapes, and scanning larger areas was very expensive. To solve these problems, I had to rethink the whole approach I took with the first version, and I realized that an almost complete rewrite was necessary. I wanted the new SDK to solve all of these problems, and also provide a solid structure that would make adding massive features and changing the processing pipeline easy.
After months of additional research and development, the new engine is completely modular and abstracted at its core. The processing pipeline is composed of stages, each stage with its isolated responsibility and implementation, such as terrain generation, prop generation, etc.
A lot of time was spent distilling and separating the different abstract responsibilities, and carefully implementing them.
The props are now aware of each other when rendering, resulting in much more natural placement and eliminating a lot of glitches present in vanilla and DWG. Scanning large areas to find appropriate locations to place a big prop is extremely fast and accurate. This allows for the use of advanced and more expensive scanner algorithms, such as determining if there’s tree nearby, or if its next to a cliff.
The new SDK allows the use of large-scale terrain transformation processors. This feature in itself is enormous, with numerous ground-breaking applications. To give you a taste of how important this is, here’s a few things I’ll be developing. Real and beautiful waterfalls created by rivers flowing from higher grounds to lower grounds. Terrain erosion with structures and shapes generated with particle and physics simulation. Cavern generation through geological processes, realistic surface cracking and sinking. With environment-aware prop generation, where the props look perfectly integrated into their surroundings, both buildings and organic props will benefit. The large-scale processing feature could also be used to eliminate mistakes and bugs in classical terrain, such as unwanted floating bits and islands. The processing stages offer nearly perfect performance and CPU scalability. The more cores you give it, the faster it will generate.
Dann’s Terrain SDK is a massive upgrade to the previous engine, and going to be the core of my future projects.
Soon you’ll see a post that will dive into the world of Gliesa!
Comments
CodyDHarkins
I am not sure if even possible (unfamiliar system). The thought was that starting from some location in the chunk, the algorithm progresses in four direction (variable distance). Decides in those locations if or what prop to be placed and how big. I am now seeing that it would require some map that keeps track of what areas have already been filled in so the algorithm can be told "that location is already in use." My idea keeps a props map separated from world knowledge and uses it to keep track of were props have already been placed. The Bredth First Search hopefully could keep the checking to four directions per new prop placed. I also expect a ring of expansion, on the map, to just get bigger and that could bring trouble for list of new props getting big. (not sure about limitation)
Dan Negura
In which way would that be implemented? Would it search for valid locations?
CodyDHarkins
I wonder if a bredth first search could have allowed for unique locations for each prop.
