EDGS: 3D Gaussian splatting without densification, from CVPR 2026

Densification is the step EDGS removes

The paper behind this repository is titled EDGS: Eliminating Densification for Efficient Convergence of 3DGS, and it was accepted to CVPR 2026. The authors are Dmytro Kotovenko and Olga Grebenkova, with equal contribution, and Björn Ommer, from CompVis at LMU Munich and the Munich Center for Machine Learning.

The contrast the paper draws is with how 3D Gaussian splatting normally starts. Standard 3DGS initializes with a sparse set of Gaussians and progressively adds more in under-reconstructed regions, and that progressive addition is the densification step. EDGS instead starts from a dense initialization built out of triangulated 2D correspondences across training image pairs, and then requires only minimal refinement.

The reported consequences are specific numbers rather than adjectives. The method reaches the original 3DGS LPIPS score in 25% of the training time, and it uses only 60% of the splats. Renderings become nearly indistinguishable from ground truth after 3,000 steps, and the documentation is explicit that this happens without any densification at all.

The practical reading is that the sparse-start, grow-the-model pattern is the expensive part of vanilla 3DGS, and that a better initialisation makes the growth machinery unnecessary. Whether that trade holds on your own scenes is an empirical question, but the mechanism is legible enough to reason about.

The training run is one command with densification switched off

Optimising a single scene in COLMAP format is a single command with a Hydra-style argument list:

python train.py \
  train.gs_epochs=30000 \
  train.no_densify=True \
  gs.dataset.source_path=<scene folder> \
  gs.dataset.model_path=<output folder> \
  init_wC.matches_per_ref=20000 \
  init_wC.nns_per_ref=3 \
  init_wC.num_refs=180

The argument list shows the structure of the method. The gs_epochs value sets the number of training iterations for Gaussian splatting, and no_densify disables densification, which the documentation notes is true by default. The dataset paths point at the input directory and the output directory where the trained model, logs and renderings are written.

The three init_wC parameters are the dense initialisation, and they are where the difference from vanilla 3DGS lives. matches_per_ref=20000 sets how many matches are kept per reference view, nns_per_ref=3 sets the number of nearest neighbours per reference, and num_refs=180 sets how many reference views are used. These are the numbers that control how much geometry you start with, and they are the parameters to explore when you change scene type.

The top-level layout matches the argument names. train.py is the entry point, configs/ holds the configuration tree that hydra-core consumes, source/ holds the implementation, metrics.py handles evaluation, full_eval.py runs the full evaluation, and notebooks/ contains the Colab notebook version of the flow. The submodules/ directory carries the external pieces the method builds on, including the gaussian-splatting and RoMa submodules.

Install is a fixed conda recipe, not a pip package

There is no package to install. The documentation offers install.sh or a manual sequence, and the manual sequence pins almost everything:

git clone [email protected]:CompVis/EDGS.git --recursive
cd EDGS
conda create -y -n edgs python=3.10 pip
conda activate edgs
export CUDA_HOME=/usr/local/cuda-12.1
export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH
export PATH=$CUDA_HOME/bin:$PATH
conda install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia -y
conda install nvidia/label/cuda-12.1.0::cuda-toolkit -y
pip install -e submodules/gaussian-splatting/submodules/diff-gaussian-rasterization
pip install -e submodules/gaussian-splatting/submodules/simple-knn
pip install pycolmap

The clone has to be recursive, and the submodules are then initialised separately, because the rasterisation and nearest-neighbour kernels are compiled from source as editable installs. The CUDA version is 12.1, with a note that similar versions such as 12.2 also work well in the authors' experience. Python is 3.10.

The rest of the dependency list covers the toolchain the training loop expects: hydra-core for the configuration system, wandb for experiment tracking, torchmetrics and lpips for evaluation, plyfile for the point cloud format, and matplotlib, rich, tqdm, imageio and imageio-ffmpeg for output. numpy is pinned to 1.26.4 with an override of the conda channels, which is the kind of pin that exists because a newer numpy breaks a compiled dependency rather than for style.

On a machine without a suitable NVIDIA GPU, this is a hard stop. There is no CPU fallback mentioned anywhere in the installation instructions.

COLMAP does the geometry work before the model starts

The pipeline needs camera poses and sparse geometry before any training happens, and COLMAP is the tool that provides them. The demo makes the division of labour explicit: the preprocess step estimates 3D positions using COLMAP, and the reconstruction step runs the model.

The data section names the datasets the method was evaluated on, MipNeRF360 and Tanks and Temples plus Deep Blending, and points to the original 3DGS repository for the latter. For your own data, the documentation says to use the same format as the 3DGS project and to follow that project's guide, then shows the expected folder layout:

scene_folder
|---images
|   |---<image 0>
|   |---<image 1>
|   |---...
|---sparse
    |---0
        |---cameras.bin
        |---images.bin
        |---points3D.bin

The sparse/0 subfolder holds the three binary files that a COLMAP reconstruction produces, and Nerf synthetic format is also acceptable. The code provides functions to convert a collection of images or a single video into the desired format, and the documentation is candid about the catch: that conversion can need tweaking and the processing time can be large for a large set of images with little overlap.

That last point is the real constraint on this method. Dense initialisation from triangulated correspondences needs enough overlap between views to triangulate in the first place, which is the same requirement that limits the demo to forward-facing scenes.

A Gradio demo runs a reconstruction in about half a minute

The fastest way to see the method work is the Hugging Face space, where you upload a list of photos or a single video, press a preprocess button to estimate 3D positions with COLMAP, then start the reconstruction and rotate the result in the browser.

The same application runs locally. The launch command pins the first GPU with CUDA_VISIBLE_DEVICES=0, starts gradio_demo.py on port 7862 and passes the no_share flag, written as CUDA_VISIBLE_DEVICES=0 python gradio_demo.py --port 7862 --no_share.

The no_share flag is worth understanding before you use it. With the flag, the app stays local. Without it, the documentation says you get the address for the Gradio app that you can share, allowing others to process their data on your server. On a shared machine that is a meaningful difference, since it makes your GPU available to anyone with the link.

The runtime figures are given as 10 to 20 seconds for EDGS itself, plus 5 to 10 seconds for COLMAP processing, with extra time to save the model, the video and the 3D preview. Those numbers are for the demo configuration and forward-facing scenes, which the documentation names as the only kind currently supported for broad accessibility.

The Colab notebook is the third route, linked from the documentation as fit_model_to_scene_full.ipynb. It is the same flow as the local app and the training command, packaged for a hosted GPU, and it is also the entry point named by the Open in Colab badge.

A research repository with no releases and a licence file to read

This is a paper implementation, and it behaves like one. The repository has no GitHub releases, the project page is hosted separately, and the version is not something you install. The primary language is listed as Jupyter Notebook, which is a clue about how the authors expect people to try it.

The news entries set the timeline. On 2026-03-02 the paper was accepted to CVPR 2026, and on 2026-03-25 the entry reads that updated training code will be released soon. The last push to the main branch was on 2026-07-04, and the repository is not archived.

The licence is the item to check before you build on this. It is a LICENSE.txt at the repository root that GitHub's classifier could not categorise, which means it is a custom licence rather than one of the standard permissive ones, and the file itself is the only place to read the terms. Nothing in the documentation summarises it, and a repository whose licence cannot be automatically identified deserves the two minutes it takes to read rather than an assumption.

The arXiv PDF is 2504.13204, and the project page sits at compvis.github.io/EDGS. For anyone judging whether to adopt this, the paper and the licence file are the two documents to read before the code, and the code is a reasonable way to check whether the claims survive on your own data.

Editorial conclusion

EDGS suits researchers reproducing a CVPR 2026 result or anyone who wants a fast 3D scene reconstruction from a forward-facing photo set and can accept a CUDA workstation with a fixed dependency set. It does not suit production use, since it has no releases, no package on PyPI, a custom LICENSE.txt that GitHub cannot classify, and a last push on 2026-07-04 that left the training code still described as forthcoming in the March news entry. Before running it, work through install.sh on a machine with CUDA 12.1 and a conda environment, check that your scene folder follows the sparse/0 layout with cameras.bin, images.bin and points3D.bin, and keep the no_densify flag set as documented.

Frequently asked questions

Official sources

1. CompVis/EDGS on GitHub
2. Issues
3. Project website
4. README