Cornucopia Raw Dev Logs

Cornucopia Raw Dev Log #2: The Beach is Now Part of Your Farm Area

So I'm back for the second dev log! The first one on the environmental vegetation optimizations did surprisingly well. I'm very happy about that :)

This one's got a lot of stuff in it. The big gameplay thing is you can now place your refining fixtures (furnaces, saws, sprinklers, tumblers, etc) in the new oceanic area connected to the farm. I was originally not going to allow it because the ocean zone is just so large and I thought it was beyond the scope of having such a huge area with all placeable terrain.

But I decided to do it anyways due to breakthroughs with performance, and figuring out the game can handle more than I thought. Originally this area was planned by the modeler and me as being purely decorative, and we only hoped that maybe somehow it could all be placeable. Happy to see that we pulled it off!

Making the grid system so much larger, while still compatible with old save files from early access players, was a lot of careful coding. I also built an entirely new tool for painting the terrain, marking off the tiles where you can't place stuff because there's environmental things in the way. Rocks, flowers, cliffs, water, that kind of thing. A lot of work, but it's done now.

The New Background

The modeler sent over the finalized version of the new farm zone background a little while ago, and it's pretty sweet. The old background was basically just a flat image back there. This new one has a bunch of hand-painted layers stacked at different depths. Distant snow-capped mountains way in the back, green mountains with cliff faces in front of those, an oak treeline, and then a dense pine forest up in the foreground. Everything is pixel art and hand-painted by him. There's like 5 or 6 depth bands in total. The farthest mountains are this pale minty color because they're supposed to be so far away. You can kind of see little dog and face shapes in the cliff rocks if you look for them.

Getting it to work properly with the camera was a bit challenging honestly, because the perspective shifts around a lot as you zoom in and out. My first attempt was a calibration tool where I'd dial in exactly where the background should sit at every zoom level, but I ended up scrapping that whole approach. What I did instead was just angle the tree line downward and extend it way further. So when you're zoomed more top-down, you're mostly seeing trees. When the camera tilts more paper mario style side-on, the mountain line shows through behind them. Way simpler than trying to reposition everything per zoom level.

Waterfall Blending

I also improved the blending where the waterfall meets the river at the top, which was looking a bit rough before. It used to have kind of a hard seam right where the waterfall mesh started and the flat river water ended. Now there's a custom material on the waterfall that fades into the river surface instead.

Rebuilding the Placement Grid

Okay to back up a bit, the game already lets you place refining fixtures out in the open on your farm, anywhere you want. Furnaces, saws, sprinklers, scarecrows, tumblers. Anywhere there's a flat tile or a slope that isn't extreme, you can place stuff down. (That includes planting fruit trees, berry bushes and other stuff too.)

With the new ocean zone connecting to the farm, I wanted the same thing to be true down there. Same rules, just in a much bigger area. Drop your furnace on the beach if you want, same as up top.

The problem is the old placement system wasn't really built for an area this big with this much decoration on it. And it wasn't really built for handling old save files from early access players either, since they already have their whole farm laid out on the old terrain shape, with soil values and vegetable plant positions saved. So I had to redo the whole thing from scratch to handle the changes as well as old save compatibility. (btw, doing development with having to worry about saving/loading compatibility and translations makes everything harder, so I recommend new devs think about that.)

I also had to build a new tool in the editor for marking off the spots where the player shouldn't be able to place stuff. Basically it's like a painter tool where I paint red tiles directly on the terrain. All the decorative rocks, flowerbeds, stonework, water, cliff edges, stuff like that gets painted red on a per-tile basis as the game is set up. I can paint from top-down view for big areas fast, or switch to in-game perspective view for the fiddly spots where I need to nudge tiles around individual props. I switch back and forth a lot.

The tool itself is done now, and I've also finished hand-painting all the blocked spots across the whole new terrain, which was honestly something I procrastinated a bit on.

Another thing I had to fix was the actual blue grid line visual itself due to the new varied terrain. When you're in placement mode, the game draws these blue grid lines on the ground so you can see which tiles are available and which are occupied (in red). Technically it works by projecting a decal downward and reading the depth buffer to figure out where the ground is. On the old mostly flat terrain that worked fine. But on the new terrain with all the cliffs and waterfalls, the grid was drawing on everything including cliff faces. Not exactly professional.

The fix was a few things. The original shader was asking the terrain what direction it was facing, and using that to decide where to draw the grid. The problem was the terrain shaders were kind of lying about it. They were writing "I'm flat" into the G-Buffer even on cliff faces, because of some weirdness with how terrain normals work in Unity. So no matter how much I tightened the angle cutoff, the grid still showed up on the cliffs, because the number it was checking against was garbage.

What I ended up doing instead was making the shader figure out the actual slope on its own, by looking at how the world position changes from pixel to pixel across the screen (ddx and ddy derivatives, for any shader people reading this). That gives you the real slope of the ground at every pixel, no matter what the terrain shader claims. Then anything steeper than about 30 degrees from horizontal gets cut off. I also shrunk the height of the projector box so it doesn't reach as far down vertically. There's a smooth fade near the cutoff angle now so the grid doesn't hard-clip at the edge.

Warp Zones

I also set up a bunch of warp zones connecting the new terrain to the other zones around it. Bottom cave up to the top cave, farm down to the beach, into town, the junction area. Makes the whole map feel way more connected instead of a bunch of disconnected zones. Sparkly indicators included so you know where they are.

The funny part is how I was actually measuring where the player should spawn on the other side of each warp. Every warp has to drop you into the destination zone at a specific spot, facing the right way, and not clipping into a wall or a rock. So I needed like a reference body roughly the size of the player to stick in the scene while I was lining it all up.

I ended up just using Rufus the farmer's sprite for this, which is kind of a weird technique but it worked pretty well! Literally just placing Rufus at the landing spot in each zone so I could eyeball whether the size and position and angle all felt right. He's the perfect size for it.

Farm Animal Pathfinding

One more thing I wanted to mention was the farm animal pathfinding. All your farm animals, like your cows, your chickens, your horses, whatever you've got following you around, they use A* pathfinding to keep up with you. Basically a grid layer that sits underneath the whole terrain and says what spots are walkable and what spots aren't. Each animal figures out a path from wherever it's standing over to wherever you are on its own.

The problem is the old pathfinding graph only covered the old farm area. So when I extended the world down into the ocean zone, the animals would follow you right to the edge of the farm and then just stop. Sit there and watch you walk off into the ocean without them, which was kind of sad.

So I rescanned the pathfinding graph across the whole new terrain. Farm, junction, ocean zone, all of it. Now the animals can trail you all the way down to the beach without getting stuck at an invisible fence somewhere.

The other thing was that big decorative props like the cliff rocks, thick clusters of trees and stuff like that, they don't automatically block the pathfinding on their own. Each of those big props gets a "Pet Obstacle for A*" marker on it now, which carves out a non-walkable zone around the prop when the pathfinding graph bakes.

Now the animals route around all that stuff the way they should, and they can follow you anywhere in the new terrain without getting stuck. Much happier about how they behave now :)

-david

Full devlog with all screenshots: https://cornucopiavideogame.com/devlog/junction-grid-blocker/

Walking on my treadmill while writing this. I have ADHD so if exercise isn't the first thing I do in the morning, it's just not likely to happen, lol. I bought a cheap treadmill off Amazon and set up the hydraulic table I already use for my mouse pad when I'm sitting, raised it up to about belly button height in front of my PC with my mouse and keyboard on it. Monitors tilt up a bit so I can see them while standing. Something in the house is better for me than the gym or yoga which I tend to stop going to in a couple months after signing up, as is generally the case. I was walking 2-3 hours per day for about a week before flying to Boston to show the game at PAX East, but now I'm back at it after a couple days recovery.

I showed a little bit of the new farm terrain in the last post. But here's an interesting problem and solutions to the new terrain I've never mentioned before.

GPU Instancing: How I Got 2,583 Plants Down to 3 Draw Calls

So my 3D modeler first started sending me terrain model tests back in November 2025 or earlier. He was actually a fan of the game originally. Redesigned the Cornucopia logo on his own almost two years ago just because he wanted to, after reaching out to me. Over time he's become pretty much the only active person working alongside me on the game. He has been working as a contractor for about the past 2 years on the game, and is now the most important person helping on the game. (And as of right now, the only other person other than me.) A player who loved what I was building and ended up helping build it. That kind of thing doesn't happen often.

In March 2026 just prior to PAX East he sent over a complete farm terrain redevelopment after we planned and brainstormed it for many months. I wanted to implement it prior to PAX, but it just wasn't possible. The terrain is WAY WAY more detailed and interesting than before and includes a new connected oceanic zone. And every day he keeps sending more fixes and improvements as we work together. Flowers, bushes, ground cover, coral for the oceanic zones, little plants growing between rocks. Today he sent background parallax layers with pine trees and oak at different depths behind the farm. The game has temperate farmland, oceanic zones, cave environments, rocky areas, the town. All of these areas are getting filled in with environmental details that give them actual personality. Stuff that was missing before.

He kept asking me in the past, "How much can I add?", and really kept trying to push the scope larger and more detailed than I thought was possible for performance.

And I kept looking at the designs thinking about the GPU, FPS, and performance on Switch/consoles.

The Problem

Every separate object in a game is a request to the graphics card. Every flower, every bush, every little ground cover plant. "Draw this." "Ok now draw this." "Now this one."

2,583++ of them.

On a decent gaming PC, fine. But we're also developing for console and we want it running well on lower end PCs, laptops, and maybe Mac in the future. Those systems care a lot about how many separate draw requests you throw at them. It's not about how many triangles are on screen, it's about how many separate things you're asking the GPU to handle at once.

And I'm looking at this beautiful scene that finally has the environmental detail the game was always missing, and I'm thinking... do I have to tell him to cut it back? Because the game can't handle it?

I really didn't want to.

The Breakthrough

My first attempt was standard GPU instancing, where you tell the GPU "here's one mesh, draw it 500 times at different positions." Efficient. But it requires identical geometry and these plants are all unique shapes from Blender. Different flowers, different bushes, different sizes. Didn't compress enough.

Then I realized something.

These plants are all stuff the player can't interact with. You can't pick them up, walk into them, nothing. They're purely visual. And they share the same texture atlas.

This is actually the first time we've ever added environmental greenery that's un-interactable. Pretty much everything in the game, you can interact with. So that's the reason we can instance these with the GPU. But anything that's collidable or you can interact with, like the regular props or regular weeds or trees, those need their own separate game objects with their own scripts and information on them. And I don't really think I can safely instance those because of the amount of unique information and interactability stored on each one.

If nobody interacts with them and they share the same texture... why are they separate objects? What if I just take all the nearby ones and literally merge their meshes into one big mesh? Unique shapes don't matter once you bake all the vertices into world space. The GPU just sees one object. (Individually animating each of them with wind was another concern, but I get into that later in this post.)

That was the moment everything changed.

The Process

The first problem was trees. Your character walks around tree trunks and bumps into them, so trunks need collision. If I merged the trunks into one big mesh you'd just clip right through everything. But the leafy canopy on top? Nobody needs to walk up there. So canopies can be combined, trunks can't. Same thing for cosmetic vegetation and bushes, don't need collisions for them.

I needed to separate every tree in the scene into its two parts before doing anything else. Wrote a tool in Unity that does it in one click. Canopy meshes get grouped for baking, trunk meshes stay individual but get marked static so Unity batches them behind the scenes.

Then I made the actual vegetation baker. This is the tool that does the combining. You select a parent object with all the plants underneath it, click one button, and it handles everything. It splits the world into a grid where each cell is 20 units across. I chose that size specifically because it's roughly one screen width for the isometric camera. That way the GPU can skip entire cells that are offscreen instead of trying to process one giant mesh that covers the whole map. Within each cell, it merges plant meshes together up to 60,000 vertices. 16-bit index format where possible because it's faster on less powerful hardware.

I also wrote a one-click optimizer on top of that. Turns off shadow casting on all vegetation (shadows are expensive on weaker hardware and honestly you don't notice them on small plants), marks everything for static batching, and gives me a report of the estimated draw calls so I can see exactly where we're at.

We ran actual density tests too. I imported a test file literally called GrassDensityCapacityTest to see how much we could push before the frame rate died. Turns out the system handles way more than we expected. That was a really good moment. The 3D modeler has also been sending me all kinds of tests throughout the months of this farm terrain remake. Like how far the player can jump, how high they jump, platforming elements, sand wetness tests, all kinds of stuff. It's actually hard to remember it all, but it's been a lot. And that's really helped him with the process of how to model all this stuff in Blender. It's been a lot. It's hard to remember it all.

The Wind

This is the part I'm most happy about and honestly surprised it works properly with the GPU instancing thanks to a custom shader and script.

When every plant was its own object, each one swayed in the wind on its own. Easy. But once you combine thousands of them into a few big meshes, they're all the same object now. How do you make individual plants inside one combined mesh still move independently?

Before combining, I go through each plant and "paint" its vertices with a sway weight. The bottom of the plant, the part in the ground, gets painted with 0. That means don't move, you're anchored. The top gets painted with 1. Full sway. Everything in between is a smooth gradient. So the stems barely move, the middle moves a bit, and the tips of the leaves and petals move the most. Just like a real plant in the wind.

Then I wrote a shader that reads those painted values and pushes the vertices around. I use two overlapping sine waves at slightly different frequencies. That layering is what makes it feel gusty and organic instead of everything going perfectly back and forth in sync. Some plants lean left while the one right next to it leans right. Some are mid-sway while others are catching up.

The shader I wrote ended up handling all of these details automatically once it's all baked and the wind settings are on. And you can actually set the wind values for each batch, so the behavior of the tree foliage animates differently than the separately batched random vegetation like flowers and weeds and decorative stuff.

And I thought carefully about what should and shouldn't sway. Coral sitting on rocks? Stays still. Ground cover flat against terrain? Static. I made separate NoWind material variants for those. Small detail but when everything sways including stuff that shouldn't, the whole scene looks wrong.

The tree canopies have a different feel from ground plants too. More of a slow, subtle breathing kind of movement. Softer than the obvious swaying of flowers and bushes. Different vegetation, different personality.

For any devs reading: the shader handles all three rendering modes (baked combined mesh, standalone tree with wind component, plain mesh) without any if/else branching. GPUs are slow at branching, so I use step() and lerp() to blend between modes with pure math. Same code path for everything.

The Result

I ran the baker and watched the draw call counter go from 2,583 to 3.

This was pretty surprising, and I was very happy seeing this work properly.

99% reduction. The farm used to be just the interactive props sitting on kind of a bare surface. Now there are flowers growing between every rock, bushes along every path, ground cover everywhere. And when you're walking through it all and everything is swaying around you in the wind, each plant moving a little differently... that's a handful of draw calls doing the work of thousands. You'd never know. All of the existing stuff that you can interact with works the same. It's just all of this decorative environmental stuff that really brings the world to life is what's GPU instanced.

Haven't tested on console yet specifically. Numbers look really promising though.

And the most important thing: my modeler can add as much environmental vegetation as he wants now. I don't have to be the person saying "cut it back" when it looks this good. A fan of the game who ended up being the person making it beautiful, and now there's not much holding him back in terms of creating this terrain. That's a good feeling.

I should note that there's a lot of things specific to the game that are constraints due to the non-rotating nature of the camera view. It's sort of a Paper Mario style where you can zoom in and out but it's fixed to one direction. We don't want any of the design to have higher elements in the foreground that block the camera view when you're in the lower angle perspective. So that was also a key design decision when remaking the terrain, and it took a little while to totally convey it all to the modeler over the months. Trial and error of tests.

Technical Deep Dive (For Devs Who Want To Do This)

If you want to implement something similar, here's how the key pieces actually work. Skip this if you're not into code.

The Baking Pipeline

The Vegetation Baker is a Unity EditorWindow. Takes a parent GameObject, collects every child that has a MeshFilter, and runs through three stages.

First, wind color baking. For each unique shared mesh, it clones the mesh and writes vertex colors. Finds the local Y bounds of the plant (min to max), normalizes every vertex Y into a 0-to-1 range. That goes into the red channel. Green channel gets set to 0 as a "this has been baked" marker. Unbaked meshes have G=1 (the default white), so the shader can tell the difference. Caches these baked meshes so identical plants reuse the same version instead of cloning every time.

Second, spatial chunking. Groups all the CombineInstance data by grid cell. Each cell is CELL_SIZE units (I use 20, matching the isometric camera viewport width). Within each cell, builds sub-chunks that respect a max vertex count of 60,000. Grid coordinates are just floor(position / cellSize). Simple but effective.

Third, combining. For each chunk, creates a new Mesh, picks index format based on vertex count (16-bit when under 65K, 32-bit otherwise), calls Unity's CombineMeshes() with mergeSubMeshes and useMatrices both true so the world-space transforms get baked in. Recalculates bounds. Saves everything as a VegetationData ScriptableObject with the combined meshes stored as sub-assets.

The Wind Shader

Surface shader with a custom vertex function. The branchless mode detection looks like this:

float isBaked = step(v.color.g, 0.49); // 1 if baked vertex colors float hasMeshWind = step(0.001, windData.x); // 1 if MeshWind component active

These two values drive everything through nested lerps. For baked meshes, the sway comes from vertex color R (squared for a nice ease-in curve at the base). For MeshWind meshes, from world Y within the sway range. For plain meshes, from local vertex Y.

The displacement uses world position for phase so nearby plants share similar timing but aren't identical:

float phase = (worldPos.x + worldPos.z + _Time.y * speed) * freq; float sinVal = sin(phase) + sin(phase * 1.3 + _Time.y * 0.7) * 0.3;

Second sine at 1.3x frequency with a time offset creates the gusty feel. Displacement goes into X and a smaller amount into Z for diagonal sway. Transforms back to object space before applying.

At Runtime

The VegetationRenderer just calls Graphics.DrawMesh() for each combined mesh every frame. No GameObjects, no transforms, just raw draw calls. The instancing fallback path is still there using DrawMeshInstanced() with manual frustum culling, but the combined path is what we actually use.

What I'd Do Differently

If I started fresh, I'd probably look into compute shader indirect instancing. More flexibility for LOD and dynamic spawning. But for a project where the vegetation is placed by a modeler and doesn't change at runtime, the baking approach is simpler and it works really well.

There's a reason I needed all of this working before anything else. Can the new area connect to the farm without a loading screen? I didn't think it was possible before this. The modeler was really insistent that we have the lower new area seamlessly connected to the farm, and I was thinking the whole time that it's probably not gonna be a good idea because it's gonna lower the FPS too much and we should just have a loading screen in between and have it as a separate area. But I haven't tested incredibly thoroughly on low end hardware, so I can't say definitively if we're still gonna run into any issues. But right now it looks amazing. And his dream of having so many details did appear to come true due to how I've optimized all this stuff, and really becoming aware of GPU instancing and writing these custom scripts and shaders. So the future of these terrain remakes is looking really exciting!

-david

Cornucopia Terrain Development - In the Thick of Things