When I was around thirteen or fourteen, my father took me inside a power plant.
I remember looking at the turbine and wanting to talk to it.
I had grown up fascinated by science fiction, so what I imagined was probably closer to HAL 9000 than anything I could properly articulate:
Hey turbine, how are you feeling today? Why is your hot reheat not doing well?
I obviously knew nothing about digital twins, semantic models, telemetry architectures or knowledge graphs.
But the question stayed with me:
What would a computer actually need to know about something before you could have a meaningful conversation with it?
I've spent a surprising amount of my professional life circling that question.
I thought the problem was 3D
NthDimension began around 2008.
I was working in industrial automation, including fire-detection systems using pre-addressed sensor cables in highway tunnels and power plants.
Industrial visualization was predominantly 2D. At the same time, I had always been fascinated by video games and science-fiction interfaces.
I wanted something different.
Why couldn't I walk through a three-dimensional representation of an industrial installation and interact with the equipment directly?
So I started building what became NthDimension.
For a while I thought I was building a 3D engine.
As the renderer improved, and as I worked on more industrial systems, I discovered that rendering wasn't really the difficult problem.
I could render a turbine.
I could attach live measurements to it.
I could make it look impressive.
But a beautiful 3D model of a turbine is still not a turbine.
Without the substance behind the visualization, I had made a toy.
Telemetry isn't understanding
One of the defining influences on how I came to think about this was my work with Fred D. Lang and Exergetic Systems.
Fred developed the Input/Loss Method for power-plant performance analysis and EX-FOSS, a steam-generator simulation system.
Exergetic Systems taught me power-plant thermodynamics.
For more than a decade, part of my work involved keeping alive and eventually modernizing software around their engineering systems.
One particularly memorable component was an old VB6 application we called the Blue Panel.
It sat between different worlds: live plant telemetry, Microsoft Excel and Exergetic's engineering executables.
Keeping that ecosystem working gave me an education that went considerably beyond software engineering.
It taught me that:
Telemetry isn't understanding.
A temperature measurement is an observation.
Ten thousand measurements are ten thousand observations.
They don't automatically explain why a plant is behaving the way it is.
For that, measurements need context. They need relationships and history. Often they need a model capable of explaining what those observations mean.
At roughly the same time, NthDimension was teaching me the inverse lesson:
A 3D model without operational meaning was a toy. Telemetry without a model was just data.
Somewhere between those two problems was what I actually wanted to build.
What makes a turbine a turbine?
Return to my teenage question:
Why is your hot reheat not doing well?
Today we could connect a language model to a process historian and make something that appears to answer that question.
But the language interface doesn't solve the underlying representation problem.
The system first needs to know which turbine we're discussing.
It needs to know what the turbine contains and what it is connected to.
It needs measurements, units and quality.
It needs current state and history.
It needs models capable of interpreting those observations.
And eventually it needs to distinguish between what was observed, what was calculated, what was inferred, and what simply isn't known.
That is much closer to what interests me about digital twins than placing telemetry beside a 3D model.
The visualization can be extremely useful.
But the visualization isn't the twin.
So what exactly is NthDimension?
This is where I've always had difficulty putting NthDimension into a conventional product category.
It contains a substantial real-time renderer and editor, geometry and modeling systems, animation, terrain, weather, procedural generation, audio and simulation infrastructure.
Calling it a game engine therefore isn't wrong.
It's incomplete.
A significant part of its architecture also comes from industrial automation, telemetry, process historians, power-generation systems and operational software.
Calling it a digital-twin platform isn't entirely wrong either.
That's incomplete too.
The description I've settled on is:
NthDimension is an engine for building computational worlds whose entities can have identity, semantics, state, relationships, behavior, history and physical representation.
Rendering is one consumer of that world.
Simulation is another.
An editor is another.
An industrial application can be another.
A game can be another.
The important distinction is that none of those consumers should have to become the sole definition of what an entity is.
Which one is the car?
Take a car inside a sufficiently complicated software system.
The renderer sees meshes, materials and GPU resources.
Physics sees bodies and constraints.
The editor sees an entity and components.
The Asset Library sees an asset with identity, revisions and dependencies.
Animation may see a skeleton and tracks.
Persistence sees serialized state.
A telemetry system may see signals.
A semantic graph sees identities and relationships.
If all these representations evolve independently, eventually several subsystems believe they own the truth.
So which one is actually the car?
The architectural principle I've been converging toward in NthDimension is:
The authoritative semantic/causal definition is the asset; geometry and runtime resources are compiled projections of it.
I don't mean “compiled” only as a metaphor.
The Asset Library work is still an active programme, so I don't claim that this authority model is complete across every NthDimension domain today. The direction is explicit: assets have stable identity, with revisions, dependencies, lineage and provenance represented as first-class state. Subsystems can then resolve the specialized representation they need from that authority rather than quietly turning their own runtime object into a competing definition of the asset.
Some derived representations are expensive enough that they need to be cached. The architectural goal is for those caches and runtime resources to remain traceable to the state that produced them, so changes can drive explicit invalidation or reconstruction instead of allowing representations to drift independently.
The renderer therefore owns the problem of rendering a car efficiently. It can reorganize geometry, build GPU resources, partition meshes or select an LOD without acquiring the authority to redefine what the car is.
That separation sounds simple when written down. Maintaining it once persistence, editing, procedural generation, simulation and live data all begin modifying the world is considerably less simple.
I don't present this as the One True Architecture.
It's a hypothesis.
And ambitious abstractions have a nasty habit of working beautifully until sufficiently complicated software encounters them.
I've learned that lesson repeatedly.
I've rewritten it a lot
Depending on where I draw the boundaries, I count thirteen substantial revisions of NthDimension since around 2008.
There wasn't an eighteen-year master plan.
I kept hitting walls.
Rotations expose one problem.
Editing becomes more sophisticated.
Then proper undo/redo arrives and assumptions that worked perfectly well for the previous editor suddenly become liabilities.
Persistence exposes another.
Animation another.
Large worlds another.
Procedural geometry another.
Every time the system became capable of doing something substantially new, it exposed assumptions made by an earlier version.
Eventually you have a choice.
Defend the abstraction because you wrote it, or replace it because reality has demonstrated that it is wrong.
I prefer replacing it.
Most of those early versions are gone as complete source trees. Crashed hard drives and the normal attrition of many years of development took care of much of that history. But not everything disappeared.
Some earlier generations survive as videos on an old YouTube channel I no longer maintain, so there is still a visual record of parts of NthDimension's evolution.
Revision 12 survived much more substantially. I spent about two years as technical project manager at Rafa Software developing MySoci, an experimental 3D social network and virtual meeting environment powered by NthDimension. We eventually published the prototype through the Microsoft Store in 2018. I later had to leave the company for personal reasons; development subsequently moved to Unity and the project was eventually abandoned.
I subsequently published that generation of NthDimension as open source. The Revision 12 source is still available on GitHub today.
So I can't show thirteen complete source snapshots arranged neatly in chronological order. But there are fossils: videos of earlier generations, an open-source revision, and a version that left my development environment and powered another company's published application.
The NthDimension I'm describing in this article is what came after all of that.
There is a real engine underneath this
I realize that “computational worlds” can very quickly become the sort of phrase that looks good on an architecture diagram while meaning almost nothing.
So here are some concrete examples of what sits underneath NthDimension today.
The large-world architecture uses double-precision world/reference-frame coordinates, hierarchical reference frames and floating-origin local rendering. The point isn't to pretend that a single floating-point coordinate retains arbitrary precision across astronomical distances. Global addressability and local numerical precision are treated as separate problems.
The configurable universe envelope currently extends to one billion light-years in radius, while local rendering operates in an appropriate nearby coordinate space.
On the rendering side, NthDimension has GPU visibility infrastructure including Hierarchical-Z occlusion, instance culling, meshlets and multi-draw-indirect paths.
The meshlet pipeline partitions indexed geometry into bounded clusters, builds packed geometry arenas and performs GPU-side rejection including frustum and normal-cone tests.
The renderer uses Cook–Torrance physically based shading with GGX, Smith masking and Schlick Fresnel, a linear HDR workflow and ACES tone mapping.
There is atmospheric Rayleigh and Mie scattering, volumetric weather, clouds, rain and lightning.
There is a B-Rep geometry/modeling system rather than only triangle-mesh editing.
There is a custom skeleton, pose and skin-weight authoring pipeline with support for up to eight bone influences per vertex.
There are terrain and DEM systems, procedural geometry and city/world generation, an Asset Library with identity, revisions, dependencies, lineage and provenance, persistence, scripting, audio/DSP and industrial connectivity through OPC UA and Modbus.
There is considerably more on the NthDimension website.
I'm mentioning these things here mainly to establish that the architectural argument isn't an attempt to rename a prototype renderer.
There is a fairly large engine underneath it.
I would rather describe a building than model one
Another problem I've been fascinated by for years is procedural generation.
I'm a software engineer, not an artist.
The idea of manually constructing thousands of buildings doesn't particularly interest me.
What interests me is describing one.
What is this building?
Why is it there?
What is it used for?
How large should it be?
What constraints does its site impose?
What characteristics should it possess?
How does the surrounding environment affect the result?
Then let machinery resolve that description into geometry and the other representations required at runtime.
Description + Context + Constraints
│
▼
Resolved Entity
│
┌───────┼────────┐
▼ ▼ ▼
Render Physics Semantic
│ │ │
└── Runtime Representations
I've increasingly found that this isn't merely a procedural-generation technique.
It's related to the same architectural question as the car.
Can the definition of something remain authoritative while specialized representations are derived from it?
NthDimension now explores this at several scales: terrain, roads, cities, buildings and characters.
And that eventually created another problem.
I needed somewhere sufficiently difficult to test all of these ideas together.
I needed evidence
I've tried to obtain investment for NthDimension.
I was rejected.
That's neither unusual nor particularly interesting by itself.
But underneath some of those conversations was an entirely reasonable question:
Where is the evidence?
A large architecture is easy to describe.
PowerPoint is remarkably tolerant of bad abstractions.
Real systems aren't.
Historically, industry had been my natural proving ground. But access to some of the environments around which my career developed became increasingly difficult. In Greece, many of the lignite power plants connected with that part of my work were being shut down.
I could continue drawing increasingly elaborate architecture diagrams.
Or I could find another sufficiently difficult system and make NthDimension confront it.
I chose the latter.
I'm building a game.
It's called Lumen Noir.
Why a game?
Lumen Noir is a science-fiction noir game set in 2126.
I'm mentioning it because it explains what I'm doing with NthDimension now.
A game obviously doesn't prove that NthDimension can operate a power plant.
What it provides is an extraordinarily hostile systems-integration problem.
A believable world needs terrain.
Weather.
Cities.
Buildings.
Vehicles.
Characters.
Skeletons and animation.
Objects.
Organizations.
Relationships.
History.
Persistent state.
Procedural generation.
Simulation.
Eventually all of those systems have to interact.
And that's where architecture diagrams encounter less glamorous realities:
frame budgets, numerical precision, memory, synchronization, serialization, broken references, asset identity, undo/redo, GPU stalls, persistence, editor workflows and bugs.
Lots of bugs.
That's exactly what I want.
Lumen Noir is my attempt to make NthDimension fail at scale.
If the architecture survives, I have evidence that some of these ideas may be useful.
If it doesn't, I've found another assumption that needs to die.
Both outcomes teach me something.
A fictional world can still test real architecture
A building inside Lumen Noir shouldn't have to exist only because the camera can currently see it.
It can have identity.
Purpose.
Relationships.
History.
Occupants.
State.
Its geometry can be one representation of that underlying entity rather than the entire definition of it.
The same applies to vehicles and eventually characters.
This is where procedural generation becomes particularly interesting.
Instead of:
Building = Mesh
I can work toward:
Building definition + environment + constraints + history → resolved building → representations
One representation might be detailed geometry.
Another might be collision.
Another could be a simplified distant representation.
Another could be semantic state.
The renderer shouldn't have to define what the building is simply because it's responsible for drawing it.
That's the architectural bet.
Back to the turbine
I still like the question I imagined asking when I was thirteen:
Hey turbine, how are you feeling today?
I've just become considerably less naive about what has to exist before a computer can give a meaningful answer.
Identity.
Relationships.
Measurements.
History.
Models.
Context.
Evidence.
And a clear distinction between what was observed and what was inferred.
Industrial systems taught me pieces of that problem.
Fred Lang and Exergetic Systems taught me how much engineering knowledge can exist behind apparently simple plant measurements.
Building NthDimension taught me that visualization alone doesn't solve it.
Now Lumen Noir gives me a laboratory in which to find out how much of what I've learned survives when I try to represent something much larger than one machine:
a world.
I'm not trying to prove that NthDimension is the best game engine.
I'm not trying to prove that it's the universal digital-twin platform.
I'm trying to answer a narrower question:
Can we build computational representations of complicated things without reducing those things to whichever subsystem happens to be looking at them?
I don't know whether my current answer is right.
That's why I'm building it.
For now, I've put current screenshots, engine specifications and more about NthDimension at syscon.gr.
What I'm most interested in discussing is the architecture.
Where does this idea stop scaling?
Does maintaining one semantic authority become too expensive or too tightly coupled once rendering, simulation, procedural generation, persistence and live telemetry all depend on it?
At what point should a derived representation become authoritative within its own domain?
How much causal and provenance information should survive into runtime before preserving it costs more complexity than the information is worth?
And how do you preserve one conceptual identity without accidentally building one enormous centralized object that every subsystem has to understand?
Those aren't rhetorical questions. They're some of the boundaries I'm interested in finding.
Where do you think it breaks?