Open-DiffusionGS: a re-implementation of Adobe's Gaussian splatting diffusion work

This is a re-implementation, and the README says so first

The first thing the introduction of this repository does is qualify what it is. The code and checkpoints here are a re-implementation and re-training, and they differ from the original version developed at Adobe. The work itself, Baking Gaussian Splatting into Diffusion Denoiser for Fast and Scalable Single-stage Image-to-3D Generation and Reconstruction, is the paper behind it, published on arXiv with the identifier 2411.14384, and the project is described in the repository description as an ICCV 2025 paper.

That framing matters for anybody reading the numbers in the README. When the authors state that their model is 7.5 times faster than Hunyuan-v2.5, that is a claim about this re-implementation measured by these authors, not a figure taken from the paper, and the paper's own quantitative and qualitative comparisons are shipped as images in the repository rather than as tables you can read. The comparison section of the README is entirely a set of image files: a quantitative table, a qualitative figure, and a hand-built HTML table comparing the Hunyuan model row against their own row.

The project is MIT licensed, written in Python, developed on the master branch, and the repository has no GitHub releases, so the code and the weights move together without a version tag. The last push was on 2026-08-30, and the news list in the README ends in November 2025, so the recent activity is maintenance rather than new features.

For a reader, the useful framing is that this is a research reproduction with a public interface, not a production pipeline with support commitments.

Single-stage, no multi-view diffusion, no depth estimator

The technical claim in the introduction is about what the method does not need. DiffusionGS is single-stage and does not rely on a 2D multi-view diffusion model. It can be applied to single-view 3D object generation with mesh exportation, and to scene reconstruction, without using a depth estimator, in about six seconds according to the README.

Dropping the multi-view model is the significant part of that. Multi-view approaches generate several views of the subject and reconcile them, which multiplies the work and introduces a consistency problem between the views. A single-stage method that goes from one image straight to a 3D representation avoids that whole stage, and a method that also avoids a separate depth estimation pass removes another dependency and another failure mode, since a depth estimate that is wrong corrupts everything built on top of it.

The mesh export is newer. The news list shows mesh exportation code added on 2025-11-20, with a mesh export example on 2025-10-23, and the code and models released on 2025-10-10. Before that, the repository existed as a paper, a project page built on 2024-11-22, and a Hugging Face dataset of prompt images and generation results uploaded on 2024-11-21.

The project also links a Chinese explainer article on Zhihu and a project page with video and interactive generation results, which is where the visual output is meant to be judged. A reader who wants to know what the output looks like should go there rather than to the README, which shows only animated GIFs.

The 24 second versus 180 second comparison is a single model pair

The most quotable numbers in the repository are in the note above the comparison table, and they are worth reading with their limits in view.

The note says the first row is the prompt image, the second row is Hunyuan-v2.5 and the third row is the open-source model, and that the model takes 24 seconds for inference while Hunyuan-v2.5 takes about 180 seconds, making it 7.5 times faster. On training cost, the note says the open-source model takes 16 to 32 GPUs to train and can be applied to scene-level generation, while Hunyuan-v2.5 is much more expensive.

Two things follow. First, the speed ratio comes from comparing inference times of two specific systems, and inference time in a diffusion pipeline depends on the number of denoising steps and the resolution, so the ratio is a property of those two configurations rather than a general property of the method. Second, the training figure is the one that matters more for anyone planning to use the model rather than run it: a system trained on 16 to 32 GPUs is not something you retrain on a workstation, and the README notes that the authors also retrained their model using only the Objaverse dataset.

The table rows in the repository are labelled with the inference times, Hunyuan3D-v2.5 at 180 seconds and DiffusionGS at 24 seconds, and the source of the comparison is the note itself rather than a published benchmark suite. If the difference between 24 and 180 seconds decides your architecture, reproduce it on your own hardware, because the README does not describe the machine, the resolution or the step count behind either figure.

The environment is built around a CUDA toolchain and two compiled submodules

The install instructions are short, which is normal for a research repository, and they reveal the shape of the dependency tree.

The first step creates a conda environment with Python 3.11 and activates it, with two commented-out lines showing the alternative CUDA toolkit and PyTorch install from the nvidia channel:

conda create -n diffusiongs python=3.11 -y
conda activate diffusiongs

The second step installs a pinned PyTorch and torchvision, the repository's own requirements, and then two submodules in editable mode:

pip install torch==2.5.1 torchvision==0.20.1
pip install -r requirements.txt
pip install -e submodules/diff-gaussian-rasterization
pip install -e submodules/simple-knn

The two submodule names tell you what the system is doing. diff-gaussian-rasterization is the rasteriser that turns a set of Gaussian primitives into pixels, and simple-knn is the nearest neighbour search used to find which Gaussians contribute to a pixel. Both are compiled extensions, which is why they are installed from the submodules directory with the editable flag rather than pulled from an index, and it is why the commented-out conda lines for a CUDA toolkit exist: a build of either submodule needs a CUDA toolchain, and a CPU-only machine will not get far.

The repository root lists requirement.txt while the instructions say to install from requirements.txt, and the root also holds a scripts/ directory, so the naming inconsistency is worth checking against the actual file before you run the install.

The practical profile is then clear: a Linux or similar workstation with an NVIDIA GPU, a CUDA toolchain, and a couple of compiled extensions built locally.

The demo is one command, and it fetches the weights for you

For the object-centric image to 3D model, the README gives a single-line script as the quick demo:

python run.py

The code automatically downloads the model checkpoints and the config files from Hugging Face, and the README also points at a manual download from a model repository on Hugging Face, with the option to set it to a local directory. The top-level download_scene_ckpt.py file is the scene checkpoint variant of that step, and launch.py is the training or launch entry point that sits next to it.

Automatic weight download is convenient and it is also the operational risk in this project. The scene checkpoint is fetched from a personal Hugging Face repository rather than from the project's own organisation, so a dependency on someone else's account and hosting is baked into the quick start. If that repository disappears or is renamed, the demo stops working, and pinning a local copy of the weights is the way to insulate yourself from that.

The rest of the root is the data and evaluation path. process_data.py preprocesses a scene dataset into the format the code expects, eval_scene_result.py handles evaluation, and the examp_data/ and extra_files/ directories hold example data and auxiliary files. The core implementation lives in the diffusionGS/ package, with the compiled dependencies under submodules/.

Scene data comes from RealEstate10K, objects from Objaverse

The data preparation section describes two different training paths, and the choice between them changes what the model can do.

For scene-level work, the README points at the RealEstate10K dataset, provided by the pixelSplat project, and asks you to unzip it into a raw data path and then run a preprocessing step:

python process_data.py --base_path YOUR_RAW_DATAPATH --output_dir YOUR_PROCESSED_DATAPATH --mode ['train' or 'test']

The mode argument takes a train or a test value, and the script writes a processed dataset in the format the code reads. RealEstate10K is a dataset of real estate video sequences, which is a sensible source for scene-level reconstruction because it contains camera motion through real indoor and outdoor spaces rather than isolated objects on a turntable.

For object-level work the README says the authors retrained their model using only the Objaverse dataset, which is a different corpus entirely. So the released checkpoints cover two different domains, and the distinction is the reason the repository ships a separate scene checkpoint download script next to the object-centric run.py.

The same pattern applies to the data story: the README is explicit about where each dataset comes from and how to convert it, and it is not explicit about dataset licensing or redistribution terms, so those are questions to raise with the authors if you intend to publish derived work.

Editorial conclusion

Adopt Open-DiffusionGS if you need single-view image to 3D generation or scene reconstruction without a multi-view diffusion model, and you are comfortable with a CUDA-shaped setup that pulls compiled submodules and checkpoints from Hugging Face at runtime. Do not adopt it if you need the exact behaviour of the original Adobe work, because the README is explicit that this is a re-implementation and re-training that differs from it, and the comparison numbers in the repository are the authors' own against one model. Before you plan around the runtime, check the checkpoint host, since the demo downloads weights automatically, and note the requirements file naming differs between the install instructions and the repository root listing.

Frequently asked questions

Official sources

1. caiyuanhao1998/Open-DiffusionGS on GitHub
2. Issues
3. License: MIT
4. Project website
5. README