ExoEngine: Writing a 3D Engine in C# Before Anyone Thought That Was a Good Idea

In the summer of 2001, I was on the beta of Microsoft Visual Studio .NET — one of the first public releases of C#. I was finishing my second internship at Visual Insights in Toronto, building DARPA battlefield visualization software in Java, and I had a specific frustration I couldn't shake.

Java had no structs.

In 3D graphics, your most-used types are small fixed-size math primitives: Vector3, Matrix4, Quaternion. In C++ these live on the stack — cheap to allocate, cheap to copy, no garbage collector involvement. In Java, everything is a heap-allocated object. Every new Vector3() is a heap allocation. In a real-time renderer you're creating and discarding these millions of times per frame, which means constant GC pressure on exactly the types you need to be fastest. It was a fundamental mismatch between the language's memory model and the requirements of real-time graphics.

C# had structs — stack-allocated value types. You could define Vector3 as a struct and get the same semantics as C++: stack allocation, value copy on assignment, no heap pressure. That was the thing that made C# genuinely interesting for 3D work, not just marginally better than Java but structurally different in a way that mattered.

I came back to Ottawa for my fourth year at Carleton with a question I wanted to answer: could C# actually hold up as a language for real-time 3D graphics? Everyone in my fourth-year computer graphics course wrote their engine in C++. I wrote mine in C#.

Why This Was a Genuine Question#

This was late 2001. C# 1.0 had just shipped. The conventional wisdom was that managed languages — garbage collected, runtime-checked, abstracted away from the metal — were categorically unsuitable for performance-sensitive work like real-time graphics. You wrote engines in C++. That was the rule.

My argument was that the rule rested on a false assumption: that the CPU was doing the heavy lifting. By 2001 that was no longer true. The GPU handled rendering — rasterization, texture sampling, shading. What ran on the CPU was coordination: scene graph traversal, visibility determination, state management, game logic. For that work, C# was more than fast enough. And with structs solving the math primitive problem, the last serious performance objection was gone.

I had also spent two summers working in Java at Visual Insights. Java was managed and garbage collected, and it had served well enough for a serious real-time 3D application used by US military commanders. The performance ceiling for managed languages was higher than the C++ community acknowledged.

By the end of the project I had written roughly 600KB of C# code. My conclusion, published on C# Corner and Code Project in July 2002, was that C# was a surprisingly capable language for real-time graphics — and possibly a genuine replacement for C++ even in demanding real-time work.

That prediction was borne out. Unity, which launched in 2005 and became the dominant game engine for independent and mid-size studios, was built on C#. The reason it worked is exactly the reason I had identified: the GPU does the rendering, the CPU does the coordination, and C# is fast enough for coordination while being dramatically more productive than C++. Structs kept the math primitives efficient. The rest followed.

What ExoEngine Actually Did#

The engine — ExoEngine3D, source on GitHub — loaded levels from Worldcraft, the level editor used for Quake and Half-Life. Worldcraft outputs world geometry as sets of bounding planes defining the contours of solid objects, so the first task was converting those bounding plane sets into polygon faces. The resulting geometry was then optimized to remove hidden and redundant faces created by adjacent objects, and converted into a BSP tree — a binary space partition tree used for both collision detection and efficient visibility determination.

The rendering pipeline supported multiple shading modes:

Flat shading — simple, fast, faceted
Gouraud shading — smooth per-vertex colour interpolation
Phong shading (fake) — viewer-dependent specular highlights, used on duck sprites to make them look rounded and shiny
Reflection mapping — used on the animated pond to get a convincing water surface

The demo scene was a simple outdoor environment with a pond, ducks, and a surrounding landscape. Modest by 2001 standards, but the point was never visual complexity — it was proving the architecture worked.

The Architecture: Three Layers#

The 600KB of code was split into three distinct layers:

ExocortexNative — a small C++ support library handling the lowest-level concerns: OpenGL bindings (using Lloyd Dupont's OpenGL/C# library as a base, with modifications) and TIFF image loading. The things that genuinely needed to be close to the metal stayed in C++.

Exocortex — a reusable C# library intended to carry across projects. This contained the mathematical foundation: OpenGL-compatible matrix, vector, and quaternion classes implemented as structs, as well as a Marching Cubes implementation. It also incorporated Exocortex.DSP — a separate open source C# library I wrote as part of my undergraduate research project, providing single and double precision complex number types, complex math, and 1D, 2D, and 3D Fast Fourier Transforms. Exocortex.DSP was released on SourceForge in early 2002 and became surprisingly widely adopted, used in projects ranging from Math.NET to speech recognition systems to EEG signal processing frameworks. The library page is still live at ben3d.ca/dsp.

ExoEngine — the application-specific layer: the BSP tree, the level loader, the rendering pipeline, the entity system for animated objects like the pond and the duck sprites.

The Exocortex library layer turned out to be the most consequential part of the project — not because of ExoEngine itself, but because of what the library became afterward.

The Exocortex Library's Longer Life#

When I joined Frantic Films in Winnipeg after graduation, I brought the Exocortex library with me. It became the shared foundation on which three separate commercial products were built:

Deadline — a render farm management system that became an industry standard in VFX and animation, later acquired by Amazon/AWS
Krakatoa — a particle rendering system capable of rendering hundreds of millions of particles, used by major film and VFX studios
Flood — a fluid simulator for production VFX

All three were originaly C# .NET applications, all three shared the Exocortex math and infrastructure library, and all three shipped to professional users in the film and VFX industry. The library became Frantic Films' property in the process.

After I left Frantic Films in early 2005, I founded a company called Exocortex Technologies — named after the same concept, the idea of software as an extension of human cognition — but built independently on a new codebase. The original Exocortex library stayed with Frantic Films and its successors.

The Cognitive Science Student Disclaimer#

I wrote in the original article: "please remember that I am only a student (and a cognitive science/neuroscience student at that) and not John Carmack thus don't get your expectations too high."

My degree at Carleton was officially in cognitive science and neuroscience — not computer science. I had taken computer science courses, but my formal training was in how minds work rather than how compilers work. I'd taught myself almost everything I knew about graphics from manuals, demo scene tutorials, and three summers of increasingly serious internships.

Choosing C# also made the project harder in a concrete way. The professor provided all students with C++ code for parsing Worldcraft level data — a non-trivial piece of work that everyone else could simply drop into their engine. Since I was writing in C#, I had to rewrite the parser from scratch. So I wasn't just proving that C# could work for 3D graphics; I was doing more total work to do it.

The John Carmack reference was genuine humility. Carmack was the gold standard — the id Software engineer who had defined real-time 3D on the PC with Doom, Quake, and their successors, and who had published and open-sourced much of that work. Writing a BSP-based engine in 2001 meant working in the shadow of what he'd done.

But the disclaimer also contained something I believed then and still believe: you don't need formal credentials to do serious technical work. What you need is curiosity, persistence, and the willingness to go deep.

Source code and screenshots: github.com/bhouston/ExoEngine3D

Original 2002 article: C# Corner · Code Project

This post is part of a series on my early career in computer graphics. Previous posts: High School · University Co-ops