DevLog

 
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.

Follow @universesandbox

Image: Interface prototype for Surface Grids data map.

Time for our round four update on the development status of Surface Grids and Lasers. If you haven’t seen them yet, check out Dev Update #1, Dev Update #2, and Dev Update #3.

A primer on Surface Grids for anyone not familiar:

It’s a feature we’re developing for Universe Sandbox (meaning it’s not yet available) 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.

Interfacing

In this update, we’ll take a close look at a part of the new user interface (UI) for the Surface Grids feature, specifically the data map. While the UI doesn’t affect the Grids simulation itself, it determines how easy and seamless it is to view and interact with the Grids feature. And as with other features and the experience as a whole, it is the UI and its accompanying user experience (UX) that ultimately determine how accessible and enjoyable Grids will be.

In previous posts about Surface Grids, we’ve shared screenshots that show a floating panel with a Grids data map, like this:

We had been using this panel for debugging, but it was never a representation of our end-goal for its design. We strongly believe that floating panels (the kind that can be dragged around the screen and can overlap) in applications and games can be very cumbersome; while they offer a lot of flexibility, managing them can become a task in itself. So instead of actually playing the game, you spend most of your time resizing them and moving them around to make sure they’re not in the way of the gameplay or other parts of the interface.

So instead, we try to create an interface where you don’t have to think about panels at all — where they’re intelligently docked, organized, and out of the way.

Below is a prototype that shows the Surface Grids data map first located within the Properties panel, then popped out to a larger view, then docked to the left. The panel is then duplicated and switched to a graph.  

Disclaimer as always: Anything discussed or shown may not be representative of the final release state. It’s also likely this end-goal design (which is subject to change) will be reached over multiple releases.  

Iteration Behind the Scenes

Dan is the creator and director of Universe Sandbox and he also leads the way in designing its UI and UX. Recently, Dan started using Adobe XD, a tool for designing, prototyping, and collaborating on UI/UX for applications. It has already proven a valuable tool in UI iteration for Surface Grids.

Designing for UI/UX can be challenging in its early stages because it’s often hard to get a sense of how it feels to actually use it until you can literally use it. Some things might seem great in design, but once you program it in, you realize that it lacks a certain flow, or feels awkward next to other interactions, and then it’s back to the drawing board. XD’s ability to create an interactive prototype can cut out this need to implement the UI for testing, which means it’s also easy to give others on the team a sense of what the designer is imagining. All of this can make the iterative process of design and feedback a lot faster and more efficient. (And no, this is not sponsored by Adobe! But we do enjoy their tools.)

Check out the interactive version of the prototype shared above: Interactive Surface Grids UI Prototype

This is very simplified and intended to only show new parts of the interface. You can click anywhere on the screen to highlight in blue the areas that can be clicked.

And here’s a behind the scenes look at Dan’s Adobe XD workspace for the above interactive prototype (large row on the right) and some other prototypes. Each rectangle is a different view of the UI, essentially creating interaction through branching paths triggered by click-areas.

What’s Next for Grids

We can appreciate that showing the UI may not be as flashy as a GIF of a molten Earth, but we’d like to show how much work and iteration, from all different sides, goes into a single feature.

Chris is continuing to work on the technical implementation, Jenn is working through the science, and Georg is gussying it all up — we’ll back in two weeks to take another look at our progress.

Bonus Galaxy Preview!

We’re really looking forward to Surface Grids, but let’s not forget the new galaxies that are coming. Here’s a preview showing some recent visual upgrades and the ability to see orbital paths for the individual galaxy particles.

Follow @universesandbox

Image: Early work on visualizing Grids data on a partially molten Earth, pre-beautification.

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

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.

Visualize It

In our last update, we talked about getting the new technical framework set up and working on the scientific-data side of Grids. In this update, we’ll focus on the third primary component of this feature: the visuals.

We can divide this visual component again into two separate challenges: 1) rendering the data accurately and 2) making it look good with visual magic.

Right now, our graphics developer, Georg, is working on the first part, rendering the data accurately. We talked before about the importance of getting the data right, but that’s really just the first step toward Grids as an accurate and interactive feature. The 2D data map that simply color-codes the data looks neat, but the first thing you see, and the thing most people want to look at, is the planet itself. So accurate data becomes much less useful if it’s not accurately represented in the planet visuals.

Visually representing this data is another tricky process. At its most basic, we need to nicely blend each possible material (silicate and water) with each of their possible phases (solid, liquid, and gas), as determined by elevation and temperature data. But it gets even more complicated: we need to account for elevation slope, the fact that phases aren’t just on or off but can exist somewhere in between (like partially-molten silicate), and the very likely possibility that seemingly opposite materials and phases can exist right next to each other (think of a high-powered laser melting ice).

From Coast to Coast

 
Another big challenge is working with the difference in resolutions. The Grids data is a low resolution compared to the visual resolution we expect for planets, especially ones that we are very familiar with, like Earth or Mars.

One good example is coastlines. In the GIFs above, take a look at the shimmering squares in the oceans. Each square is a point of Grids data. Compare that to the coastlines. If their outlines followed the same resolution, the continents would look more like a LEGO creation than the masses of land with all their nooks and crannies we’re so familiar with. We use a high-resolution heightmap for Earth, which works pretty well for accurate coastlines and large lakes. But the tricky part is getting this to play nicely with our lower resolution Grids data, so that only part of the Grids cell shows water and the other part shows land, i.e. accurate coastline.

All this talk of complex challenges makes it sound like this is difficult work. It sure is. But since this is a rewrite of Grids, we’ve done a lot of the heavy lifting already. Not to say it’ll be a walk in the park, but we at least have a good sense of what we’re up against.

Keep in mind these GIFs and screenshots represent works-in-progress and are tuned more to our current needs for development and debugging than they are for your viewing pleasure. All of this can and will change!

What’s Next for Grids

This has been another good couple of weeks for Grids development. There’s still plenty to do with getting the visuals right, plus eventually we have to turn our attention away from our favorite planet, Earth, to take a look at Mars and other randomized, generic planets and bodies.

Then once we start seeing all the data reflected accurately in the visuals, Georg will begin beautifying it with lighting, normal mapping (for bumps and dents), glows, etc, all the while multitasking with his work on the new galaxy visuals (read more about our work on new galaxies).

Here’s a glimpse of some preliminary graphics magic that demos improved lighting and emphasized normal maps (look at those ridges!), plus a bonus peek at part of our Unity development environment.
 

Thanks for reading! We’ll be back in two weeks with another update on Grids development.

Until then… did you know we started an official Discord for Universe Sandbox? Join us on Discord

All this graphics talk making you think it’d be a lot of fun to work on problems like these? Good news, we’re hiring a graphics developer! Learn more & apply

Follow @universesandbox

Image: A work-in-progress view of temperature data for the Moon’s surface during Bombardment of the Moon simulation

Here’s our round two update on the development status of Surface Grids and Lasers.

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.

If you haven’t seen it yet, check out our blog post from a couple of weeks ago (we’ll call that Dev Update #1) where we talk about our decision to delay Surface Grids in favor of a rewrite that will better meet our Quality Standards for Awesome Features.

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.

Getting Up to Speed

We’re happy with the progress that we’ve made so far on the new Surface Grids. We haven’t encountered any significant roadblocks (knock on wood) and the results we’ve seen are very promising.

Feature development in the beginning can be very exciting, because it can seem relatively quick to set up a framework, especially with a feature like this, where it’s a rewrite of a model we put a lot of work into. Early technical implementations can also give us a good sense of what’s to come and what is possible. At the same time, they can be a little less accessible from an outside perspective because they don’t have any of the polish and pizazz of a complete feature. At this point progress can also be a bit misleading, because often times the longest and most challenging part of development comes later, when we’re tweaking, polishing, finding and fixing bugs, and making sure all the complexities of the fully fleshed out model play nicely with each other and the rest of the simulation.

But let’s not get too ahead of ourselves — here’s a look at the progress we’ve made so far.

Zoom, Enhance!

As mentioned in our last post, concerns about performance with our old model played a significant part in our decision to do a rewrite. Performance relates directly to the resolution of the model: a higher resolution means more computations and slower performance. But the resolution of the model determines just how detailed the data and visuals can be, so a lower resolution model makes it that much less interesting.

The old model was scalable and the image below represents a fairly low resolution for the model, but it was also the baseline that we were working with because of performance concerns. In other words, we could run it at a higher resolution, but performance quickly took a hit once there were a bunch of objects in a simulation all running Surface Grids. Turning down the resolution helped, but not enough.

Compare that with the resolution of this new model, where each pixel is equivalent to a grid square in the above image.

See the difference? Generally speaking, the new version of Grids is at least 100 times faster than the old version. Yes, that is much, much faster. And it makes us very, very happy.

This clip shows a data map of Earth’s temperature as it becomes tidally locked. And, importantly, there are also 99 other Earths in this simulation all running their own equally high-res Surface Grids model.

A big thank you to our lead developer, Chris, for creating this new, powerhouse version of Surface Grids.

Water World

There’s another new feature in this model that we didn’t have before: simulated water flow.

Currently water flow is affected by elevation, which in turn can be affected by impacts. Our wish-list for the future of Surface Grids includes elevation-editing tools, but right now we’re not expecting those anytime soon (including the first release version).

This clip briefly shows typical water flow on Earth (currently the model runs even while paused) before it’s affected by an impact with the Moon.

Water flow is a pretty experimental aspect of the model right now, so it’s especially likely this will change significantly as we continue development.

Getting the Data Right

We’d consider the whole of Surface Grids a wash if the data wasn’t based on science. But good news: it sure is based on science.

Jenn, Universe Sandbox astrophysicist and developer, has been busy getting all the data and numbers right in the technical framework. Sometimes a model will produce interesting and compelling results, but if the numbers aren’t based in science and the results aren’t showing what we’d expect to see for an accurate (though simplified) model, then it doesn’t meet our goals for a Universe Sandbox feature.

Building an accurate, generalized model for this is no easy task. It has to handle a range of materials (silicate, water, etc.) at different phases (solid, liquid, gas), all determined by other factors like elevation and temperature; each point has to interact with the rest of the grid, the rest of the Universe Sandbox simulation, and any user input; it has to run in real time; and in a normal state, it has to produce something that looks like the Earth or Mars we’re familiar with. Fortunately, this is well tread territory at this point, as Jenn solved a lot of these problems with the last model of Surface Grids.

What’s Next for Grids

We feel very good about the progress we’ve made so far and we plan to keep moving forward at this pace. We’ll continue with the technical implementation while also adding and double-checking the scientific layers of the model.

You’ll notice in the tidal-locking clip above that we only showed the data map, not the actual planet itself, as its local temperature shifted. That’s because there’s not much to see yet (compare to the visual state of the last model as seen in the last post). We love data, but we also love planet surfaces that look pretty and glow. The surface visuals are an important part of Surface Grids, and now that we have the technical framework laid out, it’s time to make it look good. Our graphics developer, Georg, is just getting started on these visual aspects, which are also based on his previous work on the old Grids model. We look forward to sharing his work in a future Grids posts!

 
Follow @universesandbox