I doubled the world size.
Specifically, I doubled the default size of the tree’s and terrain in every dimension. That’s 4 times as much area and 8 times as much volume.
The creature’s, rovers and grass are all still the same size as before, but a size 1 world in 0.9.0 will cover four times the area of a size 1 world in 0.8.0, the 6 meter tall tree’s are now 12 meters tall, and the cliffs are twice as high.
This was a good move. The world is still pretty tiny by real-world standards, but it doesn’t look tiny anymore. It is now a lot easier to believe that baby Primum specium actually are their canonical 30 centimeters.
Of course, some things have had to be changed to support this…
Ground textures had to be re-sized to keep them from noticeably pixelating at double size. The tree’s are also noticeably low res, but I haven’t addressed them yet.
Gameplay-wise, I’ve doubled the creature speed modifier, meaning the reduced density of tree’s and creature’s shouldn’t overly impact survival. I’ve also increased the sight and hearing range modifiers, for similar reasons.
But anyone who has played the game with World Size 2 knows it had a few problems. Some of these were easy fixes: increasing the size of the tree’s as well meant I avoided any of the scaling issues the vegetation simulation had. Grass density was trickier, since grass is tied to the LOD grid, but still ultimately a simple matter of multiplying the amount of grass by 4.
But the most noticeable problem was those Out Of Memory exceptions you could generate by creating over-sized worlds.
I had already reduced their frequency for 0.8.0 by addressing the memory problems in the tree simulation, but they are still there. This is at least partly because, in the released versions, I’m offloading grass vertices for the entire map to VRAM at the start of the game.
That’s a lot of grass vertices: enough to cover the entire map in the highest density grass. Simply making them fade out when you’re not looking at them doesn’t remove them from memory. And this is VRAM, not RAM. Your graphics card generally has a lot less memory than your computer.
Of course, I didn’t implement it like this for no reason. Sending a large number of grass vertices from the CPU to the graphics card is a slow operation: continually doing it on the fly so we needed to only store the vertices around the camera would be prohibitively expensive and cost a few frames per second.
But, that wasn’t going to work for 4 times as much grass, so I had to come up with an entirely new way to render grass: one that didn’t require sending grass vertices to the GPU every frame, and didn’t take up more memory than we needed.
The new system looks almost identical, but it acts significantly differently. To start, we only generate enough grass for a small area in the north-western corner of the terrain. Then we send those vertices to the graphics card when the world is created.
Then, when the game is actually playing, the camera continually tells the grass shader where it is on the map and the shader translates the vertices horizontally to follow the camera around. So as you walk the map, you’re not seeing a unique set of grass billboards: you’re seeing the same square set tiled across the map, like a texture.
But translating horizontally would only work on a flat world: the grass still needs to actually appear at the height of the terrain. This is accomplished by handing the shader the terrain’s height-map itself, along with instructions to translate vertices vertically to meet the terrain.
Interestingly, this means the grass doesn’t *exactly* follow the terrain geometry anymore. The texture is interpreted by the shader by interpolating smoothly between pixels, while the geometry is subdivided into sharp triangles. If the terrain wasn’t smoothed, this could potentially be quite noticeable, but unsmoothed terrain would be ugly anyway so I consider that a small price to pay.
So, rather than costing CPU time, the cost of the new grass is more vertex shader work. It still has the potential to impact performance when you’re GPU-bound, but not by too much: I’ve lost 2 or 3 fps when playing the game with no creatures to get in the way. Since I expect most players are more interested in having a decent number of creatures wandering about, which puts the burden of work back on the CPU, I’m willing to accept this cost for now (there’s still plenty to optimise in the future, of course).
For those wondering how this affects the Facility Design: I’m implementing an above-ground nursary for 0.9.0. Indeed, that’s a big part of why I’ve increased the world size. Turns out an octagon of fences (a new style of fence, too) is far easier to implement than a method for rendering an underground base.
This will most likely serve as another placeholder, though: there’s still not enough room for any other facilities, and I want to provide room for the rovers, gene lab, museum and AI core. But for now, we only need a single facility: the nursary. A larger world provides enough room for that without subtracting too much space from the wilds.