120,000 lines of C++ ray tracer.
Ported to 15,000 lines of EPL.
Same quality. 8x less code. A 20-year-old production engine rewritten in our own language with spatial math built into the compiler.
Rendered by the EPL port of Aurora — the same engine, one-eighth the code.
The original: Aurora (2004-2018)
Twenty years ago, we built Aurora — a full ray tracing engine with global illumination, photon mapping, caustics, volumetric rendering, subsurface scattering, displacement mapping, depth of field, motion blur, and distributed network rendering.
It had its own shading language (ElumScript), a 3D modeler, an OpenGL viewport, and a plugin for LightWave 3D. The architecture was comparable in scope to what would later become Blender's Cycles or PBRT.
120,000 lines of C++. Windows-native. Visual Studio. Manual memory management with 37 typed allocation pools. A code generation system that templated the entire renderer in both float and double precision through macro substitution.
It worked. It rendered production-quality images. It was a serious piece of engineering.
The port: why and how
EPL is our own programming language — built from scratch over 14 years. Own compiler (JIT, x64 native), own database, own GUI framework, own network protocol. It compiles to machine code and runs at native speed.
For Aurora, we added spatial math as a first-class language feature. Vector operations, matrix transforms, ray-surface intersections, BVH traversal — all built into the language runtime, not bolted on as a library.
The question was simple: can EPL handle something this complex? The answer is in the numbers.
Where did the code go?
| C++ (2005) | EPL (2026) | |
|---|---|---|
| Lines of code | ~120,000 | ~15,000 |
| Memory management | 37 manual allocation pools | Garbage collected |
| Precision variants | Macro-generated float/double templates | Runtime-selected |
| Shading language | Custom ElumScript + bytecode VM | EPL itself (same language) |
| Build system | Visual Studio, Windows-only | epl aurora.epl — one command |
| Network rendering | Custom client/server protocol | TProtocol (built-in, encrypted) |
The 8x reduction isn't because we cut features. It's because:
- No boilerplate. C++ demanded header files, forward declarations, include guards, template instantiations, manual destructors. EPL has none of that.
- Spatial math is native. A ray-triangle intersection in C++ is 40 lines of vector operations with manual component access. In EPL it's a language-level operation.
- The shading language IS the language. Aurora's ElumScript had its own compiler, bytecode format, and VM — thousands of lines just to let artists write shaders. In EPL, shaders are just functions.
- Memory management disappears. Those 37 typed pools, the R_Table paged virtual memory, the custom string allocators — all gone. Zero memory bugs, zero leaks.
- Network rendering comes free. TProtocol is built into EPL — encrypted, multiplexed. The render farm is a few dozen lines, not a subsystem.
Same quality
Ray tracing is math — the rays don't care what language traces them. Photon mapping still produces caustics. Global illumination still bounces light. The BVH still accelerates intersection tests. The material system still evaluates operator graphs.
What changed is how much code it takes to express that math. Less code means fewer bugs, faster iteration, and a codebase that one person can understand end to end.
What this proves
Aurora isn't a product we're selling. It's proof of what EPL can do.
If a language can handle a production ray tracer — with BVH traversal, photon mapping, adaptive sampling, volumetric rendering, and distributed computation — it can handle anything. Business apps, email servers, git hosting, voice assistants, AI pipelines.
That's what we've built: not just Aurora, but an entire operating system for business, all in the same language.