# Nebula: a data driven C++ engine where fips, not cmake, runs the build

> Nebula is a modern C++ game engine with a Vulkan renderer, an ECS entity system and a data oriented design throughout, built on a Python based build tool called fips rather than on a plain cmake workflow. Getting it running means fetching dependencies, building PhysX and the shader language toolchain, and a Vulkan 1.2 capable GPU.

**gscept/nebula** — Nebula is an open-source and free-to-use modern C++ game engine.

- Repository: https://github.com/gscept/nebula
- Website: http://nebulatrifid.org/
- Stars: 1,102 · Forks: 63
- Language: C++
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/gscept-nebula

## fips, the build tool that owns the dependency graph

Nebula's build system is the first thing to understand, because it differs from what most C++ developers expect and it shapes everything else.

The engine is built with fips, a Python based build system linked in the README under other useful references and tools. fips is not just a wrapper around cmake. It manages the dependency graph, it fetches and checks out the required repositories, it knows about configurations, and it can build the engine itself when you are setting up an external project.

The setup sequence in the documentation shows the shape of it. First you set a config.

```bash
fips set config win64-vstudio-debug
```

Then you fetch everything.

```bash
fips fetch
```

That step downloads or checks out all the other required repositories, and the documentation says fips will take care of getting the relevant dependencies, including the actual engine in the case of an external project.

Then you point fips at where the code lives, using the fips nebula verb to set work and toolkit directory registry variables. The work variable is the path of your project, and the toolkit variable is the path to the nebula checkout, which for an external project would be ../nebula.

The reason for this design is visible in the repository layout. The top level holds a fips directory, fips-files/ with the configuration including a configs folder, fips.yml, fips.cmd for Windows, a CMakeLists.txt, a gpulang_config.json, and separate extlibs/ and toolkit/ directories. The engine is structured as a fips project with a dependency manifest, and the external libraries and the toolkit are pulled into that structure rather than vendored by hand.

## The fast path is a separate demo repository with a setup script

Before any of the manual setup, the README points at a shortcut. The fastest way to set up and test Nebula is to clone the Nebula-demo repository instead, because it contains a setup.bat which will set up the dependencies and configure a solution for you to run via fips open.

So the engine repository is not where you start. You start in a small project that knows how to pull the engine in as a dependency, which is the same mechanism an external studio would use. That is a deliberate design decision and it has a real effect on how you learn the codebase: you get a running project first and the engine source second.

The alternative manual path is documented too. You can build and run the project manually with fips build, fips run assetbatcher and fips run nebula-demo --. If you add a -editor commandline argument it will start with the editor user interface enabled.

Apart from that there are a few simple projects in the test folder.

The everyday commands follow a pattern worth internalising, because they recur. fips gen regenerates the solution through cmake when you add new files, whether source or flatbuffer things, and the documentation calls it a safe operation to run if dependencies change. fips open starts your editor, and fips build compiles, either through the generated solution or directly. fips update performs a git pull on the dependencies when other fips dependencies have changed, which is how you pick up upstream changes in the engine itself.

The build output location is specific and useful. fips places the solution and makefiles in the ../fips-build/{PROJECT-NAME}/{CONFIG}/ folder, and the easiest way to start your editor is fips open.

## Dependencies you have to build yourself, starting with PhysX

Two dependency steps are called out separately, and both are non-trivial.

The first is PhysX, the physics library, which is built through fips itself for a specific configuration.

```bash
fips physx build vc17 debug
```

The documentation notes that if you are running VS 2022 you should use vc16 or vc15 for VS 2019 and 2017 instead, which is a small sign of how much the toolchain configuration predates the current Visual Studio version. The configuration name has to match the one you set earlier, and the two steps are coupled.

The second is the shader language toolchain.

```bash
fips gpulang setup
```

This is the GPU language setup step, and it exists because the engine compiles shaders as part of the build, which is why there is a gpulang_config.json in the repository root.

The requirements list is short and strict. The operating system must be Windows or Linux, with Linux marked as work in progress. The compiler needs C++20 support. The GPU and drivers need to support Vulkan 1.2 or later. CMake 3.21 or newer is required. And Python 3 is needed, which is the runtime for fips itself.

That last point is worth noticing. Python is not optional tooling you install once, it is a build dependency of the engine, and the separate demo repository is the documented fastest way to set up and test Nebula. For a C++ engine project, that is a deliberate bet on Python as build orchestration rather than as an application language, and it is a bet that pays off for cross platform configuration but that also means your build environment has two toolchains in it.

## The content pipeline, where assetbatcher does the cooking

Content is not loaded from source assets at runtime. It is batched, and the tool that does it is the assetbatcher, which lives in the nebula repository and is built by default by projects as well.

```bash
fips run assetbatcher --
```

The description of what it does is specific and worth understanding. It incrementally converts or cooks content in your work folder to an export folder in the project location. It has a number of options to force or only batch specific folders, as well as the option to be run in parallel, and running it with -help prints the available options.

So the pipeline is a conventional offline cook. Source assets live in a work folder, the batcher converts them into a cooked form in the project, and the runtime loads the cooked form. The incremental behaviour matters for iteration speed, since a full recook of a large project on every change is what makes a content pipeline unpleasant, and the parallel option addresses the other half of that problem.

Running the project itself is the same pattern.

```bash
fips run {PROJECT-NAME} -- -editor
```

Use fips run {PROJECT-NAME} to run the debug project without editor tools, or run a debug session in the solution opened with fips open. Adding the -editor commandline argument runs it with the editor user interface enabled.

The distinction between the plain run and the editor run is the same distinction you see in most modern engines, where the editor is a separate mode of the same runtime rather than a separate application.

## A rendering subsystem that pushes work onto the GPU

The rendering feature list is where Nebula's ambitions show, and it is worth reading as a set of design positions rather than a shopping list.

The unified clustering system puts fog volumes, decals and lights into the same structure, which is a data oriented answer to the problem of handling many small lights. The screenshots show deferred lighting using 3D clustering and GPU culling, and geometric decals culled and calculated entirely on GPU and rendered in screen space.

Other entries describe specific techniques rather than feature labels. Screen-space reflections are described as working condition but still work in progress, which is an unusually honest way to list a renderer feature. Horizon-based ambient occlusion is done in compute. Shadow mapping is used for local lights and CSM for global, directional and sun light. Virtual texturing uses sparse binding, and there is adaptive virtual textured terrain. There is a fast and conservative GPU memory allocation, asynchronous compute, volumetric fog and lighting, area lights, a CPU and GPU hybrid particle system, skinning and animation, physically based materials, tonemapping, and a scripted rendering path.

The entity system is the other half of the architecture, and its history is stated directly. Nebula has historically had a database-centric approach to entities, and with the newest iteration the project has decided to keep improving by adopting an ECS approach while still keeping it database-centric. The stated properties are data oriented, data driven, minimal memory overhead per entity, high performance without compromising usability or simplicity, and automatic serialization and deserialization.

Keeping the database centric approach while moving to ECS is a real architectural compromise rather than a clean break, and it is the kind of decision that tells you the team is evolving an existing codebase rather than designing from scratch.

## The licence, the licence file, and the documentation gap

Two things are thinner than the feature list suggests, and both matter for a decision.

The first is the licence. GitHub classifies it as Other, a custom licence it cannot categorise, and points to the LICENSE file. The repository root has license.txt rather than a file named LICENSE, and the licence is not a standard identifier you can look up. The content of that file is the only place the terms are stated, and for anyone planning to use the engine in a commercial product, that file is the first thing to read. It may well be permissive, but the repository does not tell you that in a form you can check quickly, and an engine that also pulls in PhysX, the Vulkan SDK and a set of external libraries carries those licences too.

The second is the documentation. The README links to the documentation and marks it as WIP, at gscept.github.io/nebula-doc. A work in progress engine with a work in progress documentation site is a coherent combination for a research or learning project. It is a different proposition for a team that needs to answer questions in a week.

What compensates for the thin prose is the code itself, which is the point of the project existing in this form. The topics list gives the vocabulary: classless API, data oriented architecture, multithreading, performance, Vulkan, and the game engine 3d tag. The data structure suite is described as running from containers to OS wrappers, everything designed for performance and minimal call stacks, with an SSE accelerated and intuitive maths library, C# scripting, test benches and benchmarking, and profiling tools.

The profiling screenshots are worth a second look, because a profiler in a hobby project is a statement about intent. If you are evaluating this engine, the profiler is as much the product as the renderer is.

## Conclusion

Nebula fits a C++ graphics programmer who wants to read a modern renderer rather than use one, who wants an entity system that is data oriented rather than object oriented, and who is comfortable owning a build system that pulls dependencies with git. It does not fit a team that wants a turnkey engine with an editor, an asset pipeline and a documented workflow on day one, and it does not fit anyone without a Vulkan 1.2 capable GPU and a C++20 compiler. Check three things before you commit. Check the build path, because the fips workflow is not a cmake command you can improvise, and the quick start route through the separate nebula-demo repository with its setup.bat is the documented fast path. Check your PhysX build, since the setup explicitly requires building that dependency for your chosen configuration. And check the licence, because it is a custom one that GitHub cannot classify and the file is named license.txt rather than carrying a standard identifier. The last push was on 2026-10-15, the repository has no GitHub releases, and the documentation is marked as work in progress.

## FAQ

### What are the requirements for building the Nebula engine?

Windows or Linux with Linux marked as work in progress, a compiler with C++20 support, a GPU and drivers supporting Vulkan 1.2 or later, CMake 3.21 or newer, and Python 3.

### How do I build and run the Nebula demo?

Clone the separate Nebula-demo repository, which contains a setup.bat that sets up dependencies and configures a solution to run via fips open. Manually you can use fips build, fips run assetbatcher and fips run nebula-demo --, with the -editor argument starting the editor user interface.

### What does fips do for the Nebula project?

fips is the Python based build system the engine uses. It fetches and checks out required repositories including the engine itself for external projects, manages configurations, and provides verbs such as fips gen, fips build, fips open, fips update and fips run.

### How is content handled in Nebula?

Content is cooked with the assetbatcher, which incrementally converts content in the work folder to an export folder in the project location, with options to force or restrict which folders are batched and an option to run in parallel.

### What is the entity system in Nebula based on?

The entity system has historically been database centric, and the newest iteration adopts an ECS approach while staying database centric, with data oriented and data driven design, minimal memory overhead per entity, and automatic serialization and deserialization.

### What license is the Nebula engine released under?

A custom licence that GitHub cannot classify, with the terms in the license.txt file at the root of the repository. The last push was on 2026-10-15 and the repository has no GitHub releases.

## Sources

- [gscept/nebula on GitHub](https://github.com/gscept/nebula)
- [Issues](https://github.com/gscept/nebula/issues)
- [Project website](http://nebulatrifid.org/)
- [README](https://github.com/gscept/nebula/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gscept-nebula