bi_2

DT: Building Castles

Hey everyone! Last week I mentioned that we’ve been using a giant castle from Mindemann on discourse to inspire a bunch of building-related performance fixes. Now that the team has made some good progress, let’s take a look at what they are!

Building Castles

Recap from the video:

  • When we first loaded the save, hearthlings did not even know how to start building the castle, due to the dependency cycle issues Chris described a few weeks ago.
  • Mining foundation then took forever, because everything in a mined block’s terrain tile needs to check if it should react. Yang fixed this by only putting physics on things that REALLY need physics, like placed items.
  • Tony also realized that the merged mining region for the giant floorplan was causing every object in all tiles touched by the castle to update whenever a single block anywhere was mined. Behind the scenes, he’s split up the mining regions so fewer objects have to update every time a hearthling removes earth from the world.
  • Each floor tile seemed to take forever to put down. Turns out, this was because the blueprint uses a block’s color to determine the material required for a piece of floor or wall. This works for large single-colored spaces, but is ruinous on performance when floors have many disparate colored regions in them (like tiled floor, or road). Tony now pre-calculates the material for a section of wall or floor based on the player’s initial choices.
  • Finally for this week, Yang noticed that once hearthlings could get to the walls, it took them forever to build scaffolding. This is because each time a block is placed, all the scaffolding in the structure asked whether it should now be one voxel higher. Yang fixed this by having the scaffolding only update if it needs to. When you go from one floor to another, however, all the scaffolding will still need to update, so all your workers may still go idle at this point as they figure out what all they need to do next.

One interesting outcome of this exercise was realizing that the building systems involved above were for the most part correct. However, the performance load from large structures showed that functions and code abstractions that look, in theory, clean from a design POV (having floors all merge together into one floor entity, abstracting material out by color to save storing 2 pieces of information) must be revisited and reworked when processed at scale. The resulting models may be less conceptually clean, but will run faster. Maintaining the code going forward may be more difficult as a result, which is why performance tuning is sometimes saved for the end of a software project. However, in this case, unlocking the ability to build large structures should also reveal other correctness issues for us to fix, improving the breadth of building in two dimensions.

There’s still plenty more optimizations to go, and bugs to fix, so look for more building and performance improvements in the week to come!

Other News

The stream schedule this week is normal, except that Tom’s Tuesday stream will start an hour early, at 5:00pm PST.