LumixEngine: a C++ 3D engine built around data-oriented design

What LumixEngine solves, and for whom

Most engine choices force a trade: a commercial engine gives you tooling and a release cadence but hides the source, while a small open source engine gives you source but often little else. LumixEngine sits at the second end deliberately. It is a 3D game engine written in C++, licensed under MIT, and its README describes it in one line: "3D Game Engine". The topics attached to the repository name the design intent directly: 3d-game-engine, data-oriented-design, editor, entity-component-system, game-development, game-engine, linux, windows.

The audience follows from that. This is for programmers who intend to open the engine's own source, not just call an API from it. The MIT licence removes the licensing negotiation that comes with commercial engines, and the repository layout (src/, external/, data/, demo/, scripts/) assumes you will build from a checkout rather than install a binary. If your team has no C++ capacity, the project offers nothing to compensate.

It is not a general-purpose tool for designers. The README links a Features wiki page, a documentation site and a getting-started page, but nothing in the repository describes a scripting-first workflow for non-programmers. Teams that ship by handing a scene file to an artist should look elsewhere.

The data-oriented ECS core and the editor around it

The repository topics list entity-component-system and data-oriented-design, and the engine is organised as a C++ core plus an editor. The demo directory shows the shape of a project: demo/lumix.prj is the project file, demo/main.evox is a scene, and demo/maps/, demo/models/, demo/textures/, demo/ui/, demo/scripts/, demo/navzones/ and demo/probes/ hold the assets and scripts that scene references. A .prj file is the unit you open in the editor; .evox is the scene format. That pairing is the engine's working model: the editor edits a project, and the project points at assets on disk.

The data-oriented part matters more than the label. An ECS that stores components in contiguous arrays is a different programming model from an object hierarchy with inheritance, and it changes how you write gameplay code: you iterate over component sets rather than walking a tree of game objects. The README does not spell out the storage details, so the honest statement is that the repository advertises data-oriented design and an ECS, and the source in src/ is where the actual component layout would be confirmed.

Around that core sits an editor, shown in the README's screenshot and referenced by the getting-started video. The editor is the entry point for scene assembly, and the demo project exists to be opened in it. Nothing in the repository describes a headless or command-line build pipeline for content, so treat the editor as the normal path for producing a scene.

Installing LumixEngine and opening the demo project

The README does not give a step-by-step build recipe. It links a getting-started page at nem0.github.io/LumixEngine/getting_started.html, a video walkthrough, and a documentation site, and it names one build dependency explicitly: the project generator Genie, from bkaradzic/genie. That is the piece to install first, because the repository ships scripts/ and external/ rather than a ready-made CMake or Visual Studio solution at the top level.

Clone the repository from the URL the README and the GitHub page give, then fetch Genie from its own repository and use it to generate a project for your platform. The README does not list the exact Genie command line for this repository, so run Genie's own help output before guessing at flags:

git clone https://github.com/nem0/LumixEngine.git

Once a solution or makefile exists, build it and run the editor. The demo project is the first real thing to open. The README's example files list the project file and the scene it loads:

cd LumixEngine

Opening demo/lumix.prj in the editor should load demo/main.evox and resolve the asset folders next to it. If the editor starts but the scene is empty, the usual cause is that assets were not found relative to the project file, which is why the demo keeps maps, models and textures in sibling directories rather than in an installed location. The README does not document an install step that copies assets elsewhere, so keep the demo tree intact.

Where LumixEngine is the wrong tool

The release history is the first limitation, and it is not a small one. The newest release listed is v2.0alpha, tagged 2021-05-17, preceded by alpha in 2020 and ffr_prototype in 2019. The last push to the default branch was on 2026-09-22, so the repository is not archived and work continues, but the release channel has not produced a stable version in years. Anyone who needs a frozen version with a changelog to pin against is choosing the wrong project.

Documentation depth is the second issue. The README is a link hub: getting started, features wiki, videos, documentation site, Discord. It does not describe the build flags, the component model, or how to export a game. The repository also does not document rollback behaviour, save compatibility between engine versions, or a plugin ABI. For an engine whose selling point is source access, that is tolerable, because the source is the specification. For a team that budgets for onboarding from written docs, it is a real cost.

Third, the ecosystem is thin. The README's "Who is using it?" section names one game, On the Hunt, and the showcase links to a separate repository of sample projects (asteroids, tower defense, chess, platformer). There is no plugin marketplace or asset store described. That is not a defect in the engine, but it means every integration is your own work.

How it compares with other open source C++ engines

The related searches around this project point at a cluster of similar engines: ezEngine, RavEngine, MxEngine, Irrlicht, Kohi. The meaningful difference between them is not the feature list, which is broadly comparable, but the release and documentation posture.

Irrlicht is the older comparison. It has a long history as a C++ engine with a scene-graph style API, and its documentation tradition is different from LumixEngine's link-and-source approach. If you want an engine whose API surface has been written about for years, Irrlicht is the closer match. If you want an ECS core and a data-oriented component layout, LumixEngine's topics point at a different design.

ezEngine is the closer structural comparison, since it is also a C++ engine with an editor and a permissive licence. The difference to check before choosing is the component model and the build system: LumixEngine routes project generation through Genie, while nothing in this repository says how ezEngine is built, so that comparison has to be made by reading both codebases rather than from this page.

What LumixEngine offers that none of these guarantee is a small, MIT-licensed codebase with the editor included and the demo project checked in. The trade is that you inherit the maintenance.

Maintenance, upgrades and the MIT licence

The last push to master was on 2026-09-22, one day before this article was written, so the repository is being touched. That is not the same as a maintained release line. The gap between v2.0alpha (2021-05-17) and current master means anyone tracking the engine is tracking commits, not versions, and no migration guide between them is documented. Upgrading therefore means reading diffs in src/ and rebuilding, and the cost of that falls on you each time you pull.

The MIT licence is the simplest part of the picture. It permits use, modification and redistribution with the licence text retained, and it carries no copyleft obligation on your game code. That is the usual reason a small studio picks an MIT engine over a GPL one. This is a description of the licence identifier in the repository, not legal advice; if your product embeds the engine in a way you have not shipped before, have counsel read the LICENSE file rather than this paragraph.

One practical upgrade cost is easy to miss: because project files (.prj) and scenes (.evox) are engine-defined formats, a change in the component model can invalidate existing scenes. No scene migration path is documented, so keep the demo project around as a canary after each pull.

Frequently asked questions

The questions below are the ones a new user actually asks before building. They are answered from the repository's own material, and where that material is silent, the answer says so rather than filling the gap.

Editorial conclusion

Adopt LumixEngine if you are a C++ programmer who wants to read, build and change an entire engine, and who is comfortable treating the master branch as the product. Avoid it if you need a documented, versioned release with a support commitment, since the newest release is v2.0alpha from 2021-05-17 and the README points to nothing newer. Before committing, clone the repository, run the Genie project generator for your platform, build the demo in demo/lumix.prj, and open it in the editor to confirm the workflow matches how your team ships code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nem0/LumixEngine on GitHub
4. README
5. Releases