OpenVDB: dünn besetzte Volumendaten in C++, gebaut über CMake
OpenVDB – Datenstruktur und Tools mit geringem Datenvolumen. Es wurde von DreamWorks Animation für den Einsatz in volumetrischen Anwendungen entwickelt, die typischerweise in der Spielfilmproduktion vorkommen.
Auf einen Blick
- Was ist das?
- Die von DreamWorks Animation stammende Bibliothek speichert Volumendaten hierarchisch. Einordnung von Trunk gegen Release, Build unter Linux, macOS und Windows sowie dem Wechsel zu Apache 2.0.
- Für wen ist es gedacht?
- OpenVDB ist die richtige Wahl für volumetrische Daten, bei denen ein dichtes Gitter den Speicher sprengen würde, also Rauch, Feuer, Wasser oder Wolken in einer Render-Pipeline. Wer GPU-nahe Verarbeitung sucht und auf den Werkzeugsatz verzichten kann, findet in NanoVDB eine schlankere Alternative mit eigener Bauanleitung.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
OpenVDB: hierarchische Gitter für dünn besetzte Volumendaten
OpenVDB ist eine C++-Bibliothek für dünn besetzte Volumendaten. Die README beschreibt sie als neuartige hierarchische Datenstruktur samt umfangreichem Werkzeugsatz zur effizienten Speicherung und Bearbeitung von Volumendaten, die auf dreidimensionalen Gittern diskretisiert sind. Entwickelt wurde sie von DreamWorks Animation für volumetrische Anwendungen, wie sie in der Spielfilmproduktion vorkommen. Heute liegt das Projekt bei der Academy Software Foundation, ist unter Apache 2.0 lizenziert und wird über openvdb.org sowie ein Diskussionsforum gepflegt.
Der Kernnutzen steckt bereits im Wort sparse. Bei Rauch, Wasser oder Wolken bleiben große Teile des Gitters leer, und ein dichtes Feld würde diesen Leerraum mitspeichern. Wie hoch die Einsparung in der Praxis ausfällt, beziffert die README nicht, es werden keine Zahlen genannt.
Mit 3.390 Sternen, 770 Forks und 237 offenen Issues ist das Projekt etabliert, ohne eine Massencommunity zu sein. Vier CI-Workflows sind eingerichtet: für die Kernbibliothek, OpenVDB AX, NanoVDB und Houdini.
Trunk gegen Produktionsrelease: was das Repository selbst einräumt
Die README trifft eine Unterscheidung, die bei Open-Source-Projekten selten so deutlich ausfällt. Dieses Repository enthalte den Entwicklungsstamm von OpenVDB. Das bedeute zum einen die neueste öffentliche Version mit den letzten Funktionen und Fehlerkorrekturen, zum anderen aber auch, dass dieser Stand wenig getestet und im Allgemeinen weniger stabil sei als die Produktionsreleases.
Für den Einsatz folgt daraus eine klare Trennung. Wer eine Bibliothek für eine Produktionspipeline braucht, nimmt ein Release-Tag. Wer mitentwickelt oder eine Korrektur vorab benötigt, arbeitet gegen den Stamm. Ein einfaches Klonen ohne Tag-Angabe landet beim Stamm, also ausgerechnet bei jenem Zweig, vor dem die README selbst warnt.
Beiträge sind willkommen, der Ablauf ist in CONTRIBUTING.md festgehalten. Für Fragen nennt das Repository ein Diskussionsforum und einen Slack-Kanal unter slack.aswf.io.
Abhängigkeiten unter Linux und macOS: Boost, TBB, Blosc
Der Schnellstart behandelt ausdrücklich nur die Kernbibliothek. Andere Bestandteile wie das Python-Modul, OpenVDB AX, NanoVDB und verschiedene ausführbare Programme können weitere Abhängigkeiten verlangen; dafür verweist die README auf die Build-Dokumentation unter openvdb.org.
Unter Linux werden drei Pakete installiert, jeweils mit apt-get install -y: libboost-iostreams-dev, libtbb-dev und libblosc-dev. Die README ergänzt einen Hinweis für Distributionen, die nicht die geforderten Versionen mitbringen, und empfiehlt in diesem Fall apt pinning.
Auf macOS führt der Weg über Homebrew, mit brew install boost, brew install tbb und brew install c-blosc. Danach folgt der übliche Ablauf: Repository klonen, Build-Verzeichnis anlegen, cmake .. ausführen und mit make -j4 && make install bauen sowie installieren.
TBB steht für Threading Building Blocks und deutet auf parallele Verarbeitung hin, Blosc auf Kompression. Welche Mindestversionen verlangt werden, nennt die README an dieser Stelle nicht.
Der Windows-Weg über vcpkg und VCPKG_DEFAULT_TRIPLET
Unter Windows fällt der Aufbau deutlich umständlicher aus, und die README schränkt die Anleitung von sich aus ein: Die Befehle seien ausschließlich für 64-Bit-Systeme und Bibliotheken geprüft. Empfohlen wird, die Umgebungsvariable VCPKG_DEFAULT_TRIPLET auf x64-windows zu setzen, damit standardmäßig 64-Bit-Bibliotheken genutzt werden. Benötigt werden Visual Studio für die MSVC-Laufzeitumgebung und den Compiler, CMake sowie wahlweise vcpkg für die Abhängigkeiten.
Die Abhängigkeiten werden einzeln installiert: vcpkg install zlib:x64-windows, vcpkg install blosc:x64-windows, vcpkg install tbb:x64-windows, vcpkg install boost-iostreams:x64-windows und vcpkg install boost-interprocess:x64-windows. Der anschließende Aufruf trägt die Werkzeugkette nach: cmake -DCMAKE_TOOLCHAIN_FILE=<PATH_TO_VCPKG>\scripts\buildsystems\vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows -A x64 ... Gebaut wird mit cmake --build . --parallel 4 --config Release --target install.
Auffällig ist die unterschiedliche Zahl der Abhängigkeiten: Unter Windows werden fünf Pakete genannt, unter Linux drei. zlib und boost-interprocess erscheinen nur im Windows-Abschnitt.
cmake-Optionen für OpenVDB AX und NanoVDB
Zwei Erweiterungen werden über Schalter an cmake zugeschaltet. -D OPENVDB_BUILD_AX=ON aktiviert OpenVDB AX, -D OPENVDB_BUILD_NANOVDB=ON aktiviert NanoVDB, und -D NANOVDB_USE_OPENVDB=ON verbindet NanoVDB mit OpenVDB. Die README weist darauf hin, dass weitere optionale VDB-Komponenten existieren, deren vollständige Liste in der Build-Dokumentation steht.
Die Abhängigkeiten sind nicht symmetrisch. OpenVDB AX setzt die Kernbibliothek voraus, während NanoVDB mit und ohne OpenVDB-Unterstützung gebaut werden kann. Für NanoVDB gelten eigene Bauanleitungen, erreichbar unter dem Dokumentationspfad NanoVDB_HowToBuild.html.
Wer Volumendaten GPU-nah verarbeiten will und auf den Werkzeugsatz der Kernbibliothek verzichten kann, für den ist NanoVDB die Alternative: eigene Struktur, eigene Bauanleitung, dafür kein Zugriff auf das vollständige Werkzeugset von OpenVDB.
Von MPL 2.0 zu Apache-2.0: was die Neulizenzierung praktisch bedeutet
OpenVDB steht unter Apache 2.0. Die README weist ausdrücklich auf einen Wechsel hin: Das Projekt habe die Neulizenzierung von der Mozilla Public License 2.0 zu Apache 2.0 abgeschlossen, Einzelheiten stünden in der Datei RE-LICENSE_NOTE.txt. Praktisch heißt das, dass jede Version ab dem Wechsel unter den Bedingungen von Apache 2.0 steht, während ältere Bestände noch unter MPL 2.0 lizenziert sein können. Wer OpenVDB in ein Produkt einbettet, sollte prüfen, welche Fassung er tatsächlich bezieht.
Eine zusätzliche Klausel betrifft Marken: Die Marken eines Beitragenden dürfen nicht ohne dessen ausdrückliche Erlaubnis im Zusammenhang mit dem Projekt verwendet werden. Für eigene Distributionen oder Schulungsunterlagen ist das beachtenswert.
Über den rechtlichen Rahmen hinaus macht die README keine Zusagen zu Sicherheit, Support oder Produktionsreife.
Versionsstand v13.0.0 und die Lücke seit November 2025
Das letzte Release ist OpenVDB 13.0.0 vom 4. November 2025. Davor liegen 12.1.1 vom 30. September und 12.1.0 vom 8. August 2025. Zum Zeitpunkt der Materialerhebung am 29. August 2026 liegt das letzte Release damit rund zehn Monate zurück, und auch der in den Metadaten verzeichnete letzte Push datiert auf den Tag von 13.0.0.
Bei einer Bibliothek, die in Produktionspipelines steckt, ist eine solche Pause nicht zwingend ein Warnzeichen, sie verändert aber die Planung. Wer eine Korrektur braucht, kann nicht auf das nächste Release warten, sondern muss sie selbst einbauen oder gegen den Stamm arbeiten. Genau deshalb ist der Hinweis im Abschnitt zum Entwicklungsrepository mehr als eine Formalie.
Ergänzend nennt das Projekt eine Einstufung bei den Core Infrastructure Initiative Best Practices unter der Nummer 2774. Was diese Bewertung im Einzelnen umfasst, geht aus der README nicht hervor.
Redaktionelles Fazit
OpenVDB ist die richtige Wahl für volumetrische Daten, bei denen ein dichtes Gitter den Speicher sprengen würde, also Rauch, Feuer, Wasser oder Wolken in einer Render-Pipeline. Wer GPU-nahe Verarbeitung sucht und auf den Werkzeugsatz verzichten kann, findet in NanoVDB eine schlankere Alternative mit eigener Bauanleitung. Weniger geeignet ist das Projekt für Umgebungen ohne C++-Buildkette, unter Windows ist der Aufwand über vcpkg sichtbar höher. Vor der Integration sollte geklärt sein, ob ein Release-Tag oder der Entwicklungsstamm bezogen wird; für Produktion verweist die README selbst auf die Releases. Danach lohnt ein Bau mit -D OPENVDB_BUILD_NANOVDB=ON, um die eigene Toolchain zu prüfen, bevor AX dazukommt.
Community-Notizen