# 3dgrut's manifest says version 2.0.0 while the newest tag is v1.1.0

> NVIDIA's reference implementation of Gaussian ray tracing, rasterization and a hybrid of the two, for training and rendering particle scenes. Three version numbers disagree with each other, two tracer directories differ by a single letter, and USD export is gated to Linux on x86_64 while the package declares itself operating system independent.

**nv-tlabs/3dgrut** — Ray tracing and hybrid rasterization of Gaussian particles

- Repository: https://github.com/nv-tlabs/3dgrut
- Stars: 2,450 · Forks: 281
- Language: Python
- License: Apache-2.0
- Published: 2026-09-16 · Updated: 2026-09-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nv-tlabs-3dgrut

## The package manifest reads 2.0.0 while the newest tag is v1.1.0

Three version numbers sit in three places and they do not agree. The project metadata names the package threedgrut at version 2.0.0. The changelog headline for 2026/06 announces 3DGRUT v2.0.0 with Neural Harmonic Textures support. The release list shows two tags, v1.1.0 published 2026-06-10 and v1.0.0 published 2025-04-03. So the tag created on the same day the 2.0.0 feature landed is 1.1.0, and no 2.0.0 tag exists. Both release titles are also the same string, Stable Code Release, with the 1.1.0 one carrying a date in parentheses. Nothing in the repository reconciles the three, so a build that resolves the package version from the metadata reports a major version that has never been cut, and a build that pins to the newest tag gets 1.1.0.

## Two tracer directories are named one letter apart

The root holds four directories whose names cover the same subject in four spellings: threedgrut, threedgrut_playground, threedgrt_tracer and threedgut_tracer. The last two differ only at the seventh character, where one reads r and the other u, so threedgrt_tracer and threedgut_tracer sit side by side and an import path typed from memory has a one letter chance of being wrong. Neither the directory names nor the four root scripts, train.py, render.py, playground.py and validate.py, are explained in the visible documentation, which stops partway into the Linux install options after listing uv, a CUDA toolkit and OpenGL headers, with a further option beginning but not completing. Alongside them sit two more requirement files, requirements_extra.txt and requirements_tinycudann.txt, so dependencies arrive by three routes: the project metadata, and two files nothing in the overview points to.

## USD export is gated to Linux on x86_64 while the package declares OS independence

The classifier list carries one entry, Operating System :: OS Independent, and the same block installs usd-core with a marker restricting it to sys_platform linux and platform_machine x86_64, with a comment saying usd-core is only available for amd64. On any other platform that dependency is simply absent, which matters because the contents list names USD as one of three export targets alongside PLY and NuRec. Windows support was added in 2025/07 and is offered through UV install scripts, so the supported platform and the export-capable platform are not the same set. The block also shows what was taken out: a slangtorch pin at 1.3.18 restricted the same way, commented out under a doubled hash with the note that it works on amd64 only. The two markers are formatted as comments, one active and one disabled, so the platform restriction is legible in the file rather than enforced by a check.

## The container sets a surfaceless EGL platform for a tool that wants OpenGL headers

The image sets EGL_PLATFORM to surfaceless, which tells the graphics stack there is no display surface to present to. The Linux prerequisites in the documentation ask for OpenGL headers for the playground, installed with libgl1-mesa-dev, and the interactive playground GUI is one of the numbered sections alongside training, rendering, evaluation and asset preparation. A surfaceless platform and an interactive GUI are different use cases, and the container also redirects XDG_DATA_HOME to a path under /usr/local/share/uv and XDG_BIN_HOME to /usr/local/bin, so anything the tools write lands outside a home directory. The remaining environment sets NVIDIA_VISIBLE_DEVICES to all, driver capabilities to graphics, compute and utility, and FORCE_CUDA to 1. None of this is documented in the overview; the visible portion of the README stops inside the install options.

## The install scripts choose a compiler for your CUDA toolkit

Five CUDA versions are supported, 11.8, 12.4, 12.6, 12.8 as the default and 13.0 marked experimental, and the documentation states that the install scripts automatically find or install a GCC version compatible with whichever one you chose. A script that installs a compiler needs privileges and writes outside the project directory, which is a heavier operation than resolving Python packages. The container takes the default and pins it exactly, passing CUDA_VERSION 12.8.1 and UBUNTU_VERSION 24.04 as build arguments to a CUDA devel base image, and both Linux and Windows are covered by paired scripts, install_env_uv.sh and install_env_uv.ps1, which is why the clone command carries the recursive flag and why a gitmodules file sits in the root. The package itself requires Python 3.11 or newer and pins its build backend to an exact setuptools version. The clone step is where the recursive flag earns its place:

```bash
git clone --recursive https://github.com/nv-tlabs/3dgrut.git
cd 3dgrut
```

## The authors recommend a different repository for production use

The introduction names two formulations and then a third. 3DGRT traces rays through volumetric Gaussian particles instead of splatting, which is what lets it handle distorted cameras with rolling shutters and secondary rays for reflection, refraction and shadows, at the cost of needing dedicated ray tracing hardware and being slower than 3DGS. 3DGUT keeps the same distorted camera support inside a rasterization framework. 3DGRUT is the hybrid, rasterizing primary rays and tracing secondary ones. Alongside that, the text points readers to gsplat for anyone who wants a fast, modular, production-ready framework, and notes that gsplat also provides 3DGUT support. So the feature that distinguishes this repository is available elsewhere, named by its own authors as the better fit once production matters.

## Vulkan support was announced as coming soon and never reappears

The 2025/08 changelog entry says support for the 3DGRT and 3DGS/3DGRT pipelines became available with the Vulkan API as part of a separate project, the Vulkan Gaussian Splatting repository under the nvpro-samples organisation. It adds that 3DGUT will also be available soon. No later entry records that arrival, and nothing after 2025/08 in the news list mentions Vulkan again, so the rasterized formulation that is the point of 3DGUT is the one still outstanding, and it is outstanding in someone else's repository rather than this one. The remaining entries are feature adds and one release tag: multi-sensor datasets limited to COLMAP style, Windows, playground support for PBR meshes and environment maps, image masks, SparseAdam, MCMC densification, and the v1.0.0 tag in 2025/04.

## Two experiment trackers and two config frameworks are both required

The dependency list is unconditional rather than optional, and it carries overlapping tools. Both wandb and tensorboard appear, so two experiment trackers are installed whether you use either. Both hydra-core and fire appear alongside omegaconf, which is three ways of handling configuration and command line parsing in one package. torchmetrics, rich, pytest, tensorboard and wandb all ship as runtime requirements rather than development extras, and the optional dependency group is separate. NVIDIA's own ncore package is a hard requirement at version 19.0.0 or newer, matching the 2026/03 entry about training from NCore v4 datasets, so a dataset tool from the same vendor is a required install rather than an optional extra. install_env_uv.sh, listed in both the documentation and the Dockerfile, runs the same resolution.

## Conclusion

This is the implementation to read if you want the papers' formulations rather than a supported product, and the authors themselves point elsewhere for production work. Two things to settle before you build. The version story is inconsistent across the manifest, the changelog and the tag list, so pin a commit rather than a tag, and do not assume a tagged release carries the code the news section describes. Second, the USD export path exists only on Linux on x86_64, which rules it out on the Windows support added in July 2025 and on Apple silicon. Check the tracer directory you are importing from, since the two tracer packages are named one letter apart.

## FAQ

### Does 3DGRUT need ray tracing hardware?

The 3DGRT path does. The documentation recommends an NVIDIA GPU with ray tracing cores for good performance with 3DGRT and states that it remains slower than 3DGS. 3DGUT is the rasterization alternative for the same distorted camera support.

### Which CUDA versions does 3DGRUT support?

11.8, 12.4, 12.6, 12.8 as the default, and 13.0 marked experimental. The container build pins 12.8.1 on an Ubuntu 24.04 base image, matching that default.

### Can 3DGRUT export a trained scene to USD on Windows?

Not through the package dependencies. The usd-core dependency carries a marker restricting it to Linux on x86_64, and the package declares itself operating system independent, so on Windows the USD path is not installed while PLY and NuRec remain.

### What is the difference between 3DGRT, 3DGUT and 3DGRUT?

3DGRT ray traces volumetric Gaussian particles for distorted cameras and secondary rays. 3DGUT keeps that camera support inside a rasterization framework. 3DGRUT is the hybrid, rasterizing primary rays and tracing secondary ones.

### Which papers does the 3DGRUT repository implement?

Three. 3D Gaussian Ray Tracing from SIGGRAPH Asia 2024 in the journal track, 3DGUT from CVPR 2025 as an oral, and Neural Harmonic Textures on primitive based neural reconstruction from arXiv 2026.

## Sources

- [Issues](https://github.com/nv-tlabs/3dgrut/issues)
- [License: Apache-2.0](https://github.com/nv-tlabs/3dgrut/blob/main/LICENSE)
- [nv-tlabs/3dgrut on GitHub](https://github.com/nv-tlabs/3dgrut)
- [README](https://github.com/nv-tlabs/3dgrut/blob/main/README.md)
- [Releases](https://github.com/nv-tlabs/3dgrut/releases)

---

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