Here’s our round six update on the development status of Surface Grids and Lasers. If you haven’t seen them yet, check out Dev Updates #1, #2, #3, #4, and #5.

This will be a smaller update than usual because we’re focusing our efforts on the last sprint for the new galaxies we’ve been working on. We hope you won’t have to wait long for their official release, but if you’re feeling impatient, you can check them out by opting into the experimental version.

A primer on Surface Grids for anyone not familiar:

It’s a feature we’re developing for Universe Sandbox that makes it possible to simulate values locally across the surface of an object. In effect, it allows for more detailed and accurate surface simulation and more dynamic and interactive surface visuals. It also makes it possible to add tools like the laser, which is essentially just a fun way of heating up localized areas of a surface.

Keep in mind this is a development log for a work-in-progress feature. Anything discussed or shown may not be representative of the final release state of Surface Grids.

Set Phases to Accurate

Our last dev update focused on the upcoming galaxies, but at the end we mentioned how Jenn, astrophysicist and Universe Sandbox developer, was working on vapor flow for the Grids model. We also joked that the challenging part here is creating this “accurately and performatively without single-handedly developing Weather Simulator 2020.” Unfortunately, the joke is all too real!

That doesn’t mean we are actually developing a complex weather simulator, but there is nonetheless complexity. While developing the vapor flow model, Jenn has been doing her homework with research into fluid systems and geophysics (if you’re looking for some light reading, you can check out Lectures On Dynamical Meteorology, Geophysical Fluid Dynamics, and An Introduction to Planetary Atmospheres).

The first part of vapor flow is determining what exactly is vapor; this is done by phase tracking, which determines what phase each material is in, based on temperature and elevation. For water, vapor is its gas state, then we need to see where it’s headed from there — whether it’s evaporating or condensing at the dew point, depositing, if it should be boiling away completely, etc. If it’s remaining as vapor, then the model accounts for a few factors to move it around: there are the prevailing winds which vary by latitude, are affected by planet rotation, and cause east-west movements (as seen in the GIF at the top), and there are temperature differentials from thermal flows and elevation that cause north-south movement (still a work in progress).

Image: The “heat map” shows vapor amounts (not vapor flow), where red is higher amounts and blue is lower. The poles are both much drier, and because there’s much less evaporation over land than oceans, you can see the outlines of the continents.

We want to stress that this is necessarily a very simplistic model, largely limited by its low resolution and the amount of memory we can allocate for this single component of Grids. There are lots of things missing that make this very different from more complex weather simulations — there are no vortices, so there won’t be anything like hurricanes, it is only a 2D simulation with no layers through the vertical dimension, and it’s fairly low resolution.

But we hope to use this data for the resulting local vapor amounts to have rough approximations for clouds, ice caps (for Mars, this effect happens with CO2 vapor flow), and for the future implementation of basic life simulation (vegetation), it could affect growth in dry and wet areas.

Loading…

In our last post, we also mentioned Chris’s work on saving and loading with Grids. This component of the feature obviously isn’t as interesting as, say, lasers, but at the same time, it’s essential to get it right and it’s another good representation of challenges on the edges of new feature development.

Here’s a shortlist of some of the questions and challenges that doesn’t even get into the technical weeds: How can we deal with file type and size limits for different platforms, like Steam Workshop, mobile devices, etc.? How can we maintain file size for fast, background autosaving and quicksaving? How can we get it to play nicely with previously saved simulations with objects that didn’t have all of the Grids data?

We had similar saving and loading questions with the new galaxies: What should happen if you load simulations that had the old galaxies? They won’t look and function the same. Should we change their shape and motion to use the new model, or should we preserve appearance? Is it okay to change sims on Steam Workshop that are very popular?

Saving and loading is something we all hope just works seamlessly and shouldn’t be something the player ever has to think about — which are both telltale signs that there is little room for bugs, errors, and bad user experience (UX). Thankfully, we have answers to all of these questions!

What’s Next for Grids

We’re hoping to make some good progress again on the visual side of Grids, rendering all of that wondrous data into some nice planet graphics. We’ve been recruiting our graphics developer, Georg, to work on some other projects (like the now so gorgeous galaxies), but it’s time for Grids attention again.

Thanks for reading! We’ll be back in two weeks with another update on development. And hopefully before that, we’ll have our next big update with new galaxies.