# OpenSpace: an interactive renderer for the known universe, minus the Mac > An open source astronomy visualisation application that can drive a laptop screen or a planetarium dome, with scripting in Lua, JavaScript and Python and a way to export a session as video frames. The hard constraint is the graphics layer, because OpenSpace needs OpenGL 4.6 and macOS is explicitly unsupported. **OpenSpace/OpenSpace** — This is the official GitHub repository for OpenSpace: an open source astrovisualization project. For instructions on how to build and run OpenSpace, see the Getting Started Guides on the wiki page at http://docs.openspaceproject.com. - Repository: https://github.com/OpenSpace/OpenSpace - Website: http://openspaceproject.com - Stars: 1,297 · Forks: 218 - Language: C++ - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/openspace-openspace ## What the software is and who it is for OpenSpace is an open source, non-commercial, freely available interactive data visualization software designed to visualize the entire known universe and portray our ongoing efforts to investigate the cosmos. The description in the repository is that it brings the latest techniques from data visualization research to the general public. The feature it offers is interactive presentation of dynamic data from observations, simulations, and space mission planning and operations. The scale question is answered directly. The software works on multiple operating systems, Windows and Linux, with an extensible architecture capable of powering both personal computers and high resolution tiled displays and planetarium domes. In addition, OpenSpace enables simultaneous connections across the globe, creating an opportunity for shared experiences among audiences worldwide. The target audience is described in four groups, and the list is a good summary of who this is for. The general public who wishes to explore our universe. Enthusiasts interested in hacking the underlying components to create unique experiences. Informal science institutions wishing to create a low-cost yet powerful exhibition piece. And scientists desiring to visualize their datasets in a contextualized, powerful software. That last group is the one that makes the project more than a planetarium show. The same renderer that draws a sky catalogue for a museum is the one a researcher uses to put their own simulation output in context. The project is not archived and the last push was on 2026-10-15. The releases are v0.22.0 from 2026-06-12, v0.21.4 from 2026-04-30 and v0.21.3 from 2025-12-01, and the default branch is master. ## The academic lineage and the two papers The Background section is a short history that explains why the software looks the way it does. OpenSpace started as a collaboration between Sweden's Linköping University and the American Museum of Natural History. Development began several years ago through a close collaboration with NASA Goddard's Community Coordinated Modeling Center to model space weather forecasting, and continued with visualizations of NASA's New Horizons mission to Pluto and ESA's Rosetta mission to 67P/Churyumov-Gerasimenko. That preliminary work provided a foundation for continued funding from NASA, the Swedish eScience Research Centre and the Knut and Alice Wallenberg foundation, which extended the collaboration to include the University of Utah's Scientific Computing and Imaging Institute, New York University's Tandon School of Engineering, multiple informal science institutions across the world, and multiple international vendors. The two paper links in the README are the peer-facing side of the same history. There is a system paper with a DOI in IEEE TVCG, and a globe browsing paper, also in TVCG, from 2017. The globe browsing paper is the more interesting of the two for an engineer, because the problem of navigating a globe in a tiled display environment is what forces the architecture to be extensible in the first place. The repository also has the paperwork that goes with an academic project of this kind: `ACKNOWLEDGMENTS.md`, `CREDITS.md`, `THIRD_PARTY_LICENSES.md` and a `CITATION.cff`, which is the file that tells a citing tool how to cite the project. There is also a `LICENSE.md` whose badge reads MIT, while the licence field in the repository metadata is recorded as a custom one that GitHub cannot classify, so the file itself is the authority on the terms. ## What is in the box, and the scripts that drive it The high-level features are the ones a user would name when describing the software. There is AMNH's Digital Universe catalog of extrasolar datasets, which covers stars, galaxies and quasars. There are high-resolution planetary images for major objects in the solar system, naming Earth, Moon, Mars and Venus. There are animated 3D models representing space missions, with the ISS, New Horizons and JWST given as examples. There is support for custom profiles with arbitrary user-defined content. And there is the ability to drive any type of display environment, with a flat screen, multi-projector and planetariums given as examples. Then the two features that make it a platform rather than a show. There are Lua, JavaScript and Python interfaces into the engine, allowing highly customized controls. And there is native support to export an interactive session as individual frames for video export, which is how a live show becomes a video. The scripting story is the important one for an institution. A planetarium is not a fixed film, it is a live operator driving a timeline, and Lua is the traditional language for that. The three languages mean a team can write in whichever one fits their pipeline, and the fact that the interfaces hook into the engine rather than into a UI means the control surface is the whole application. The repository itself contains the source code and the example profiles, and it does not contain any data. The data is downloaded separately, which is why the Getting Started Guides on the documentation site are the entry point rather than a build instruction in the README. ## OpenGL 4.6, and why macOS is out The platform constraint is stated twice, once as a requirement and once as an exclusion. OpenSpace requires support for OpenGL 4.6. And macOS is not supported. The reason is given in detail: the Apple Silicon series of chips do not support OpenGL natively, and Metal 2 does not support `double` precision accuracy, with a link to the Metal Shading Language specification, Section 2.1, as the authority. That is a hardware and driver fact rather than a porting effort, and it is the kind of exclusion a project should state plainly rather than leave you to discover during a build. OpenGL on macOS has been deprecated for years, and the compute-heavy double precision work that a space visualisation renderer does is exactly what the Metal path cannot deliver. The build requirements follow from the same constraint. You need CMake version 4.0 or above, and a C++ compiler supporting C++23, with Visual Studio 2026 18, GCC 15 and Clang 21 given as the versions that qualify. C++23 is a recent requirement, and it is worth noticing that the project is tracking the language rather than settling on a comfortable baseline. That has a cost for anyone contributing, since the build environment becomes part of the barrier to entry, and it is a reason the project has an `AGENTS.md` and a detailed contribution process. ## The build system and the test infrastructure The repository layout shows a project with a serious engineering setup behind the visualisation. The build is CMake, with a `CMakeLists.txt` at the root and a `CMakePresets.json` for the editor and command line presets. There is a `vcpkg.json`, which is the manifest for the Visual C++ package manager, so the C++ dependencies are declared and fetched rather than installed by hand. There is a `Doxyfile` for the API documentation and a `.clang_tidy` for the static analysis configuration. The source is split into `src/` for the core, `include/` for the public headers, `apps/` for the applications, `modules/` for the loadable content, `shaders/` for the GPU programs, `ext/` for the external dependencies, `data/` for the data handling, `config/` for configuration, `support/` and `tests/` and `visualtests/`, the last being the directory that tells you the project has screenshot-based regression testing for its rendering. That last one is notable. A renderer that is visually correct is hard to assert on, so a visual test suite that compares frames is how you catch a shader regression. The `openspace.cfg` file at the root is the configuration the application reads. The continuous integration is Jenkins rather than a hosted forge, with a `Jenkinsfile` and a `Jenkinsfile.nightly`, and the `scripts/` directory holds the build and packaging scripts. There is also a `.mailmap` file, which is the mechanism for keeping authorship attribution correct across a large group of contributors, and a `CREDITS.md` alongside it. ## Where OpenSpace is the wrong choice The first wrong case is macOS. This is not a preference, the README rules the platform out because the hardware does not support the graphics API the software needs at the precision it needs. A designer or a student on a Mac has to use a different machine entirely, and the Getting Started Guides are where to find out what that means in practice. The second is a team looking for a component. OpenSpace is an application with a build, a data pipeline and a display layer, not a library you link against. If you want to draw a sky catalogue in your own software, this is the wrong shape and you want a graphics library instead. The third is an institution that cannot maintain a rendering machine. The project is explicit that it can drive high resolution tiled displays and planetarium domes, and that implies a projector setup, a GPU, a sound system and someone who can operate them. A small community space with a laptop and a projector might work, and the README names informal science institutions as an audience, but the operational commitment is real. The fourth is a project that needs the data to be in the repository. The repository holds the source and the example profiles, and the data comes from elsewhere, so a deployment has to manage data acquisition and licensing on top of the build. The fifth is an organisation that needs commercial support or a commercial licence. The software is described as non-commercial and freely available, and while the licence badge reads MIT, the licence metadata is recorded as custom, so the terms for a commercial deployment are worth reading in `LICENSE.md` rather than assuming. ## Conclusion OpenSpace suits a museum, a planetarium or a science communicator who needs a full-dome rendering of sky catalogues, mission animations and datasets, and who can deploy on Windows or Linux hardware with a modern OpenGL driver. It does not suit a macOS user, because the README rules that platform out on hardware grounds, and it does not suit a developer who wants a library, since this is an application with its own build and its own asset pipeline. Before starting, read the Getting Started Guides on the documentation site, because the repository contains the source and example profiles but no data, and confirm your display hardware supports OpenGL 4.6 before you plan the build. ## FAQ ### What is OpenSpace? It is an open source, non-commercial, freely available interactive data visualization software designed to visualize the entire known universe, supporting interactive presentation of dynamic data from observations, simulations, and space mission planning and operations. ### Can I run OpenSpace on macOS? No. The README states that macOS is unsupported, because Apple Silicon chips do not support OpenGL natively and Metal 2 does not support double precision accuracy. OpenSpace requires OpenGL 4.6 support. ### What do I need to build OpenSpace? CMake version 4.0 or above and a C++ compiler supporting C++23, with Visual Studio 2026 18, GCC 15 and Clang 21 given as the qualifying versions. The build instructions are in the Getting Started Guides on the documentation site. ### Can I script OpenSpace? Yes. The README lists Lua, JavaScript and Python interfaces into the engine, allowing highly customized controls, and there is native support to export an interactive session as individual frames for video export. ### Does the OpenSpace repository include the astronomical data? No. The repository contains the source code and the example profiles, but no data. The data is handled separately, and the documentation site carries the build and installation instructions for each operating system. ## Sources - [Issues](https://github.com/OpenSpace/OpenSpace/issues) - [OpenSpace/OpenSpace on GitHub](https://github.com/OpenSpace/OpenSpace) - [Project website](http://openspaceproject.com) - [README](https://github.com/OpenSpace/OpenSpace/blob/master/README.md) - [Releases](https://github.com/OpenSpace/OpenSpace/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openspace-openspace