The Cave Problem (Solution Coming Tomorrow)

Before yesterday, the framework’s chunk generation process could be separated in two major steps: the terrain and the props. The terrain is optimized to generate landscapes (the ground and cliffs, general landmass, etc.), and the props step is optimized to generate independent structures that may require a specific environment to be placed in (for example a tree might need dirt and 10 blocks of air). In that version of the framework there was only one type of prop, and it could only scan raw terrain without other props for a valid placement location. This basically meant that props couldn’t see each other when being placed. Even if they were placed after all the other props, they could only see the raw terrain shape and notht eother props. 

This prop system was fast and efficient but prevented using it to generate terrain structures. For example, it was almost impossible to recreate vanilla caves, and have them pierce the terrain surface like they normally do without ending up with floating trees. This is because when trees were being placed, they could only see the raw terrain without any caves (since caves are props as well, just made up of air), and so the tree could easily pick a spot which actually had a cave opening.

The generation pipeline looked somewhat like this (very simplified):

1.  start chunk generation
2.  generate terrain
   a.  start parallel process for each column batch
   b.  a lot of calculations and interpolation
   c.  calculate block type based on depth
3.  generate props that could potentially touch this chunk
   a.  start parallel process for each prop
   b.  create/retrieve prop spot
   c.  generate a limited terrain patch required by the prop’s spot scanner
   d.  scan the patch for a valid location
   e.  generate prop at location if valid
4.  transfer all blocks into external container

The system needed to be changed to allow for some props to see other props when scanning for the spot. As you can see in the pipeline, at point 3.c. the engine generates the raw terrain (important to note that the prop origin could be outside the current chunk) to scan for a proper spot for the prop. The generator shouldn’t (and doesn’t) have access to the adjacent chunks, hence why we generate the raw terrain from scratch when scanning for a prop location.

To solve the floating-tree-cave-opening issue, I rewrote a large part of the process. The first two design attempts resulted in a minute per chunk generation time, which is impossibly slow and inacceptable. The third attempt works very well, is quite fast (~6ms/chunk) and still has a lot of room for improvement, and also brings some additional benefits. 

If you’re brave and understand Java you can dig into the source code of the framework to see what this last attempt is, but for everyone else I will be posting another article tomorrow detailing the solution.