Infinigen Indoors: Procedural Indoor Scenes

• Infinigen Indoors is a procedural system that generates photorealistic indoor scenes defined by a comprehensive asset library and constraint-based layout solver.
• The system employs a procedural asset library with 79 object and 30 material generators to synthesize diverse indoor elements from furniture to architectural components.
• Utilizing hierarchical solving and simulated annealing, it optimizes floor plans, room arrangements, and object placements to meet ergonomic and semantic constraints.

Searching arXiv for the cited papers to ground the article in the current literature. Infinigen Indoors is a Blender-based, fully procedural system for generating photorealistic indoor 3D scenes. It extends the original Infinigen framework from natural scenes to houses, apartments, warehouses, and other indoor environments, while introducing a procedural indoor asset library, a constraint-based arrangement system, and export pathways to real-time simulators. In subsequent work, ProcFunc presents a new indoor room generator as a practical, efficient, compositional alternative to the existing Infinigen Indoors pipeline, while also reusing and refactoring parts of Infinigen Indoors (Raistrick et al., 2024, Raistrick et al., 29 Apr 2026).

1. Origins and scope

Infinigen Indoors emerged as an extension of the original Infinigen system, which focused on natural scenes such as terrain, plants, animals, and other outdoor assets. The indoor extension preserves the original commitment to fully procedural generation and infinite variety, but targets domains in which scene organization is more regular and semantically constrained. The stated scope includes furniture, architecture elements, appliances, and day-to-day objects, together with room layouts and building-scale structure (Raistrick et al., 2024).

The extension from natural scenes to indoor scenes involves several shifts. It moves from natural assets to indoor assets; from unconstrained nature to structured interiors; from object generation only to scene-level generation; and from static placement to constraint-based arrangement. The system is described as generating both objects and whole multiroom / multistory building layouts. A central claim is that everything is 100% procedural, with no external assets used (Raistrick et al., 2024).

This framing is important because indoor environments impose requirements that differ from outdoor procedural synthesis. The relevant constraints include ergonomics, accessibility, stability, symmetry, and room-function constraints. In that sense, Infinigen Indoors is not merely an enlarged asset library; it is a procedural scene synthesis system whose semantics are expressed at the level of object relations and room structure (Raistrick et al., 2024).

2. Procedural asset library

The procedural asset library is one of the system’s three major pillars. The paper states that the library contains 79 randomized procedural object generators and 30 procedural material generators, with approximately 40k lines of code total, including 25k for object/material generators. These generators are compact probabilistic programs whose parameters are randomized by default but overrideable by the user (Raistrick et al., 2024).

The object generators are organized into five categories:

Category	Count	Parameters
Appliances	10 generators	112 params
Windows / Doors / Staircases	14 generators	127 params
Furniture	17 generators	216 params
Decorations	15 generators	92 params
Small Objects	19 generators	194 params

The material library comprises 30 generators with 120 parameters total, roughly evenly split across wood, ceramic, fabric, metal, and others. The paper states that these materials cover 78% of OpenSurfaces material categories, compared to 21% in original Infinigen (Raistrick et al., 2024).

The coverage of the asset library is broad. It includes household appliances such as fridge, beverage fridge, dishwasher, microwave, oven, stove, oven+stove, TV, monitor, and kitchen sink; bathroom fixtures such as bathroom sink, bathtub, hardware, and toilets; clothes such as pants, shirts, and blankets/towels; architectural elements such as doors and casings, staircases, rugs, warehouse racks and pallets, and windows; seating and furniture such as bar stools, office chairs, armchairs, dining chairs, side chairs, upholstered chairs, beds, sofas, tables, desks, dining tables, kitchen tables, shelves, cabinets, wall shelves, bookcases, and triangle shelves; table decorations and small objects such as books, vases, aquariums, plants in pots, bottles, jars, utensils, bowls, plates, cups, wineglasses, food containers, food bags, pots, pans, and lids; and wall decorations such as balloons, wall art, and mirrors (Raistrick et al., 2024).

Asset construction is performed from scratch using Blender procedures including geometry nodes, modifiers, mesh manipulations, array repetition for staircase components, boolean operations for doors/windows, soft-body simulation for blankets, clothing, and pillows, and cloth simulation for balloons and packaging inflation. The paper also highlights a combined text-and-shape logo generator for packaging, fabrics, and art decor (Raistrick et al., 2024).

3. Constraint specification and arrangement semantics

Infinigen Indoors treats indoor scene synthesis as a constrained optimization problem rather than as unconstrained sampling. Indoor scenes are generated at multiple levels, including floor plan generation, room arrangement, large/medium/small object placement, material and fixture placement, and camera and lighting placement. The system’s central argument is that indoor scenes require structured relations such as chairs around tables, TVs facing sofas, objects not blocking doors, vases not overhanging surfaces, books on shelves, and accessibility in front of appliances (Raistrick et al., 2024).

To express these relations, the system introduces a Python-based domain-specific language. The DSL does not encode how to arrange objects; it encodes what the scene should satisfy. Each constraint is represented as a compute graph composed of geometric operations, set filtering, arithmetic operations, logical comparisons, and aggregation operators (Raistrick et al., 2024).

The API includes with_semantics(...), related_to(...), scene, StableAgainst, SupportedBy, count(), area, volume, min_distance, angle_alignment_cost, rotation_asymmetry, reflection_asymmetry, accessibility_cost, focus_score, and freespace_2d. It also supports arithmetic operations such as +, -, *, /, pow, and hinge; comparisons such as ==, <, <=, and in_range; and aggregation operators such as all, sum, and mean (Raistrick et al., 2024).

The paper presents this DSL as more expressive than earlier layout systems because it supports high-level semantic constraints, compositional constraints, constraints over abstract categories, constraints that depend on context, and direct interaction with procedurally generated assets, including changing asset parameters like table size. The distinction from methods that only learn object-position distributions or static-scene priors is therefore explicit (Raistrick et al., 2024).

Typical examples include placing chairs symmetrically around a table, placing plant pots close to windows, keeping equal numbers of knives and forks, ensuring vases do not overhang, leaving free space in front of appliances, and placing glassware only on shelves against a dining-room wall. The paper notes that a typical residential program may include around 105 total hard and soft constraints and about 15 lines of Python per room type for a custom setup (Raistrick et al., 2024).

4. Solver architecture and mathematical formulation

The arrangement solver searches for a composition that maximally satisfies the provided constraints. The paper states that it uses simulated annealing with Metropolis-Hastings acceptance. Given current state $s$ and proposed state $s'$, with losses $l(s)$ and $l(s')$, the acceptance probability is

$$p(s' \mid s) = \min \left[\exp\left(\frac{l(s)-l(s')}{\tau}\right), 1\right]$$

where $\tau$ is the temperature, cooling exponentially from 0.25 to 0.001 (Raistrick et al., 2024).

The move set combines discrete and continuous modifications: Addition, Deletion, Relation Plane Change, Resample, Reinitialize Pose, Translate, and Rotate. The solver uses a move schedule in which discrete moves matter more early on, while continuous moves become more important later in cluttered scenes (Raistrick et al., 2024).

Because joint optimization over all objects is intractable, the system uses hierarchical solving. The sequence is: floor plans / whole-house layout, large objects, medium objects, and small objects. The paper explicitly notes that this greedy decomposition is not guaranteed optimal, but is effective and computationally feasible (Raistrick et al., 2024).

A notable design choice is that object motion is restricted to the degrees of freedom implied by its relations. A painting against a wall can move only along the wall plane; a shelf against the floor and wall moves in a constrained subspace; rotation axes are similarly constrained. This reduces the search space and helps preserve hard constraints (Raistrick et al., 2024).

The appendix defines several scoring terms used in constraint evaluation. For angle alignment cost, the formulation is

$\sum_i \frac{1-\cos\theta_i}{2}$

where $\theta_i$ is the angular difference between an object’s front-facing normal and the inward normal of the closest edge of the reference object on the XY plane. The focus score is given by

$$\sum_{a \in A} \frac{1 - \vec{n}_a \cdot (\vec{b}_c - \vec{a}_c)}{2\|\vec{b}_c - \vec{a}_c\|}$$

with $\vec{n}_a$ the front-facing normal of object $s'$0, and $s'$1, $s'$2 the centroids of source and target objects. Reflection symmetry is computed by selecting a reflection plane, reflecting positions and orientations, performing bipartite matching with a modified Jonker-Volgenant algorithm, and normalizing weighted deviations into an asymmetry score. Accessibility cost is defined in fast and slow versions, respectively based on centroids and closest mesh points, and rises when the blocker is larger, closer, or more directly in front of the target plane (Raistrick et al., 2024).

5. Floor plans, buildings, and export to simulation

Infinigen Indoors includes a floor-plan solver for multi-room, multi-floor homes. The room adjacency graph is created using a probabilistic context-free grammar (PCFG). Supported room types include kitchen, bedroom, living room, closet, hallway, bathroom, garage, balcony, dining room, utility, and staircase (Raistrick et al., 2024).

The grammar begins from a living room and expands rooms according to probabilistic child-room rules. Hard constraints require correct room adjacency, bathroom privacy, planarity, required room counts, and staircase placement consistency across floors. Initialization proceeds by estimating total contour area from typical room sizes, generating a random house outline, beveling corners for variety, subdividing the contour using a Mondrian process, merging or splitting blocks until the room graph cardinality matches, checking adjacency and exterior access, and placing a staircase placeholder for multistory homes (Raistrick et al., 2024).

The floor-plan objective is a weighted combination of 12 terms, including shortest path to entrance, typical room area, room aspect ratio, room convexity, room wall conciseness, functional room area, room collinearity, narrow passages, exterior length by room, exterior corners by room, staircase occupancy, and staircase IOU with rooms. This indicates that building structure is optimized with both geometric regularity and functional priors in view (Raistrick et al., 2024).

A major systems contribution is a one-click export tool for real-time simulation. Supported targets are Universal Scene Description (USD), textured OBJ, FBX, STL, and URDF for collision and articulation. Because Blender materials are not always portable, the export process automatically UV-maps, performs texture baking, converts procedural materials to standard texture maps, and exports collision and articulation metadata (Raistrick et al., 2024).

The simulators mentioned are NVIDIA Omniverse Isaac Sim and Unreal Engine 5. The paper reports that scenes can run at interactive rates: 60 FPS in Unreal and 50 FPS in Isaac Sim with physics on RTX 4090s. The intended uses include embodied-agent training, reinforcement learning, domain randomization, and simulation-based robotics tasks (Raistrick et al., 2024).

6. Evaluation, limitations, and relation to ProcFunc

The reported evaluation includes perceptual, systems, and downstream-learning evidence. In a perceptual study against ProcTHOR, ATISS, SceneFormer, and FastSynth, crowd workers judged overall realism, layout realism, and error frequency; Infinigen Indoors scored best in the reported table, with lower error frequency and higher preference rates. In solver ablations, the optimized solver is reported as about 3× faster than the non-optimized version, with caching and plane hashing identified as the main speed contributors, and longer runs with the full optimized system yielding about a 28% score increase (Raistrick et al., 2024).

The synthetic-data experiments include 2k shadow / shadow-free pairs for shadow removal, improving zero-shot generalization on SRD, and 1464 labeled images for occlusion boundary estimation, where training on Infinigen Indoors yields better ODS, OIS, and mAP than Hypersim or Infinigen-Nature. These results support the claim that the scenes are useful not only as visual content but also as supervised training data (Raistrick et al., 2024).

The paper also implies several limitations. The solver is greedy and not globally optimal; customization depends on user-written constraint programs; layout realism may depend on asset and lighting quality as well as arrangement quality; some hard subproblems are handled heuristically, including SAT-like relation assignment and floor-plan optimization; and the system still requires careful procedural design of assets and constraints (Raistrick et al., 2024).

Later work positions ProcFunc as both a replacement/improvement in programming interface over Infinigen-style tooling and an enabling layer for new indoor generation systems. ProcFunc introduces 497 Python functions and argues that procedural generation should use atomic Python functions with explicit arguments, explicit return values, runtime assertions, type annotations, and standardized interfaces. As an indoor application, it develops a new room generator with room geometry built from scratch, compositional wall/window openings, furniture and scene objects, and a large library of compositional procedural materials divided into 22 semantic classes. The room scenes are built from pre-generated small Infinigen-Indoors assets plus samples from 15 storage/larger object generators that were refactored to ProcFunc interfaces (Raistrick et al., 29 Apr 2026).

The comparison is consequential for understanding Infinigen Indoors’ position in the literature. ProcFunc explicitly states that the new system does not replace all of Infinigen Indoors; rather, it reuses and refactors parts of it while adding new compositional structure. It reports markedly lower scene CPU time and lower memory and storage in several room-generation configurations, while also noting that Infinigen Indoors may still cover a broader variety of room types. This suggests that Infinigen Indoors remains significant as the broader procedural indoor framework, whereas ProcFunc emphasizes a more Python-native, static, and traceable programming model for an indoor generator with strong efficiency and compositionality properties (Raistrick et al., 29 Apr 2026).