# Infinigen: procedural photorealistic 3D worlds for computer vision training data

> Infinigen generates photorealistic natural and indoor scenes from code rather than from captured photos. It is a research project from Princeton's Vision and Learning Lab, and its install path is a Blender-bound Python environment, not a pip install.

**princeton-vl/infinigen** — Infinite Photorealistic Worlds using Procedural Generation

- Repository: https://github.com/princeton-vl/infinigen
- Website: https://infinigen.org
- Stars: 7,287 · Forks: 615
- Language: Python
- License: BSD-3-Clause
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/princeton-vl-infinigen

## What Infinigen generates, and why procedural beats captured for some datasets

Infinigen is a procedural generator of photorealistic 3D scenes. Instead of collecting photographs and reconstructing geometry, it writes code that builds a scene from scratch: terrain, plants, materials, rooms, furniture, and the cameras that look at them. The README describes the project as "Infinite Photorealistic Worlds using Procedural Generation", and the accompanying papers (CVPR 2023 for the natural-world work, CVPR 2024 for Infinigen Indoors, and a 2025 paper for Infinigen-Articulated) are cited directly in the README rather than summarized.

The audience is narrow and specific. This is for computer vision researchers and graphics engineers who need training or evaluation data with exact ground truth. The README's Hello World example shows the four outputs that matter: an RGB render, a depth map, a surface normal map, and an instance segmentation map, each derived from the same scene graph rather than estimated after the fact. A captured photo cannot give you a pixel-perfect instance mask; a procedural scene can, because the generator knows which object occupies every pixel before rendering.

The second audience is simulation. The Infinigen-Articulated work generates articulated assets, objects with joints and moving parts, and the README links to an ExportingToSimulators document. That is a different use case from image generation: the output is an asset with kinematics, destined for a physics simulator rather than a training set.

## How the generator is structured: Blender as the runtime, Python as the scene language

The dependency list in pyproject.toml tells you most of the architecture. The first dependency is bpy==4.2.0, the Blender Python module. Infinigen does not implement its own renderer or geometry kernel; it drives Blender. Everything else in the list supports that: numpy and scipy for math, trimesh with python-fcl and rtree for collision and spatial queries, OpenEXR for the high-dynamic-range output passes, and cvdpack, described in a comment as the "v2 ground-truth tool".

That choice has consequences. Python is pinned with requires-python = "==3.11.*", an exact match rather than a floor, because bpy 4.2.0 is built against a specific interpreter ABI. You cannot drop Infinigen into a project running Python 3.12 without changing the environment. The numpy cap (numpy>=1.25,<2) is likewise a known-break boundary, and the comment in the file says so: floors are covered by a compatibility workflow, caps represent known breaks.

Scenes are assembled by composition of Python functions. The repository's src/ tree holds the generator code, examples/ holds runnable entry points such as examples/render_clay_pan_video.py, and scripts/ holds install and utility scripts. The Makefile exposes the optional compiled components separately: terrain, customgt, and flip_fluids each have their own target that shells out to a script under scripts/install/. Those are not part of a default install, which is why the setup.py logic treats a minimal install as the default: INFINIGEN_MINIMAL_INSTALL defaults to "True", and only when it is false does the build run git submodule update --init --recursive.

## Installing Infinigen and generating your first Hello World scene

The README does not put install commands inline. For Infinigen V2 it points to hosted documentation at infinigen.cs.princeton.edu, and for the other scene types it points at branch-specific READMEs: nature-stable for natural scenes, indoors-stable for rooms, and articulated-stable for simulation assets. Read the branch README that matches your target, because the install steps differ between them.

The container path is the most reproducible one and is fully specified in the repository. The Dockerfile builds from continuumio/miniconda3:24.7.1-0 by default, creates a conda environment named infinigen on Python 3.11, and installs the package in editable mode with the dev extra:

```dockerfile
RUN conda init bash && \
    . ~/.bashrc && \
    conda create --name infinigen python=3.11 -y && \
    conda activate infinigen && \
    pip install -e ".[dev]"
```

The Makefile wraps the build and run steps. docker-build tags the image, and docker-build-cuda adds the CUDA base image argument:

```bash
docker build --tag infinigen_docker_img --progress auto .
docker build --tag infinigen_docker_img --build-arg APP_IMAGE=nvidia/cuda:12.0.0-devel-ubuntu22.04 .
```

For a non-container install, the pyproject.toml extras are the map. The base install gives you the generator. The terrain extra pulls in landlab and pyrender and notes that it is a v1 feature; vis adds einops and numba for ground-truth visuals; test adds pytest and pytest-xdist. A source install therefore looks like an editable install with the extras you actually need:

```bash
pip install -e ".[dev]"
```

The repository uses uv.lock, so a uv-based workflow is also present in the tree, though the README does not walk through it. Once the environment is up, the runnable examples live under examples/, and the per-branch README files describe the Hello World, Hello Room and Hello V2 entry points. The Dockerfile mounts $(PWD)/outputs to /opt/infinigen/outputs, so that directory is where rendered results land in the container workflow.

## Where Infinigen is the wrong tool

The first limitation is the alpha. The most recent release is v2.0.0a1, dated 2026-07-15, and its own release title calls it the "First alpha release of 2.0 overhaul". If you build on the v2 API, you are building on something the maintainers have labelled alpha. The README's V2 section sends you to hosted documentation rather than to a stable API reference, which is consistent with that status.

The second is the split across branches. Nature, indoors and articulated each have a -stable branch and an -initial branch, and the README links to all of them. That is a lot of surface area for one project, and it means the answer to "how do I install Infinigen" depends on which of the three you want. A user who follows the main README expecting one install path will not find it there.

The third is the dependency shape. Pinning bpy==4.2.0 and requires-python = "==3.11.*" means Infinigen cannot share an environment with a project that needs a different Python minor version or a newer numpy. This is not a packaging oversight; it is what happens when your renderer is a Blender build. If your pipeline is already on Python 3.12, Infinigen is the wrong component to add to it.

Finally, procedural generation is not free data. A generated scene is only as diverse as the generator's parameter space. The project's claim is about the size of that space, not about matching the statistics of any particular real-world dataset. If your evaluation set is a specific captured dataset, generated scenes are a supplement, not a substitute.

## Infinigen against Kubric and synthetic dataset pipelines

The closest comparison in this space is Kubric, which also produces synthetic scenes with ground-truth annotations for vision research. The difference is in the source of the scene. Kubric assembles scenes from imported 3D assets, so its variety is bounded by the asset library you feed it. Infinigen generates the assets themselves: plants, terrain, furniture and materials are produced by code rather than loaded from a model repository. The README's framing, "Infinite Photorealistic Worlds", is a claim about that generative step.

The trade-off runs the other way too. Imported assets carry the detail of whatever they were scanned or modelled from, and a large asset library can look more varied per scene than a procedural generator whose parameters you have not tuned. Infinigen's output quality depends on how well its procedural rules cover the scene type you care about, which is exactly why the project splits into nature, indoors and articulated branches instead of shipping one universal generator.

If your goal is articulated objects for a physics simulator, the relevant comparison is not Kubric at all but asset libraries of rigged models. Infinigen-Articulated's contribution is that the joints are generated with the geometry rather than authored by hand, and the README links to an ExportingToSimulators document for getting them into a simulator.

## Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-27. Releases are irregular rather than cadenced: v1.17.0 in August 2025, v1.19.0 in November 2025, and v2.0.0a1 in July 2026. The 2.0 line is where current work sits, and it is alpha, so an upgrade from v1 to v2 is a migration rather than a version bump. The pyproject.toml comment about the terrain extra being "a v1 feature" is the clearest signal in the repository that the two lines do not carry the same feature set.

Upgrade cost also comes from the pinned dependencies. Moving to a future bpy release means moving the Python pin with it, and the numpy<2 cap means the upgrade is gated on the project's compatibility work rather than on your schedule. Budget for a rebuild of the environment, not a pip upgrade.

The licence is BSD-3-Clause, declared both in pyproject.toml and in the LICENSE file at the repository root, and each source file carries the header notice. That is a permissive licence, which generally means you can use the output and the code in commercial work provided the copyright notice and disclaimer are retained. Two things to check yourself rather than assume: the setup.py comment notes that optional components including OcMesher, infinigen_gpl and customgt dependencies are cloned manually if needed, and a component named infinigen_gpl is a strong hint that at least one optional piece carries a different licence from the BSD-3-Clause core. Whether that affects your use is a question for your own legal review, not something the README settles.

## Conclusion

Adopt Infinigen if you need paired RGB, depth, surface normal and instance segmentation output for a scene type that no captured dataset covers, and you can afford a Blender 4.2 environment pinned to Python 3.11. Do not adopt it if you need a stable, versioned API for a production pipeline: the 2.0 overhaul is at alpha, and the README points v1 features such as terrain at the infinigen1 extra. Before committing, install the branch that matches your scene type (nature-stable, indoors-stable or articulated-stable), generate one scene end to end, and check that the outputs directory contains the ground-truth passes your training code expects.

## FAQ

### What is Infinigen?

Infinigen is a procedural generator of photorealistic 3D worlds, developed at Princeton and described in the README as "Infinite Photorealistic Worlds using Procedural Generation". It builds scenes in code and renders them through Blender, producing RGB images alongside depth, surface normal and instance segmentation ground truth.

### How do I install and use Infinigen?

The README does not list install commands inline. It points to hosted documentation for Infinigen V2 and to branch-specific READMEs (nature-stable, indoors-stable, articulated-stable) for the other scene types, so the install steps depend on which one you want. The repository also ships a Dockerfile that creates a conda environment named infinigen on Python 3.11 and installs the package with pip install -e ".[dev]".

### Does Infinigen require Blender?

Yes. The first dependency in pyproject.toml is bpy==4.2.0, the Blender Python module, and the Dockerfile installs the OpenGL and GLFW libraries Blender needs. Python is pinned to 3.11 because of that dependency.

### What is the difference between Infinigen 1.x and Infinigen 2.0?

The v2.0.0a1 release is described as the first alpha of a 2.0 overhaul, and the README separates the V2 getting-started path from the older nature, indoors and articulated paths. The pyproject.toml terrain extra is annotated as a v1 feature, which indicates the two lines do not carry identical feature sets.

### What outputs does an Infinigen render produce?

The README's Hello World example shows an RGB image, a depth map, a surface normal map and an instance segmentation map generated from the same scene. The Docker workflow writes results into the mounted outputs directory.

### What licence does Infinigen use?

The project is BSD-3-Clause, declared in pyproject.toml and in the LICENSE file, with the notice repeated in source file headers. Note that setup.py mentions optional components such as infinigen_gpl that are cloned manually, so check the licence of any optional piece you enable.

## Sources

- [License: BSD-3-Clause](https://github.com/princeton-vl/infinigen/blob/main/LICENSE)
- [princeton-vl/infinigen on GitHub](https://github.com/princeton-vl/infinigen)
- [Project website](https://infinigen.org)
- [README](https://github.com/princeton-vl/infinigen/blob/main/README.md)
- [Releases](https://github.com/princeton-vl/infinigen/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/princeton-vl-infinigen