3dgrut: ray tracing Gaussian particles and rasterizing distorted cameras
Ray tracing and hybrid rasterization of Gaussian particles
At a glance
- What is it?
- NVIDIA's 3DGRUT combines 3DGRT, which ray traces Gaussian particles, with 3DGUT, which makes rasterization work with distorted and rolling-shutter cameras. Here is what the repository actually ships, how to install it, and where it stops being the right tool.
- Who is it for?
- Adopt 3dgrut if you need secondary rays for reflections, refractions or shadows, or if your capture uses fisheye, rolling shutter or other distorted camera models, and you have an RT-capable NVIDIA GPU. Skip it if you want a plain fast 3DGS pipeline, since the README itself points production users at gsplat.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem 3dgrut was built to solve
Standard 3D Gaussian Splatting rasterizes primaries by projecting each Gaussian onto the image plane. That projection assumes a camera model you can invert analytically. Feed it a fisheye lens, a rolling shutter, or a sensor whose distortion changes over the exposure, and the projection math stops matching what the camera actually recorded. The same projection step also gives you no natural way to ask for a reflection, a refraction or a shadow, because those need rays that start somewhere other than the camera.
3dgrut attacks both problems from two directions. The 3DGRT half traces rays through volumetric Gaussian particles instead of splatting them, which is what makes distorted cameras and secondary rays tractable. The README is blunt about the cost: 3DGRT "requires dedicated ray-tracing hardware and remains slower than 3DGS." The 3DGUT half takes the other route, keeping rasterization but changing the rendering formulation so distorted cameras and time-dependent effects work inside it. The hybrid, 3DGRUT, renders primary rays by rasterization and secondary rays by ray tracing.
The intended reader is a graphics or vision engineer with an NVIDIA RTX-class GPU who is reconstructing scenes from real captures, not a team that just wants a fast splat viewer. The repository is also explicit that if you want a "fast, modular, and production-ready Gaussian Splatting framework," you should use gsplat instead. That sentence, in the project's own README, sets the boundary of who this is for.
How the ray tracing and rasterization paths fit together
The repository layout mirrors the split. There are separate top-level directories for threedgrt_tracer, threedgut_tracer and threedgrut, plus a threedgrut_playground for the interactive GUI. The tracer directories hold the two rendering backends; the shared package holds training, configuration and export logic that both paths consume.
Configuration lives in configs/ and is driven by Hydra and OmegaConf, which is why hydra-core and omegaconf appear in the dependency list. Training, validation and rendering are separate entry points (train.py, validate.py, render.py), so a checkpoint produced by one can be rendered or evaluated by another without re-running training. The playground.py entry point opens the GUI described in the README's section 5.
The dependency list reveals the rest of the data flow. datasets come in through COLMAP-style loaders or the nvidia-ncore package (nvidia-ncore>=19.0.0), image handling uses opencv-python, imageio and simplejpeg, and experiment tracking goes to tensorboard or wandb. Export to USD relies on usd-core, which the pyproject marks as linux and x86_64 only, so USD export is not available on every platform the project otherwise supports.
A detail worth noticing: slangtorch appears in pyproject.toml only as a commented-out line, annotated "slangtorch on amd64 only." If you are building on a non-amd64 Linux machine, expect that shader compilation path to be absent rather than broken.
Installing 3dgrut with the UV scripts
The README documents two install routes: UV scripts and Docker. The UV route is the primary one. Clone with submodules, because the tracer code depends on thirdparty/ content, then run the platform install script.
git clone --recursive https://github.com/nv-tlabs/3dgrut.git
cd 3dgrutBefore running the script you need uv itself and a CUDA toolkit. The README lists supported CUDA versions as 11.8, 12.4, 12.6, 12.8 (default) and 13.0 (experimental). The install script for Linux "automatically find[s] or install[s] a GCC version compatible with your chosen CUDA toolkit," which removes the usual GCC-versus-nvcc mismatch. Install uv first if you do not have it:
curl -LsSf https://astral.sh/uv/install.sh | shThen run the Linux install script from the repository root:
bash ./install_env_uv.shWindows users have install_env_uv.ps1 instead; the README states Windows support was added in July 2025. After the script completes, the environment lives in .venv, and the Dockerfile appends the matching activation line to ~/.bashrc, so activating the venv is the expected next step.
For a container build, the Dockerfile defaults to CUDA 12.8.1 on Ubuntu 24.04 and runs the same install script inside the image:
ARG CUDA_VERSION=12.8.1
FROM nvidia/cuda:${CUDA_VERSION}-devel-ubuntu${UBUNTU_VERSION}
ENV EGL_PLATFORM=surfaceless
RUN bash ./install_env_uv.shThe EGL_PLATFORM=surfaceless setting matters for headless rendering, and the image declares NVIDIA_DRIVER_CAPABILITIES=graphics,compute,utility so both rasterization and ray tracing have what they need. A first real use is training on a COLMAP-style dataset through train.py, with the dataset and run configuration supplied as Hydra overrides; the README's section 2 is where the exact config names live, and they should be read there rather than guessed.
Where 3dgrut is the wrong tool
The clearest limitation is stated by the project itself: 3DGRT is slower than 3DGS and needs ray-tracing hardware. If your GPU lacks RT cores, the ray tracing path is off the table, and the README recommends an RT-capable NVIDIA GPU "for good performance with 3DGRT." That is a hardware gate, not a tuning problem.
The second limitation is platform and build surface. CUDA 13.0 is labelled experimental, slangtorch is commented out for non-amd64, and usd-core is restricted to linux x86_64. A team on ARM Linux or on a CUDA version outside the supported list is doing integration work the project has not committed to supporting.
The third is scope. The README's own recommendation points anyone wanting a production-ready splatting framework to gsplat. If your captures come from a conventional pinhole camera and you never need reflections or shadows, the extra machinery here buys you nothing and costs you install complexity. Similarly, if you need a mature ecosystem of viewers, editors and downstream converters, a research release with a handful of export formats is a narrower base than a framework built around that ecosystem.
Finally, the README does not document a rollback path or a compatibility matrix between checkpoint versions. A checkpoint trained under one release is not guaranteed to load under another; the CHANGELOG.md is the place to check before upgrading a long-running experiment.
gsplat, and the actual difference in approach
The README names gsplat as the recommended alternative for teams that want "a fast, modular, and production-ready Gaussian Splatting framework," and notes that gsplat also provides 3DGUT support. That last clause is the important one: the distorted-camera capability from the CVPR 2025 paper is not exclusive to this repository.
The difference is in the rendering backend. gsplat is built around rasterization as the primary path, and its 3DGUT support extends that rasterizer to distorted cameras. 3dgrut ships both a rasterizer (3DGUT) and a ray tracer (3DGRT) and can mix them in one render, using rasterization for primary rays and ray tracing for secondary ones. If you need reflections, refractions or shadows from Gaussian particles, that hybrid is the thing gsplat does not replace. If you only need distorted-camera support, gsplat's 3DGUT path covers the same ground with a smaller dependency footprint.
A second alternative lives in the same family: the README notes that support for the 3DGRT and 3DGS/3DGRT pipelines is available through the Vulkan API as part of the Vulkan Gaussian Splatting Project, with 3DGUT "also available soon." That is a different integration surface entirely, aimed at applications already built on Vulkan rather than Python training scripts.
So the choice is not which project is better. It is whether secondary-ray rendering is part of your requirement. If it is, 3dgrut is the repository that ships it. If it is not, the README is telling you to look elsewhere.
Maintenance, versions and the Apache-2.0 licence
The repository is not archived, and its last push was on 2026-09-01, which is recent. Releases are tagged rather than continuous: v1.0.0 landed on 2025-04-03 as the first stable release, and v1.1.0 followed on 2026-06-10 as a stable code release. The pyproject.toml declares version 2.0.0, which corresponds to the June 2026 news entry about Neural Harmonic Textures support, so the version string in the package metadata runs ahead of the most recent release tag. Anyone pinning dependencies should decide which of those two numbers they mean.
The upgrade cost is dominated by the CUDA and compiler stack rather than by Python. The install scripts pin a GCC version to the chosen CUDA toolkit, and the default CUDA in the Dockerfile is 12.8.1. Moving CUDA versions means re-running the install script and rebuilding the tracer code, not just bumping a Python requirement. The CHANGELOG.md at the repository root is the file to read before an upgrade.
Licensing is Apache-2.0, declared in the LICENSE file and repeated in the SPDX headers across pyproject.toml, setup.py and the Dockerfile. That permits commercial use and modification, with the usual obligations around notices and attribution. It is worth noting that the repository also carries an ATTRIBUTIONS.md, and that the thirdparty/ directory contains vendored code with its own terms. Apache-2.0 on the top-level project does not automatically relicense what sits in thirdparty/, so a legal review of that directory is the practical next step for commercial deployment. This is not legal advice.
Editorial conclusion
Adopt 3dgrut if you need secondary rays for reflections, refractions or shadows, or if your capture uses fisheye, rolling shutter or other distorted camera models, and you have an RT-capable NVIDIA GPU. Skip it if you want a plain fast 3DGS pipeline, since the README itself points production users at gsplat. Before committing, verify your CUDA version against the supported list (11.8, 12.4, 12.6, 12.8, 13.0 experimental), confirm your GPU has RT cores for the 3DGRT path, and check whether the export formats you need are covered by the transcoding documentation in threedgrut/export/README.md.
Frequently asked questions
What is 3D Gaussian splatting?
It is a scene representation in which a scene is stored as a set of 3D Gaussian particles that are projected and blended to form an image. 3dgrut is built on this representation but replaces the projection step with ray tracing in its 3DGRT path, and adapts the rasterization formulation in its 3DGUT path.
What is the best software for creating Gaussian splats?
The 3dgrut README does not position this repository as a general splat creation tool. It recommends gsplat for projects that need a fast, modular and production-ready Gaussian Splatting framework, and describes 3dgrut as the official implementation of 3DGRT and 3DGUT aimed at ray tracing and distorted cameras.
How do I install 3dgrut on Windows?
The repository ships install_env_uv.ps1 alongside the Linux install_env_uv.sh script, and the README states that Windows support was added in July 2025. Both are UV-based installs, so uv and a supported CUDA toolkit are prerequisites.
Does 3dgrut require an NVIDIA GPU with ray tracing cores?
For the 3DGRT path, the README recommends an NVIDIA GPU with ray tracing cores for good performance and states that 3DGRT requires dedicated ray-tracing hardware. The 3DGUT path is rasterization based, and the README describes 3DGRUT as a hybrid that rasterizes primary rays and ray traces secondary rays.
Which CUDA versions does 3dgrut support?
The README lists CUDA 11.8, 12.4, 12.6, 12.8 (default) and 13.0 (experimental) as supported versions. The Dockerfile defaults to CUDA 12.8.1 on Ubuntu 24.04.
Community notes