Frank was ill for most of last week, so the work on the architecture changes has been on hold. Meanwhile I worked with Michael on audio, and did some prototyping for a new terrain engine.
Read on for the juicy technical stuff. You know you want to.
Michael started replicating the old wingsuit sound effects I made with his own fancy new sounds.
Note that the goal was mostly to attain feature parity between the old sound implementation and the new FMOD system. Now that we have done that, Michael can work on making it actually sound better.
We reviewed the results at the end of the week:
- The sounds already have way more interesting texture. This is actual wind, instead of filtered white noise.
- We should split the sounds up into individual components. The initial design uses very few sounds to communicate a lot of things, but we can afford to be much more granular. We’ll have flavor layers that mimic the interaction of the wind with your ears for example, not just the basic suit sounds.
- This current iteration is lacking a lot of high-frequency content, hence it sounds like it’s in the background.
- We can add lots of incidental cloth sounds when the limbs move.
- We can drown out certain categories of sounds as your speed (and thus the wind intensity increases.
He also made some very juicy user interface sounds which I’ll have to share with you later.
I’m meeting with Micheal tomorrow to hear the second iteration of the wingsuit sounds. Last we spoke he was considering throwing himself against trees to record to most authentic collision sounds. I’m curious to hear how that went down.
I may have mentioned this before, but we’ve about reached the limit of what we can do with Unity’s built-in terrain engine.
To Voxel or Not To Voxel
(Spoiler alert: No)
A new terrain engine, then? Yes, or at least we’re seriously considering it. But what would we make?
When you start writing something from scratch the sky is the limit, really. I’ve done a lot of research, looking at the various techniques other games have used over the last decade.
Voxels are the hip thing at the moment, and I’d be lying if I said I’ve not been tempted by them. A big limitation of heightmap-based terrain is that the geometry can only ever deform along its vertical axis. It’s fundamentally two dimensional.
Imagine draping a table cloth over a random arrangement of tableware. You’d recognize the peaks created by the wine bottle underneath, you’d see the hills created by the wine glasses, the plates, the cutlery. But the cloth would never ever fold itself such that it would follow the contours of the objects around it underneath. You’d see the rim of the glass clearly, but information about the shape of the stem wouldn’t be visible at all; the cloth can’t represent it.
Heightmap terrain is pretty bad at rendering steep cliffs. It cannot do overhangs (as it can’t fold over itself), and it cannot do caves either (it can’t have holes connecting different parts of the surface). Games with heightmap-based terrain that do want these features require 3D artists to model these specific features in external 3D modeling apps, and then place them on the terrain manually.
Voxels are a fundamentally 3D representation, and a such do let you model of all kinds of cliffs, overhangs and caves. Everything gets hugely more complicated with Voxels though. They far less straightforward to create polygonal geometry for, smooth level of detail transitions are harder still, they use far more memory, and content creation would likely take longer because of the extra computation involved. I thought about creating a voxel terrain system that offers all these features, with draw distances op to hundreds of kilometers, and decided that it would take at least two years to make.
So voxels are most likely out.
Let’s say we want a much-improved version of Unity’s heightmap-based terrain system though, what would it look like?
Volo’s terrain is based on heightmaps with a resolution of 1 pixel per meter. We need the terrain resolution to be at least this high to generate interesting geometry to fly through, and without it we couldn’t generate the little rock formations and crevices that we love. Fun fact: when I started making the Swiss Alps terrain last year I used double this resolution, and it felt heartbreaking to have to halve it.
But we also want to see all the way to the horizon, many kilometers away! If you tried to keep all of that high-resolution terrain in memory you’d make most of today’s gaming PCs weep in agony.
Luckily we don’t need all the detail all the time. You can’t distinguish the shape of individual rocks of far away terrain, so there is technically no need to have that detail loaded. We could stream terrain details in and out as we fly, and save a huge amount of memory.
With Unity you can load chunks of terrain dynamically and patch them into existing terrain, so technically you *can* stream details as you move through the world. The catch is that all loaded terrain chunks have to use the same resolution, otherwise the edges of the chunks don’t connect properly. You can see this in the current v3.x builds of Volo, where the low-resolution terrain outside the borders has huge gaps where it transitions to the high-res playable terrain. In turn, this means you would have to load far-away chunks at the same resolution as nearby chunks, even though they might only represent a couple of pixels on your screen! This wastes a lot of memory and rendering resources, and it greatly limits the view distances we can get.
For the new system I’m making sure we can load chunks of terrain in at arbitrary levels of detail, so far away chunks use only a little bit of data to represent far away terrain.
Level of Detail
You’ll know from playing Volo that Unity’s terrain system doesn’t have smooth transitions from one level of detail to the next. When you cross a certain distance threshold it pops in a higher resolution version of a bit of terrain, and this is very noticeable.
This stems a lot from how the terrain engine was meant to be used, I think: from an on-the-ground perspective, moving at relatively low speeds. But when you’re flying at high speeds the terrain is just popping all the time.
I’m playing with a technique from this paper, which animates the vertices of each terrain mesh to exactly match the next level of detail as you get closer to it. Here’s a quick wireframe demonstration (view it on HD):
Foliage and Detail Rendering
I haven’t thought about this too much yet, but I think we can do better than Unity here, too. The way it loads and renders grass and trees is one of the biggest causes for slowdown in the current versions of the game (especially in VR).
I know both Big Robot and Facepunch are both rolling their own grass rendering, and I might take some inspiration from that.
Over the last two months I’ve taken the occasional hour to toy with these ideas, but I should really take a full week to make some big strides. My attention is currently divided between the architecture changes and working with freelancers though. Perhaps in a month or so. 🙂
That’s it for last week!