Desktop Tuesday: Hydrodstatic Bulk Pressure Simulator

Hey everyone, welcome to another Stonehearth Desktop Tuesday! For the last few months, Albert has been working really hard on improving water’s stability and performance. Last week, we finally checked this update into Alpha 22.5, and we’d really love for you to bang on it and see if it’s behaving.

Water Is Complicated

Recap from the video:
Back in 2014, when Albert first started working on water, his goal was to make a representation of water that behaves intuitively realistically, works in a voxel world, and that uses cubemitter waterfalls, not slopes to communicate downward movement, so it would be more fun to look at.

To solve this Albert evaluated and decided against voxel-by-voxel water (finite element analysis) which he felt as a simulation would be too slow to calculate if you did a lot of work with moats. Instead he picked decided to simulate whole bodies of water that would flow based on pressure mechanics. He calls his system a hydro (water) static (waterfalls, not waves) bulk water pressure simulator. In his system, water follows the following rules:

First, it takes the shape of it’s container, so if you have a square container and deform it, the water body will deform also. Second, it flows from high regions to low regions, as in the example of this waterfall. Third, if 2 bodies of water are merging, height difference b/w them determines rate of flow. If you create a 2nd pool beside this first one, at first the 2nd one will fill quickly, and then slow as they reach height parity. Finally, When you create a waterfall, the rate at which water spews out changes based on the amount of pressure. So at the top of a water body, sprays gently, but deeper down where there’s more water, sprays faster

In our original system, any behavior that required 2 bodies of water to merge was super buggy because water can be any shape, and it turns out that it’s quite difficult to get 2 polygons of arbitrary shape to merge together. In the original system, Albert solved this by calculating the surface area of the interface region, and then, on a voxel by voxel basis, did separate calculations for each square of water to determine how water should flow from it into the adjacent body. This means that if you have a square that’s 3×4, you do 12 calculations for each voxel point of merging.

After 2 years of fixing bugs, so many that it was hard to make forward progress on other water features, much less water gameplay, Albert, like Chris w/ building, flipped a table on the original system, and decided to rewrite the way water bodies merge. +

In the new system, he calculates the aggregate surface area of all the places where the two water bodies touch and then does the merge considering the entire surface area, so there’s just one calculation, instead of one for each voxel where there might be joining. Though the single calculation is more complex, it results overall, in fewer bugs and better performance.

Some additional perks Albert was able to roll in include the fact that cubemitters emit from just the part of the block that’s water, instead of the whole block. Also, puddles that flood your town evaporate slowly, block by block.

We’re very aware that all this work treats water purely from a simulationist point of view, rather than from a gameplay one. We look forward to getting to that work but I wouldn’t look for it until after Richard and Luke work through their revisions of number of higher priority gameplay systems. In the meantime, please make a bunch of rivers and moats and let us know how the simulation improvements are holding up for you!

Other Announcements

Angelo and Max will do an engineering stream on Thursday at 6:00pm PST! This will be Max’s first stream so be sure to give him a warm welcome.