# Datoviz: a Vulkan engine for scientific scenes, where the plotting API is not here yet

> Datoviz is a GPU rendering engine for interactive scientific data, with a retained scene model and a generated Python binding that takes NumPy arrays directly. Version 0.4 is a release candidate, the high level plotting functions are explicitly absent, and the layer you should use depends on what you are building.

**datoviz/datoviz** — ⚡ Datoviz: high-performance GPU rendering for scientific data visualization

- Repository: https://github.com/datoviz/datoviz
- Website: https://datoviz.org
- Stars: 817 · Forks: 43
- Language: C
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/datoviz-datoviz

## An engine for scientific scenes, not a plotting library

Datoviz is described as a GPU-powered visualization engine for interactive scientific data, and the README is precise about when to reach for it. Use it when dense points, images, meshes, volumes, annotations, linked panels, or custom scientific scenes need more control and performance than an ordinary plotting library provides.

The gallery shows what that means in practice: an interactive 3D protein visualization, an Allen mouse brain volume, a large colourised LiDAR point cloud, and a United States state population choropleth. Those four share little as charts and a lot as workloads, and that is the argument for one engine rather than a set of libraries.

The v0.4 feature set is described as a retained scene model, native Vulkan rendering, desktop and offscreen presentation, reproducible capture, and direct use from C or Python. The retained scene model is the part worth understanding before anything else. The scene is not a throwaway list of draw commands that is rebuilt on every redraw; it is kept, and the visuals, their data, the controllers and the panels are objects that live in it. That is what makes a linked panel, a camera that persists between frames, and a reproducible capture possible.

The project is MIT licensed, with the licence file at the root of the repository, and the primary language is C with a Python package generated from it. The last push to the repository was on 2026-10-20, and the repository is not archived.

## The Python binding is generated, and it hands you raw NumPy

Python users call the generated binding with import datoviz as dvz and pass NumPy arrays directly to the supported data upload APIs. The README's minimal example is a deterministic scatter plot, and the shape of the code says more about the design than any prose would.

First the data, with a seeded generator so the result is reproducible:

```python
import numpy as np
import datoviz as dvz

# Create deterministic NumPy arrays for one point per row.
n = 10_000
rng = np.random.default_rng(12345)
positions = rng.uniform(-1, 1, (n, 3)).astype(np.float32)
positions[:, 2] = 0
colors = rng.integers(0, 256, (n, 4), dtype=np.uint8)
colors[:, 3] = 200
diameters = rng.uniform(4, 12, n).astype(np.float32)
```

Then the scene, the figure and the panel:

```python
# Create the retained scene, its output figure, and one full-size panel.
scene = dvz.dvz_scene()
figure = dvz.dvz_figure(scene, 1280, 720, 0)
panel = dvz.dvz_panel_full(figure)

# Attach the arrays to a point visual, then add it to the panel.
points = dvz.dvz_point(scene, 0)
dvz.dvz_visual_set_data_many(
    points,
    {"position": positions, "color": colors, "diameter_px": diameters},
)
dvz.dvz_panel_add_visual(panel, points, None)
```

And finally the interaction and the window:

```python
# Bind 2D pan and zoom interaction, then open the native window.
panzoom = dvz.dvz_panzoom(scene, None)
dvz.dvz_panel_bind_controller(panel, panzoom, dvz.DVZ_DIM_MASK_XY)

dvz.run(scene, figure, title="Datoviz Quickstart")
```

Two things stand out. The data upload takes a dictionary of arrays under named keys, so there is no per point Python object and no conversion loop in user code. And the controller is a separate object bound to a panel with a dimension mask, so the same scene can be driven by different interaction models without rebuilding the visuals.

## Install the pinned release candidate, and the macOS wheel defect

Datoviz v0.4.0rc2 is the active published release candidate, and the README gives the exact install command:

```sh
python -m pip install --pre datoviz==0.4.0rc2
```

The version is pinned deliberately, and the README explains why: RC2 supersedes RC1, and macOS users should upgrade because the RC1 wheel has a native-window Vulkan-loader defect that RC2 fixes. That is a specific enough warning to act on. A wheel that opens a native window and cannot load the Vulkan driver is not a cosmetic difference between release candidates.

After the final v0.4 release, the normal command will be:

```sh
python -m pip install datoviz
```

For development, or on a platform with no published wheel, the source build is the route. It needs Git, CMake 3.21 or newer, Ninja, just, Python 3.10 or newer, a supported C or C++ compiler, shader tools and a Vulkan-capable runtime, and the clone has to bring the submodules with it:

```sh
git clone --branch main --recursive https://github.com/datoviz/datoviz.git
cd datoviz
just build
just test
python -m pip install -e .
```

The full installation guide covers macOS, Linux, Windows, Python and C and C++ integration, and the README points to it for platform packages, compiler versions, Vulkan and MoltenVK requirements and native Windows guidance. Contributors are pointed to CONTRIBUTING.md and BUILD.md as well.

## C linkage for native applications, and a CMake package

Datoviz is a native C library, and installed packages expose headers and a CMake package for C and C++ applications:

```cmake
find_package(datoviz CONFIG REQUIRED)
target_link_libraries(my_app PRIVATE datoviz::datoviz)
```

The public API uses C linkage and can be called directly from C++. That is a deliberate constraint rather than an accident of the binding generator, and it has a practical consequence: the same library that a Python user reaches through import datoviz as dvz is the one a native application links, so a mixed language codebase can share a scene.

The Python package carries the same shape. The manifest names the packages datoviz and datoviz.experimental, and the package data ships the shared libraries, the headers, the CMake package files and the JSON payload manifest, so the wheel is platform specific and self contained. The build system is a custom backend, datoviz_build_backend.backend, living under tools/, and the wheel configuration requires shaderc, which is the shader compiler the renderer needs at build time.

There is also a command line entry point, datoviz-config, wired to datoviz.cli:main, and an optional extra that pulls in PyQt6 for the Qt hosted rendering path.

For anyone integrating rather than scripting, the last line of the README's layer table is worth repeating: the C scene and app API is the release facing surface, and the Python API with NumPy adaptation is supported, while other areas are labelled as experimental or unstable.

## The v0.4 status table tells you what you can actually rely on

The README publishes a table of v0.4 surface status, and it is unusually candid, which is the main reason to read the project before using it.

Supported with feature specific gaps is the native C scene and app API. Supported is the Python API with NumPy adaptation and exact raw calls, and offscreen rendering and capture. Supported with an optional provider is Qt and PyQt hosted rendering. Retained visual families are supported or experimental depending on the family. Experimental are the WebGPU and WASM browser path and the scene compute to render integration. Advanced and unstable are the DRP2 command streams and runtime internals. And the high level plotting API is marked external and GSP.

The last row is the one that will surprise people arriving from a plotting library. The old high level Datoviz Python plotting API is not part of v0.4, and the README says that role belongs to the developing GSP and VisPy2 layer. The layer table makes the same point in user terms: for high level functions such as scatter() or imshow(), the answer is not in v0.4, use the scene API today and wait for GSP and VisPy2 later.

The practical reading is that Datoviz v0.4 is the explicit engine layer, covering scenes, visuals, data uploads, controllers, windows, captures and integration surfaces. If you want a function call that draws a scatter plot and returns an axis, this is not that tool yet. If you want a retained scene you can drive, capture reproducibly, and link panels in, it is.

## Where Datoviz is the wrong choice

The first wrong fit is wanting a plotting library. If the requirement is a quick chart with axes and a legend, an ordinary plotting library remains the shorter path, and the README says so by telling you the high level API is not in v0.4.

The second is a machine without Vulkan. The engine is native Vulkan rendering, the source build requires a Vulkan-capable runtime, the macOS path involves MoltenVK, and the wheel configuration requires shaderc at build time. On a machine with a software rasteriser or no Vulkan driver at all, the cost of making this work is a different project.

The third is a plan that depends on the experimental surfaces. The WebGPU and WASM browser path is experimental, and the README directs you to the feature status, platform support and v0.3 capability disposition pages before relying on an experimental or backend specific feature. That advice is not boilerplate: the browser path in particular is the one you would want for a hosted interactive example, and it is the one that is explicitly not finished.

The fourth is stability planning against a release candidate. The published artefacts are v0.4.0rc2 and v0.4.0rc1 from 2026-07-19, and v0.3.5 from 2026-01-21, so the version you install today is a candidate for the next major line rather than a settled release. The repository is a good indicator of how the project works in practice: there is a CHANGELOG.md, an ARCHITECTURE.md, an ADVICE.md, an AUDIT.md, a MAINTAINERS.md, a CITATION.cff, a paper/ directory, a spec/ directory, vcpkg and conda recipes, a docker/ directory and a justfile that imports task groups for maintenance, release, build, bindings, wheels, WebGPU, diagnostics and tests. The justfile even checks that the code excerpts in the Vulkan course chapters match their step programs, which is the level of internal consistency a project like this needs.

The fifth is a team that wants a maintained high level API with a roadmap it can build on. In that case the honest answer today is to watch GSP and VisPy2 rather than to adopt the engine layer and wait.

## Conclusion

Datoviz fits a team rendering dense points, volumes, meshes or linked panels that has outgrown a plotting library and wants one engine for both the interactive window and offscreen capture. It does not fit a project that wants scatter() and imshow() today, and it does not fit a machine without a Vulkan runtime. Before adopting it, install the pinned release candidate, read the feature status table for the visual family you need, and confirm the wheel for your platform exists.

## FAQ

### What is Datoviz?

It is a GPU-powered visualization engine for interactive scientific data, built as a native C library with native Vulkan rendering and a generated Python binding. The README positions it for dense points, images, meshes, volumes, annotations, linked panels and custom scientific scenes that need more control than a plotting library gives.

### How do I install Datoviz?

The active release candidate is v0.4.0rc2, installed with python -m pip install --pre datoviz==0.4.0rc2, and the README notes that macOS users should take RC2 because the RC1 wheel has a native-window Vulkan-loader defect. After the final v0.4 release, python -m pip install datoviz becomes the normal command.

### Can I use Datoviz from C or C++?

Yes. Installed packages expose headers and a CMake package, with find_package(datoviz CONFIG REQUIRED) and linking the datoviz::datoviz target, and the public API uses C linkage so it can be called directly from C++.

### Does Datoviz v0.4 include a scatter or imshow function?

No. The high level plotting API is not part of v0.4, and the README says that role belongs to the developing GSP and VisPy2 layer, so for now you use the scene API for those jobs.

### What does building Datoviz from source require?

Git, CMake 3.21 or newer, Ninja, just, Python 3.10 or newer, a supported C or C++ compiler, shader tools and a Vulkan-capable runtime, and the clone has to be made with --recursive so the submodules come along.

## Sources

- [datoviz/datoviz on GitHub](https://github.com/datoviz/datoviz)
- [License: MIT](https://github.com/datoviz/datoviz/blob/main/LICENSE)
- [Project website](https://datoviz.org)
- [README](https://github.com/datoviz/datoviz/blob/main/README.md)
- [Releases](https://github.com/datoviz/datoviz/releases)

---

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