HomeGamesUpdatesPricingMethodology
Steam News1 May 20262mo ago

Pigeons at Devlog 5/1/26: Procedural Terrain

Hello! In the past we’ve mostly been secretive about updates until they launch, but like what’s the point of that? So we’re going to try being more open about what we’re working on with weekly (I hope) devlogs.

In this update2

Full notes

Full Mycopunk update

Read the full published notes in a cleaner layout. The original post stays linked below.

Repeated intro

Hello!

What changed

0 fixes4 additions7 changes0 removals
  • Maps
  • Performance
  • Gameplay
changedProc GenAll of our terrain code runs in compute shaders on the GPU, which makes it go really really fast (yes, the levels still take a while to generate - I’ll be optimizing load times as we go AND the 1.8.2 patch today should improve loading times a bit!)
changedProc GenTerrain is split into layers. Every layer runs a function for each voxel (of which there are 21,233,664) that returns that voxel’s distance to the nearest surface. Say we want to plop a big ball into the center of the level - we just calculate:
changedProc GenAs a bonus, here’s a weird terrain layer I accidentally made using voronoi noise.
addedCrashing OutWe’ve been dealing with a fun new crash that seems to be caused by particle systems reading from mesh data. These sorts of crashes are always fun because they only happen on a few computers, and NONE OF THEM ARE OURS! :D We added a debug option that seems to be mostly working as a temporary fix but I’m working on a long-term solution to replace mesh data in particle systems, which should also help performance when a bunch of them are going off at the same time.
changedCrashing OutThe current theory is that the crash is connected to a different bug where status effect particles were occasionally appearing with corrupted values, making them 3000 times the size they are supposed to be. This began happening when we updated to Unity 6, and we’re not really sure why…
changedCrashing OutThis solved the problem visually, but since the insane numbers are still being set, I suspect that certain cards run into a crash when trying to process them.

Mycopunk changes

changedAll of our terrain code runs in compute shaders on the GPU, which makes it go really really fast (yes, the levels still take a while to generate - I’ll be optimizing load times as we go AND the 1.8.2 patch today should improve loading times a bit!)
changedTerrain is split into layers. Every layer runs a function for each voxel (of which there are 21,233,664) that returns that voxel’s distance to the nearest surface. Say we want to plop a big ball into the center of the level - we just calculate:
changedAs a bonus, here’s a weird terrain layer I accidentally made using voronoi noise.
addedWe’ve been dealing with a fun new crash that seems to be caused by particle systems reading from mesh data. These sorts of crashes are always fun because they only happen on a few computers, and NONE OF THEM ARE OURS! :D We added a debug option that seems to be mostly working as a temporary fix but I’m working on a long-term solution to replace mesh data in particle systems, which should also help performance when a bunch of them are going off at the same time.
changedThe current theory is that the crash is connected to a different bug where status effect particles were occasionally appearing with corrupted values, making them 3000 times the size they are supposed to be. This began happening when we updated to Unity 6, and we’re not really sure why…

In the past we’ve mostly been secretive about updates until they launch, but like what’s the point of that? So we’re going to try being more open about what we’re working on with weekly (I hope) devlogs. Or maybe we’ll do two of these and then forget to post any more…

Proc Gen

Let’s start with something that didn’t happen this week, because I’m excited to talk about proc gen. Our procedural levels are generated using a grid of voxels (sorta like Minecraft). Then we use a cool algorithm called marching cubes to turn those voxels into a smooth surface. If you’re interested in marching cubes, there are a lot of cool youtube videos on the topic, but basically it’s a massive table of surface shapes to choose from for every possible combination of neighboring voxels.

All of our terrain code runs in compute shaders on the GPU, which makes it go really really fast (yes, the levels still take a while to generate - I’ll be optimizing load times as we go AND the 1.8.2 patch today should improve loading times a bit!)

Terrain is split into layers. Every layer runs a function for each voxel (of which there are 21,233,664) that returns that voxel’s distance to the nearest surface. Say we want to plop a big ball into the center of the level - we just calculate:

[c]ball_radius - length(current_pos - ball_center)[/c]

The resulting value is negative in the air outside the ball and positive in the ground inside the ball.

When we aren’t making balls, we can do a lot of cool things with simple math. For example, the arches you sometimes see in the Desert or Ice Floes are made by calculating the distance from each voxel to a curve like this one. I then offset the distance with some random noise and we get our rocky arches.

As a bonus, here’s a weird terrain layer I accidentally made using voronoi noise.

-Liam

Crashing Out

We’ve been dealing with a fun new crash that seems to be caused by particle systems reading from mesh data. These sorts of crashes are always fun because they only happen on a few computers, and NONE OF THEM ARE OURS! :D We added a debug option that seems to be mostly working as a temporary fix but I’m working on a long-term solution to replace mesh data in particle systems, which should also help performance when a bunch of them are going off at the same time.

The current theory is that the crash is connected to a different bug where status effect particles were occasionally appearing with corrupted values, making them 3000 times the size they are supposed to be. This began happening when we updated to Unity 6, and we’re not really sure why…

With the world update coming out so soon, and very few leads, so I put in a temporary fix:

if (tooBig) { Die(); }

This solved the problem visually, but since the insane numbers are still being set, I suspect that certain cards run into a crash when trying to process them.

So what’s the solution? No more meshes. Instead of reading the exact model data (slow), I reconfigured the system to use generic shapes that will fit around the models (fast). This should free up a bit of VRAM, and the game likely won’t hitch as much when you use a Globbler build that applies acid to everything on the map in a single frame.

This change comes as part of a larger goal for 1.0 to increase the performance of VFX, while also making them a little less visually overbearing on the whole. You guys like to blow stuff up, so I wanna try and help you not go blind while doing it.

-Noah

NEW ENEMY MODELS!!!!!!

Your workplace will be ruined by furniture and appliances soon (well, soon ish). Fridge, toilet, laptop, microwave, fan, etc. These cruel chaotic BEAUTIFUL machines want you dead. Kill them or they will butcher you.

Modeling and texturing was done by a old Saxon faculty who is obviously unwell but with great work ethic fortunately. (That’s me) Every enemy core looks different to fit the body type, and the new shells are carefully designed to be insanely infected. They will look a lot nicer than the old ones because of my crazy texturing technique improvement normal maps, it will bring more detail and depth to the enemy surface and fungal flesh. The models must look good because I am going to UV them one by one like why would I make it bad.

Concept art for one of the new grunt models

Just the model - wait for them magical textures

Saxon doesn't care about you but we do, enjoy!!

-Lily

Also update 1.8.2 is out now! Patch notes here.

Source

Steam News / 1 May 2026

Open original post

Changelog.gg summarizes and formats this update. How we read updates.