We have been working on Gaea since 2015. It underwent a complete overhaul in 2020-2022 during the Pandemic so we could create a more future-friendly platform on which Gaea would run for the next decade.

Below is the first part of a series blog posts delving deeper into the technology behind Gaea. In fact, some of the lowest-level work for hardware acceleration ended up becoming Pull Requests into these widely used libraries such as AdaptiveCpp, AMD, and more, which will help improve computing for everyone.

Each section in this article is divided into two portions:

• a standard, generally accessible version
• a technical version with details on implementations and code.

Use the Table of Contents on the right side to navigate to different sections.

Modular Infrastructure

Gaea wasn’t just built as an app — it was built as a core engine first.

At its heart is the Gaea Engine, which does all the heavy lifting: terrain generation, erosion, performance optimization, and memory handling. Then we built the Gaea interface around it — the part you see and interact with.

The two are separate but connected. That means we can upgrade the engine without changing the UI. Or improve the UI without affecting the core. They grow side by side — but never in each other’s way.

Some features, like Autosave, Groups, or the Graph, only exist in the UI to help you work faster. You won’t find them in the engine. But deep features like Erosion, Tiled Builds, and Parallelism are engine-only — powering everything behind the scenes.

This split keeps Gaea clean, powerful, and ready for the future — whether you're an artist, developer, or both. It also allows Gaea's engine to become portable when needed and work with external applications such as Houdini.

For the actual architecture and subsequent development, we follow SOLID principles — the gold standard of software architecture. The most important to us:

• SRP: Each part of Gaea does one thing, and does it well.
• OCP: Add new features without breaking old ones.

When bugs show up, we don’t just slap on a quick fix. We look deeper — find the real cause — and improve the system. That way, the same problem doesn’t come back later.

It’s this kind of disciplined engineering that keeps Gaea powerful, stable, and future-proof — even as it grows in complexity.

Technical Details

Gaea was designed as an SDK first. At its core is the Gaea Engine — a standalone processing system with a strict contract-based interface. Each node in the system is a self-contained processor, designed to plug into a larger pipeline. The entire Gaea UI is built as a layer on top of this SDK.

This separation of concerns creates a clear architectural boundary:

• Engine: Handles node execution, memory management, parallelism (SPMD), tiling, and build orchestration.
• Interface: Manages the graph, UI constructs such as autosave, presets, groups, and interaction logic.

Because of this decoupling, the UI can evolve independently — add features like grouping or workflow enhancements — without impacting the core. Likewise, engine improvements (e.g. faster erosion or new compute strategies) don’t disrupt the interface layer.

Even core features like Autosave, Grouping, or the Graph structure itself are UI-level constructs, not part of the Engine. In contrast, engine-level features like Erosion, Tiled Builds, and Massive Parallelism never touch the UI, except to expose inputs or display results.

This design has enabled Gaea to remain modular, extensible, and maintainable as it scales. It also allows Gaea to become a programmable component for complex workflows or 3rd party interfaces. Utilizing Gaea in Houdini via the Gaea2Houdini plugin is a perfect example of this.

Gaea architecture relies on adherence to SOLID principles, with particular emphasis on SRP (Single Responsibility Principle) and OCP (Open/Closed Principle).

Every class, module, and component in Gaea has a clearly defined purpose. This SRP-focused structure avoids bloated god-objects or procedural sprawl. Combined with OCP, it allows us to extend behavior without modifying existing code, keeping the codebase flexible yet robust.

Our design isn't a patchwork of features — it's a deeply interconnected system where components are composable and predictable. When functionality evolves, we don't bolt things on. Instead, we refactor holistically, preserving architectural integrity.

We treat errors the same way. Rather than applying bandaid fixes, we perform root-cause analysis and structural corrections. This discipline results in fewer regressions and a more resilient system overall.

The result is a high-performance, scalable codebase that remains lightweight, testable, and easier to evolve.

SPMD: The Silver Bullet

Imagine an erosion process where you must move every grain of sand, one by one. There are two billion grains. Even if you're fast — one grain per millisecond — you’re still looking at a 16-minute wait.

Parallel processing helps — multiple people moving sand at the same time. That cuts it down to 2 minutes. But Gaea went further.

We gave each grain its own set of instructions — like tiny autonomous workers. These grains don’t wait to be told what to do. They think for themselves. They know where to go, how to erode, where to deposit, and when to stop.

This approach is called SPMD — Single Program, Multiple Data. We built this into Gaea using .NET. This is something rarely done at this scale.

Now, all grains move together, in sync, performing erosion, deposition, and other terrain magic in one single pass. What once took minutes, now happens in seconds.

Technical Details

Traditional .NET isn’t built for SPMD-style workloads — the kind where billions of independent data elements run the same logic in parallel. But that’s exactly what Gaea needed for erosion: each "grain" of terrain executes erosion logic independently, including downcutting, deposition, sediment transfer, and more.

Gaea employs massive parallelism. We built a custom SPMD execution layer on top of .NET’s task and threading infrastructure. Instead of typical thread-per-region processing, we dispatch the same program logic across a vast dataset, with each worker (or core) executing a single instruction stream on its assigned data slice. Internally, we maintain data locality, branch-safe execution, and lock-free scheduling, allowing us to scale cleanly across available CPU cores.

Below the SPMD level, in each parallel computation a second level parallelism is employed: SIMD, or Single Instruction Multiple Data. Just like the SPMD program executes on a massive, parallel level, the smaller computations within the program executes on a parallel level as well.

This massive parallelism isn't just parallel processing but data-level parallelism implemented in managed code. The payoff is that we process billions of data points in under a second on modern CPUs, even with complex erosion logic.

Gaea’s terrain engine now leverages SPMD-like performance without relying on unsafe or platform-specific native code — a rare and powerful achievement in .NET.

Spawning Pool: Memory Management

Most software lets the system handle memory. Allocating when needed, and cleaning up when done. But that can be slow and unpredictable, especially when handling billions of terrain data points.

Gaea takes a different route. We built our own memory manager called the Spawning Pool.

Instead of throwing memory away when it's done, we mark it as “zombie memory”. Not dead, just waiting. When a new task comes along, we reuse that memory instantly. No waiting, no reallocation.

It’s like having a warehouse where boxes are never thrown out — just cleaned, refilled, and sent back into the world. This makes Gaea blazingly fast, especially in complex terrain operations.

The result? Less overhead, more speed, and complete control — far beyond what the default system can do.

Technical Details

Gaea doesn't rely on the default .NET garbage collector. Instead, we built a custom memory management layer tailored for high-performance terrain workloads.

We call it the SpawningPool: a system that rents, tracks, and recycles memory blocks far more efficiently than the standard GC or even ArrayPool<T>. Instead of freeing memory immediately, we often mark it as "zombie memory" which is dormant, but reusable. These blocks can be quickly reallocated for future tasks without reallocation. The zombie blocks of memory are available to the Operating System if it suddenly needs that memory for some other task elsewhere. This flexibility ensures Gaea does not hog memory unnecessarily.

This system avoids the unpredictable pauses of GC, eliminates fragmentation issues, and ensures consistent memory locality, which is crucial for data-intensive operations like erosion, masking, and simulation.

In benchmarks, our SpawningPool consistently outperforms all built-in .NET memory pooling options — including custom allocators — both in throughput and stability under pressure.

Benchmarks

CPU vs. GPU

GPUs are fast — but only when used wisely.

It’s a common belief that using the GPU always means better performance. But that’s not the full picture. Sending data to the GPU and getting it back takes time. It’s like sending a giant truck to deliver a tiny parcel — overkill, and slow to start moving.

Gaea evaluates every algorithm and decides: Is the GPU worth it?
If the CPU is still faster — we stay on the CPU.

In fact, many operations are always faster on the CPU, so we don’t even bother writing GPU versions for them. Our terrain engine is built to be smart — sometimes using simple heuristics to choose the fastest path, whether that’s a CPU core or a GPU thread.

Only the big stuff, like full erosion simulations and fluid-like processes, go to the GPU — and only when it’s actually beneficial.

Thanks to our SPMD execution layer and SpawningPool memory system, Gaea squeezes top-tier performance out of modern CPUs. So even without a high-end GPU, Gaea remains blazingly fast, responsive, and stable.

Technical Details

GPUs excel at throughput: like trucks hauling massive data payloads. But they suffer from high latency. In contrast, CPUs are motorcycles: lower throughput, but extremely low latency and highly responsive.

Transferring data to and from the GPU is non-trivial. It introduces latency and stalls execution, especially for short-lived or frequently updated data. This makes the GPU a poor fit for many terrain operations that benefit more from quick turnarounds than brute force.

Gaea implements a hybrid model:

• Tasks like Erosion and Hydraulic Simulation — computationally dense, long-lived, and GPU-optimized — are offloaded.
• Operations like blending, transforms, masks, and layering are kept on CPU, where they run faster due to immediate memory access and fast branching.

Many operations don’t even have GPU equivalents because they’re inherently better on CPU. We use simple heuristics in some systems (like PE and Lighting) to decide on-the-fly what backend to use — enabling intelligent, adaptive execution.

With SPMD and SpawningPool, we optimize CPU workloads to the point that, in many cases, well-designed CPU code matches or outperforms naïve GPU code — without the GPU tax.

This approach keeps Gaea performant on all machines, minimizes bugs from backend switching, and avoids unnecessary GPU dependency — all while maximizing real-world speed where it matters.

Next Part

In the second part, we will talk about the second set of technical developments such as "pop-free" LODs using optimized mesh generation, LightX - the most advanced heightfield renderer, and how their byproducts can help you create more powerful VFX visuals.