# Skybolt: a C++ and Python engine for planetary-scale object simulation > Skybolt is an engine from Prograda for simulating and visualising dynamic objects such as aircraft, ships and spacecraft in a 3D planetary environment, built around a composition-based entity component system with C++ and Python plugins. It suits simulation and geospatial visualisation teams, and its documentation lives outside the repository, which is where most of the evaluation has to happen. **Prograda/Skybolt** — C++/Python-based 3D geospatial application for simulating and visualizing dynamic objects in planetary environments - Repository: https://github.com/Prograda/Skybolt - Stars: 658 · Forks: 56 - Language: C++ - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/prograda-skybolt ## An engine built around a geospatial coordinate system Skybolt is described as a C++ and Python based engine for simulating and visualising dynamic objects such as aircraft, ships and spacecraft in a 3D planetary environment. The repository description expands that into an application for simulating and visualising dynamic objects in planetary environments. The distinction from a game engine is in that first phrase, dynamic objects in a geospatial coordinate system. Real-time 3D object simulation within a geospatial coordinate system is the core feature, and everything else in the project is arranged around it. A scene graph built for arbitrary local coordinates is a different thing from an engine whose world is a planet with a coordinate system that aircraft, ships and spacecraft are placed into. The intended users are implied by the domain. The topic list attached to the repository names aerial imagery, atmospheric scattering, flight simulation, geospatial visualisation, open street map, ocean wave simulation, volumetric cloud and an image generator, and the feature list mentions terrain, ocean, urban infrastructure and atmospheric conditions among the things that can be visualised. The project is developed by Prograda, and it is not framed as a hobby project or a demo. There is a business enquiries contact form alongside the issue tracker and the discussions page, a single versioned release so far at 1.8.0, and a documentation site published through mkdocs with a dedicated Getting Started guide. That is the shape of a commercial engine whose source is available. ## Composition-based entity component system and configurable properties The modular architecture is the part of the design that determines how you extend the engine. Dynamic objects are modelled using a composition-based entity component system with a configurable property framework. Composition based is the distinguishing word. Rather than entities inheriting behaviour from a class hierarchy, an entity is assembled from components, and the components themselves are composed. For an engine that has to represent aircraft, ships, spacecraft and terrain at the same time, with the same simulation loop, that approach avoids a taxonomy that has to be rewritten every time a new vehicle type appears. The configurable property framework is the companion piece. Properties are described as configurable, which in an engine of this kind usually means that the set of properties attached to a component is itself defined by configuration rather than compiled in. The documentation does not spell out the configuration format, so it would be wrong to guess at the file syntax. What can be said is that the combination targets exactly the problem of a heterogeneous object model: entities of different kinds share the machinery because the variation lives in components and in property configuration. The practical consequence for an integrator is that the entity model is data, and the engine is a runtime for that data. Scenes, scenarios and object definitions can be composed without recompiling the engine, which is what makes it usable as an application platform rather than a code library. ## Plugins in C++ and Python are the extension route Custom functionality is added through plugins, and the project supports both C++ and Python based plugins. The choice between them is a real engineering decision rather than a detail. A C++ plugin is the route for anything performance sensitive or tightly coupled to engine internals. Simulation of aircraft and ships involves per-frame work over many objects, so anything in the hot path belongs in C++. A Python plugin is the route for configuration, tooling and domain logic that changes more often than the engine does. Since the engine is already a C++ and Python hybrid, the scripting boundary is where the project expects new behaviour to arrive, and it keeps the iteration loop short for a user who is experimenting with scenario content rather than rewriting the simulation core. The repository layout supports this reading. There is a src/ directory for the engine, a Scenarios/ directory that appears to hold scenario content, Tools/ for tooling, Assets/ for assets, and docs/ with an mkdocs.yml at the root, which is where the documentation site is configured. The scenario viewer app is a separate feature and a separate deployment shape: an interactive 3D application for visualising scenarios. That gives you two ways to work with the engine, building a tool or a simulation on one side and reviewing the result in a viewer on the other. ## Rendering breadth is where the topic list becomes useful The feature list says the engine can visualise photorealistic environments, including terrain, ocean, urban infrastructure and atmospheric conditions. The repository topics narrow that further and, since they are the project's own labelling rather than an outside claim, they are the best available guide to what the renderer actually contains. Atmospheric scattering and volumetric cloud are separate topics, which suggests clouds are rendered volumetrically rather than as skybox textures. Ocean wave simulation appears as its own topic, which points at an actual wave model in the ocean rendering rather than a normal map. Aerial imagery and open street map together suggest the terrain side can pull in both overhead imagery and vector map data as sources. An image generator topic implies the engine can produce imagery rather than only consume it, and cigi is a general interchange format for real-time scene description, which would make sense for a flight simulation engine that needs to load authored scenery. None of these are performance claims and none come with numbers in the documentation, so treat them as a list of subjects the engine covers rather than a benchmark. The honest summary is that this is a rendering stack aimed at realism over planetary scenes: sky, water, ground and the man-made layer above them. For an engineer, this is the part that decides fit. If your application needs believable sky and water over a large area, the topic list is a good sign. If it needs to draw a hundred thousand static polygons quickly, this is the wrong kind of engine. ## Build system: CMake, Conan and a shared lock file The repository layout says a lot about how a build is expected to work. At the root there is CMakeLists.txt, a CMake/ directory with the usual find-package and toolchain configuration, a Conan/ directory, a conanfile.py at the root, and a conan-shared.lock file. Conan is the dependency manager and the lock file is named shared, which indicates a lock that is intended to be shared across the project rather than per developer. For a C++ engine with native dependencies, a pinned lock file is the difference between a reproducible build and an afternoon of version conflicts, and having one in the repository is a good sign about the project's discipline. The docs/ directory with mkdocs.yml at the root means the documentation is built from markdown in the repository and published to the site, and the Getting Started guide lives there. This matters for evaluation: the project notes are short and point outward rather than repeating the content, so a reader has to go to prograda.github.io/Skybolt for the actual instructions. That is a real difference from most open source C++ projects, where the README carries the build steps. Here the build knowledge is hosted separately from the code, which is convenient for readers and inconvenient for anyone auditing the instructions against a specific commit. If you plan to pin a version, check that the documentation you are reading corresponds to the tag you are checking out. There is also a Tools/ directory at the root, which is where helper tooling for a C++ project of this kind usually lives. ## Licence, release cadence and the documentation gap The licence needs a note of caution. The README states that the project is licensed under the Mozilla Public License Version 2.0, with details in a file called License.txt, and that file is listed among the top level repository entries. GitHub itself reports the licence as a custom one it cannot classify, so automated licence scanners will not produce a clean answer for you. MPL 2.0 is a file-level copyleft licence, which is a materially different obligation from the permissive licences common in this category of project. If you intend to modify Skybolt files and distribute them, the obligations attach to those files, and a legal review is appropriate for a commercial deployment. This is a licensing question to check with your own counsel rather than a conclusion to draw from the project notes alone. On maintenance, the repository is not archived and the last push was on 2026-09-25. There is a single listed release, Skybolt 1.8.0, dated 2026-02-11. A project with a version above one and a single tagged release is consistent with a private development line that is published when the team chooses, rather than with an open release cadence, so you should expect to build from the branch rather than from a stream of tags. The documentation gap is the other thing to weigh. Everything a new user needs, including how to build and how to author a scenario, lives outside the repository. Read the Getting Started guide before deciding, because the README alone tells you very little about what you are getting. ## Conclusion Adopt Skybolt if your work involves dynamic objects in a geospatial or planetary setting, particularly if you can afford to write plugins in C++ and Python and to rely on an external documentation site for the build and scenario details. Do not adopt it as a general purpose 3D engine for a game or a graphics application, because the design centres on simulation in a geospatial coordinate system rather than on content authoring. Before you commit, read the Getting Started guide at prograda.github.io/Skybolt, confirm that the C++ and Python toolchain the documentation expects matches yours, and settle the licence question yourself by reading License.txt, since the repository file says Mozilla Public License 2.0 while GitHub reports the licence as one it cannot classify. ## FAQ ### What is the Skybolt engine and who is it for? Skybolt is a C++ and Python based engine for simulating and visualising dynamic objects such as aircraft, ships and spacecraft in a 3D planetary environment, with real-time simulation inside a geospatial coordinate system. It is aimed at simulation and geospatial visualisation work rather than general game development. ### How do I extend Skybolt with custom behaviour? The project supports custom functionality through plugins, in both C++ and Python. The composition-based entity component system and the configurable property framework mean that new object types and their properties can be defined as data and behaviour added as plugins. ### How do I get started with Skybolt? The repository points to a Getting Started guide inside the Skybolt documentation at prograda.github.io/Skybolt, with the documentation index at prograda.github.io/Skybolt/index.html. The build uses CMake together with Conan and a shared lock file, with conanfile.py at the repository root. ### What licence does Skybolt use? The README states that the project is licensed under the Mozilla Public License Version 2.0 and points to a file called License.txt for the details. GitHub reports the licence as one it cannot classify, so the file itself is the authoritative source for any compliance question. ## Sources - [Issues](https://github.com/Prograda/Skybolt/issues) - [Prograda/Skybolt on GitHub](https://github.com/Prograda/Skybolt) - [README](https://github.com/Prograda/Skybolt/blob/master/README.md) - [Releases](https://github.com/Prograda/Skybolt/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prograda-skybolt