LiteReality-Agent, RGB-D 스캔을 실행 가능한 3D 장면 프로그램으로 재구성하는 에이전트 시스템
LiteReality-Agent는 실내 RGB-D 스캔을 사실적이고 관절이 있는 시뮬레이션용 3D 장면으로 재구성하는 에이전트 시스템이다. 이 시스템은 재구성을 코딩 문제로 바꿔 Room.py라는 실행 가능한 파이썬 프로그램을 반복적으로 수정하고 검증한다. 10개 실내 장면에서 GPT-6 Astra와 Fable 5.1 같은 최신 프런티어 모델보다 시각 충실도와 기하 정확도가 높았고 물리적 개연성 평가에서도 가장 좋은 결과를 보였다. 이 논문은 arXiv 프리프린트다.
실내 RGB-D 스캔을 상호작용과 물리 시뮬레이션이 가능한 구조화된 3D 디지털 트윈으로 자동 재구성하는 문제를 에이전트 코드 작성 방식으로 해결할 수 있는가?
실내 공간을 시뮬레이션용 디지털 트윈으로 만들려면 구조, 관절, 재질, 물리 속성, 공간 관계를 함께 복원해야 한다. 기존 결정적 파이프라인은 사전 정의된 시나리오를 벗어나면 대처하지 못하고, 일반 대규모 언어 모델 기반 에이전트는 실제 관측에 근거하지 않거나 물리적으로 타당한 배치를 보장하지 못한다.
CAD 모델 검색과 배치, 단일 또는 다중 이미지 기반 3D 생성, 미분 가능 렌더링을 이용한 역렌더링, LiteReality의 결정적 다단계 파이프라인 등이 쓰였다. Holodeck, SceneCraft 같은 언어 기반 장면 생성과 GPT-6 Astra, Fable 5.1 같은 범용 코딩 에이전트도 등장했지만, 실측 스캔에 근거한 검증과 물리적 정합성을 일관되게 보장하지 못했다.
LiteReality-Agent는 전체 방을 실행 가능한 Room.py 프로그램으로 표현한다. 먼저 Scene Initialisation 단계에서 Layout Agent가 스캔에서 얻은 노이즈 있는 객체 배치를 충돌, 지지 관계, 벽 인접성을 기준으로 수정하고, 객체별로 이미지를 생성하거나 TRELLIS.2 또는 Articraft 방식의 절차적 코드를 이용해 정적 및 관절 자산을 만든다. 이후 Agentic Authoring 단계에서 관찰, 편집, 검증 루프를 돌며 select_views, render_and_compare, measurement, stitch_wall, fetch_material 같은 도구로 장면을 다듬고, 충돌과 지지 게이트를 통과시킨다. 최종 장면은 MuJoCo로 내보낼 수 있다.
10개 실내 장면의 620개 캡처 뷰에서 LiteReality-Agent는 SSIM 0.6105, PSNR 14.129dB, RMSE 0.2033, LPIPS 0.5392를 기록해 네 지표 모두 최고였다. 가장 강한 비교 대상인 GPT-6 (+Scan)보다 PSNR은 1.162dB 높았고 LPIPS는 13.7% 낮았으며, LiteReality보다 PSNR은 2.248dB 높고 LPIPS는 19.6% 낮았다. 기하 지표에서는 611개 프레임의 깊이 MAE가 10.50cm로 GPT-6 (+Scan)의 13.33cm보다 21.2% 낮았고, 86개 가구 객체 모두 아래쪽 근접 접촉이 확인됐으며 가구 표면 교차 쌍은 0개였다. 사람 평가에서는 5점 척도에서 배치 정확도 4.60, 객체 유사도 4.58, 전체 유사도 4.54를 얻어 GPT-6 (+Scan)보다 각각 1.49, 1.60, 1.54 높았고, 전체 유사도 기준 65회 짝 비교 중 53승 11무 1패였다.
저자들은 사람 평가 표본이 작고 장면 커버리지가 고르지 않으며 평가가 독립적이지 않아 통계적 유의성을 주장하지 않는다고 밝혔다. 조명도 참조 사진에 독립적으로 보정되지 않았고, 자동 종료 기준이 없어 턴 수와 도구 호출 횟수로 예산을 통제했다. MuJoCo 시연은 흔들기와 Franka pick-and-place 예시만 보여줬을 뿐 로봇 작업 성공률이나 실제 물리 동역학을 측정하지 않았다. 평가는 캡처된 시점에서만 이뤄져 미관측 시점 일반화는 보고되지 않았고, 가구 객체 수가 방법마다 달라 교차 쌍 같은 객체 기반 지표 해석에 주의가 필요하다.
로봇 학습용 실내 시뮬레이션, 제조 디지털 트윈, 가상현실 콘텐츠 제작에 활용할 수 있다. 소스 코드와 데이터 캡처 애플리케이션이 공개돼 있어 연구팀이나 스타트업이 당장 프로토타입에 적용해 볼 수 있다. 다만 상용 로봇 훈련 파이프라인에 쓰려면 10개 장면 이상의 다양한 공간에서 검증하고, 로봇 작업 성공률과 동역학 정합성을 측정하며, 산업용 캡처와 품질 관리 절차가 더 필요하다.
논문 전문
LiteReality-Agent: An Agentic System for Interactable 3D Indoor Scene Reconstruction
CC BY 4.0 라이선스로 공개된 논문입니다. 출처를 밝혀 전재하며, 원문은 arXiv:2610.01863(PDF)에서 볼 수 있습니다.
Abstract
We present LiteReality-Agent, an agentic system for reconstructing real indoor environments as realistic, articulated, and simulation-ready 3D scenes from RGB-D scans. At its core, LiteReality-Agent formulates 3D reconstruction as a coding problem, where a coding agent gathers evidence through designed tools and iteratively edits a Python script, Room.py, which can be executed to produce a 3D digital twin of the room. With this formulation, we build a robust observe-edit-verify harness that supports evidence gathering, measurement, verification, layout optimisation, simulation-readiness, and quality control throughout the reconstruction process. LiteReality-Agent produces high-quality reconstructions suitable for simulation and downstream embodied AI tasks. Furthermore, as agent capabilities continue to improve rapidly, the system introduced by LiteReality-Agent remains a strong orchestration framework for agents: it equips them with specialised tools, structured workflows, and robust verification mechanisms that substantially improve reconstruction quality and reliability. We have demonstrated that LiteReality-Agent produces reconstructions that are more geometrically accurate, visually realistic, and simulation-compatible than those generated by the latest frontier models, such as Astra and Fable. We therefore view LiteReality-Agent as a practical and important building block for robust real-to-sim systems. Both the source code and the data-capture application are publicly available.
†
Figure 1: Reconstructing a real room with LiteReality-Agent. LiteReality-Agent repurposes the reconstruction as a coding task, where a coding agent writes a Room.py file that can be compiled into a realistic, interactive, and simulation-ready 3D room.
1 Introduction
Building a functional, simulation-ready digital twin has long been a holy grail of inverse graphics. Achieving this goal could unlock a range of applications, including robotic simulation, manufacturing digital twins, and virtual reality. Unlike point-based 3D reconstruction methods (Campos et al., 2021; Wang et al., 2025) , or conventional mesh reconstruction methods (Murez et al., 2020; Sun et al., 2021), our goal is to recover a structured environment that can be directly used for interaction and physical simulation (Huang et al., 2025b). This requires jointly understanding the structure of the scene, reconstructing objects and their articulations (Zhou et al., 2026; Li et al., 2026), estimating material and physical properties, and resolving spatial relationships. Integrating these capabilities into a robust end-to-end system remains a longstanding challenge.
Previous work has taken this direction through several approaches. CAD-based scene reconstruction retrieves CAD models and positions them within the scene to form a compact representation (Avetisyan et al., 2019; Kuo et al., 2020; Gao et al., 2024). Compositional 3D reconstruction from single or multiple images instead uses 3D generative models to reconstruct individual objects and place them in the scene (Yao et al., 2025), while inverse-rendering pipelines recover object geometry, orientation, and materials through differentiable rendering (Yan et al., 2023; Yeh et al., 2022). Despite this progress, a gap remains in building a robust and scalable system that can turn large-scale real-world scans into high-quality environments suitable for interaction and physical simulation. LiteReality (Huang et al., 2025b) takes a step toward this goal with a multi-stage pipeline that converts indoor scans into graphics-ready scenes by integrating scene understanding and parsing, asset retrieval, appearance recovery, and assembly into a conventional graphics representation. However, its largely deterministic pipeline limits its ability to handle cases beyond predefined scenarios.
Meanwhile, a growing body of work has explored the use of large language models for 3D scene generation. Systems such as Holodeck (Yang et al., 2024), SceneCraft (Hu et al., 2024), and SceneSmith (Pfaff et al., 2026) employ LLMs to generate and validate scene layouts and object placements, producing simulation-ready indoor environments in graphics engines. At the object level, Articraft (Zhou et al., 2026) formulates articulated asset generation as a programming task supported by a domain-specific SDK and automated verification. More recently, proprietary LLMs such as GPT-6 Astra and Claude Fable 5 further suggest that coding agents have developed strong capabilities for understanding and modelling 3D environments. Together, these advances make the previously daunting problem of functional digital-twin reconstruction increasingly tractable. What remains missing is a system that can orchestrate such agents while grounding their outputs in real-world observations and ensuring that the resulting scenes are consistently high quality and suitable for their intended applications.
To this end, we introduce LiteReality-Agent, a full-stack agentic system for transforming consumer RGB-D room scans into realistic, articulated, and simulation-ready environments. At its core, we formulate reconstruction as a coding task: the entire room is represented as an executable Room.py program that serves as a persistent workspace. A coding agent can access the observations, modify the program, and compile it into a 3D scene. Because all modifications operate through the same executable representation, the scene remains readable, reproducible, and directly editable throughout the reconstruction process.
LiteReality-Agent consists of two stages: Scene Initialisation and Agentic Authoring. Scene Initialisation first reconstructs each object from its corresponding image evidence as either a static or articulated asset. The noisy scan-derived layout and object placements are then processed by the Layout Agent, which resolves collisions, validates object placements and support relationships, and produces a clean, physically plausible scene layout. The resulting scene is instantiated as an initial Room.py file. Agentic Authoring subsequently refines the scene through an observe-edit-verify harness. The agent is equipped with task-specific tools for image selection, rendering and comparison, geometric and metric measurements, and scene editing. Explicit quality-control checks, including collision and support verification, help ensure that the scene remains complete, structured, and physically plausible throughout the authoring process. Physical properties and collision geometry are also estimated by the object reconstruction agents, following a formulation similar to Articraft (Zhou et al., 2026). The resulting environment is simulation-ready and fully programmable through Room.py. Representing the entire scene as an executable Python program also enables downstream editing via natural-language instructions carried out by a coding agent. We demonstrate this capability through scene decoration, object replacement, and layout adjustment.
We rigorously benchmark LiteReality-Agent on diverse real-world indoor scenes against the deterministic LiteReality pipeline and general-purpose coding agents: GPT-6 Astra running in Codex and Fable 5.1 running in Claude Code. Our evaluation combines image-based measures of visual fidelity, geometric measures of reconstruction accuracy and physical plausibility, and human and agent-based perceptual assessments. LiteReality-Agent achieves the highest mean scores across all reported visual metrics and perceptual criteria. These results demonstrate the effectiveness of LiteReality-Agent as an orchestration framework for agentic indoor real-to-simulation reconstruction. Both the source code and the data-capture application are publicly available.
2 Related Work
Indoor Reconstruction and Real-to-Sim.
Object-centric methods retrieve and align CAD assets to observations (Avetisyan et al., 2019; Kuo et al., 2020; Gao et al., 2024), while neural representations recover scene appearance and geometry (Mildenhall et al., 2020; Kerbl et al., 2023; Ni et al., 2025). LiteReality (Huang et al., 2025b) and MetaScenes (Yu et al., 2025) convert scans into asset-based environments. Video2Game (Xia et al., 2024), DRAWER (Xia et al., 2025b), and HoloScene (Xia et al., 2025a) reconstruct interactive worlds from video; DRAWER additionally recovers articulation. FIRE3D (Xia et al., 2026a) predicts compositional scene assets with a feed-forward network. For robot learning, Phone2Proc (Deitke et al., 2023) generates procedural environments from mobile captures, RialTo (Torne et al., 2024) constructs digital twins for policy refinement, and PolaRiS (Jain et al., 2026) reconstructs environments for policy evaluation. ACDC (Dai et al., 2025) instead constructs digital cousins using similar assets.
Object Generation and Articulation.
Image-to-3D methods range from multi-view synthesis (Liu et al., 2023b; Liu et al., 2024; Liu et al., 2023a; Long et al., 2024) to large reconstruction and generative models (Hong et al., 2024; Xu et al., 2024; Xiang et al., 2026; Hunyuan3D et al., 2025; Chen et al., 2026b). CAST (Yao et al., 2025) aligns generated objects into a scene, while URDFormer (Chen et al., 2024) infers articulated simulation environments from images. Real2Code (Mandi et al., 2025) predicts articulation as code; Articulate-Anything (Le et al., 2025) iteratively generates and critiques articulation programs. Articraft (Zhou et al., 2026) couples programmatic asset generation with a specialised SDK and validation harness.
Language-Guided Scene Authoring.
LayoutGPT (Feng et al., 2023) and Holodeck (Yang et al., 2024) generate layouts from language; FirePlace (Huang et al., 2025a) and LayoutVLM (Sun et al., 2025b) refine placement through geometric or visual feedback. 3D-GPT (Sun et al., 2025a), SceneCraft (Hu et al., 2024), and LL3M (Lu et al., 2025) use language models for programmatic 3D authoring. The Scene Language (Zhang et al., 2025) combines programs, words, and embeddings to represent scene structure and appearance. SceneSmith (Pfaff et al., 2026), SAGE (Xia et al., 2026b), and SceneWeaver (Yang et al., 2025) organise agentic scene-generation pipelines. BlenderAlchemy (Huang et al., 2024) explores visually guided editing, and BlenderGym (Gu et al., 2025) benchmarks code-based graphics editing.
Agentic Inverse Graphics.
SceneScript (Avetisyan et al., 2024) and IG-LLM (Kulits et al., 2024) infer structured scene descriptions from visual inputs. VIGA (Yin et al., 2026) iterates through code, rendering, and inspection; Thinking in Blender (He et al., 2026) refines scene factors in executable code from a single image. HARMONY (Sun et al., 2026) combines agentic placement with geometric refinement for monocular scene reconstruction. Agentic Real2Sim (Chen et al., 2026a) uses vision-language agents to assemble physical simulations from interaction videos. The AHa-3D research blog (Xu et al., 2026) describes a closely related workflow for video-to-simulation reconstruction with camera, measurement, and inspection tools. LiteReality-Agent addresses metric RGB-D room reconstruction, combining articulated assets and a persistent scene program with calibrated multi-view verification and explicit collision and support checks.
3 LiteReality-Agent
LiteReality-Agent reconstructs a room in two stages: scene initialisation establishes the layout and major objects, and agentic authoring refines an executable scene program through an observe–edit–verify loop (Fig. 2). Implementation details and supporting examples are provided in Appendix B.
3.1 Input: RGB–D Scans and Detection Results
The input consists of RGB–D scans and detection results from the LiteReality Scan application, including the room layout and object bounding boxes.
3.2 Scene Initialisation
We follow LiteReality (Huang et al., 2025b) in parsing the room shell and reconstructing objects separately before assembly, replacing asset retrieval with generation from the scan’s own images.
Layout Agent.
The layout is represented as a scene graph of structural elements and objects, with relations for support, wall adjacency, functional grouping, and potential clashes. These relations distinguish physical support from association: a chair belongs to a table but rests on the floor. They also distinguish incompatible overlaps from expected box overlap, such as a chair tucked beneath a table.
The Layout Agent corrects noisy detections before object reconstruction. Geometric checks identify objects outside the room, embedded in walls, unsupported, or overlapping incompatibly. Deterministic repairs make small placement and dimension adjustments; image-based reasoning handles ambiguous cases, such as an incorrectly sized or merged detection. Proposals are accepted only when they improve geometric consistency and remain within cumulative limits relative to the scan. The corrected boxes guide both asset generation and final placement, preventing later assembly from restoring the original errors.
Object reconstruction.
For each object, selected capture views are processed by an image-generation model to produce a clean reference image. Structured or articulated objects are routed to procedural generation, while visually complex, predominantly static objects use TRELLIS.2 (Xiang et al., 2026). Generated meshes are checked for malformed geometry, detached fragments, and fused background surfaces. A bounded retry loop for generated chairs regenerates the reference and mesh when these checks fail.
The procedural branch follows Articraft (Zhou et al., 2026): a coding agent writes an object.py program defining geometry, separate moving parts, and joints. We compile physical properties alongside the visual asset, retaining authored values and otherwise estimating mass from category and size, inertia from geometry, and friction from material priors. Convex collision geometry and per-object simulation checks help identify unusable assets before room assembly.
The scene program.
The shell and reconstructed objects are assembled at their corrected scales and poses. Room.py defines the room, object instances, materials, and added geometry, while procedural assets retain their object.py programs. This is the agent’s persistent workspace: edits are written to code and reproduced by rebuilding the scene.
3.3 Agentic Authoring
The second stage observes the capture, edits the scene program, and verifies the result through rendered comparisons and geometric checks. Algorithm 1 summarises the loop, and Table 1 lists its tools.
3.3.1 Evidence Tools
Image selection at three levels.
The agent queries the whole room, one wall, or one object. Room-level selection greedily chooses complementary frames that cover the walls. Wall-level selection ranks views by the wall’s projected on-screen area. Object-level selection uses per-object visibility from the render manifest to find clear views of the target. A minimum frame separation reduces near-duplicate observations. These scopes let the agent move from inspecting the overall layout to checking a local detail.
Rendering and comparison.
The same three levels determine how comparisons are labelled (Fig. A7a–c). Room views label visible objects by name; wall views outline only the selected wall; object views draw its bounding box. Each pair uses the same calibrated camera for the render and photograph. Thus, a room-level mismatch can be traced to a named object or surface and inspected in isolation. Changed scene and object programs are rebuilt before rendering so that comparisons show the current edit.
Wall stitching and measurement.
Capture frames are projected onto a metric wall plane and combined into one head-on reference, selecting visible observations while marking unobserved regions. A grid expresses distance along the wall and height above the floor. For example, the whiteboard in Fig. A8d can be located and sized from its edges relative to the red and blue ticks, then placed using those coordinates in Room.py. Surface queries also pair this rectified reference with an orthographic render for checking materials and fixtures. Raw views remain necessary for objects protruding from the wall. PBR retrieval supplies texture maps whose colour can be adjusted to match the observations.
Authoring harness.
The harness guides four ordered modules: first, matching wall materials; second, adding fixtures and lighting; third, placing small objects; and finally, refining existing procedural assets through multi-view renders of their geometry, appearance, and articulation. Each module builds on the previous result. To keep the scene organised for later editing, added geometry is grouped into named objects with explicit support (rests_on) or attachment (attached_to) relationships. Subsequent agents can then identify and edit objects while accounting for these relationships.
3.3.2 Control and Quality Gates
Budgeted control.
Since Visual quality is hard to set reliable automatic stopping criterion, so we control authoring through a bounded loop with explicit gates. Sessions have turn and tool-call limits. During the final 10\% of calls, exploration and self-checks are disabled so the agent completes and saves its edits. The program is then rebuilt and validated. The budget controls when authoring stops; geometric and support gates determine whether the result passes validation.
Geometric and support gates.
Layout repair uses coarse boxes, so the authored room requires another check on its actual geometry. This is particularly important for chair–table pairs with valid box overlap and for newly added objects. Mesh intersections determine whether a collision exists; convex approximations estimate corrective translations. Bounded corrections move unanchored objects, are saved to Room.py, and are checked again after rebuilding.
Support is checked separately: an object may avoid collisions yet float above its intended surface. We compare object undersides with declared supports, report missing supports or invalid contact heights, and check that articulated assets retain separate moving parts. Unresolved findings return to authoring; checklist-based visual review can provide additional appearance feedback. Table 3 reports support and intersection measurements on the resulting scenes.
3.4 Simulation-Ready Export
We export the room to MuJoCo (Todorov et al., 2012) as individual objects with mass, inertia, collision geometry, and joints. Walls and attached fixtures stay fixed; movable objects have free joints, and articulated parts use hinge or slide joints. Separate collision shapes preserve space beneath tables and inside furniture. The exporter accounts for asset placement and scale, estimating physical properties when needed.
4 Results
We evaluate visual fidelity, geometric consistency, and perceived similarity on ten indoor scenes, comparing LiteReality-Agent with LiteReality and two general-purpose agent baselines.
4.1 Experimental Setup
Scenes, baselines, and inputs.
We evaluate LiteReality-Agent on ten indoor scenes with 620 capture views, comparing against LiteReality (Huang et al., 2025b) and two general-purpose agents: GPT-6 running in Codex and Fable 5.1 running in Claude Code. Each general-purpose agent is evaluated with RGB photographs alone (RGB-only) and with additional geometric observations from LiteReality Scan (+Scan), including depth, camera calibration, a point cloud, and a RoomPlan layout. All methods use the same photographs for each scene; LiteReality and LiteReality-Agent receive the same scan information as the +Scan baselines.
Evaluation protocol.
All reconstructions are aligned to the recorded camera coordinate system without changing scene scale or individual object placements, and rendered at 960\times 720 using the recorded camera poses and intrinsics. We evaluate fidelity at the captured viewpoints rather than held-out novel views. All methods share the lighting and colour-management settings of the corresponding LiteReality-Agent scene while retaining their own materials and textures, including material emission. This lighting is not independently calibrated to the reference photographs. Additional input and evaluation details are provided in Appendix C.
4.2 Visual Fidelity
- LiteReality
- 0.5609
- 11.881
- 0.2635
- 0.6709
- Fable 5.1 (RGB-only)
- 0.5307
- 10.681
- 0.3008
- 0.7197
- Fable 5.1 (+Scan)
- 0.5649
- 12.287
- 0.2506
- 0.6422
- GPT-6 (RGB-only)
- 0.5742
- 11.549
- 0.2694
- 0.6910
- GPT-6 (+Scan)
- 0.6004
- 12.967
- 0.2323
- 0.6250
- LiteReality-Agent (ours)
- 0.6105
- 14.129
- 0.2033
- 0.5392
We evaluate SSIM, PSNR, RMSE, and LPIPS on reference photographs and renders paired at the same resolution, without additional image alignment or appearance correction. We retain all 620 capture views and average per-frame scores with equal weight, so scenes with more views contribute more to the aggregate; metric configurations are provided in Appendix C. As shown in Table 3, LiteReality-Agent achieves the best mean on all four metrics. Compared with GPT-6 (+Scan), the strongest alternative, it improves PSNR by 1.162 dB and reduces LPIPS by 13.7\%; compared with LiteReality, the corresponding gains are 2.248 dB and 19.6\%. Figure 3 presents qualitative comparisons on three representative scenes.
4.3 Geometric Consistency and Physical Plausibility
We evaluate three aspects of geometric consistency: depth MAE (cm) over 611 frames with shared valid depth, bottom near-contact (the proportion of furniture objects with at least one sampled bottom point within 1 cm of an external supporting surface), and the number of furniture pairs with intersecting triangle surfaces. Furniture counts vary across methods, so object-based results must be interpreted alongside these counts. These measures assess specific aspects of physical plausibility, rather than establishing full physical validity. Implementation details are provided in Appendix D.
Results.
Table 3 shows that LiteReality-Agent outperforms both scan-informed agent baselines on all three criteria, achieving a depth MAE of 10.50 cm (21.2\% lower than GPT-6 (+Scan)), bottom near-contact for all 86 identified furniture objects, and no detected furniture–furniture surface intersections. Compared with LiteReality, it maintains 100\% bottom near-contact while reducing depth MAE from 15.03 to 10.50 cm and detected intersection pairs from 43 to zero.
4.4 Effect of Scan Data on General-Purpose Agents
Adding LiteReality Scan data to the same RGB photographs improves all four visual metrics for both general-purpose agents. PSNR increases from 11.549 to 12.967 dB for GPT-6 and from 10.681 to 12.287 dB for Fable 5.1. Depth MAE decreases from 40.51 to 13.33 cm and from 58.64 to 16.32 cm, respectively, corresponding to reductions of 67.1\% and 72.2\%.
These fidelity gains do not consistently extend to the object-based layout measures: detected furniture intersection pairs increase from 14 to 24 for GPT-6 and from 36 to 54 for Fable 5.1, while GPT-6’s bottom near-contact rate decreases from 69.1\% to 63.0\%. These comparisons support the complete system but do not isolate the harness from its other components; intersection counts also depend on the differing furniture populations.
4.5 Qualitative Results
Figure 4 shows a kitchen and meeting room with complementary capture and reconstruction views, with additional rooms and views provided in Appendix A. The editable reconstruction supports changes to materials, furniture, and fixtures without repeating capture or reconstruction; Figure 6 illustrates controlled programmatic edits, while Appendix B.7 provides implementation details and complementary natural-language editing examples. Figure 6 further demonstrates the exported kitchen in MuJoCo, including its response to shaking and a Franka manipulation example. Separate bodies, support relations, and joints enable physical interaction; however, these demonstrations do not measure robot-task success or identify real-world dynamics.
4.6 Human and Agent-Based Perceptual Evaluation
Human and agent evaluators rate LiteReality (Huang et al., 2025b), Fable 5.1 (+Scan), GPT-6 (+Scan), and LiteReality-Agent on layout accuracy, object similarity, and overall scene similarity, each on a five-point scale (higher is better).
Evaluation protocol.
Human participants compare reference images with matched-view reconstruction renders and orthographic plan views, with method identities anonymised and positions randomised per scene. Each participant rates all four methods on five scenes from the ten-scene benchmark, giving 65 participant–scene evaluations across 13 verified submissions; ratings are averaged with equal weight and scene coverage is uneven. Agent-1 and Agent-2 rate the same methods and criteria. Appendix E gives the full protocol.
- LiteReality
- 2.03
- 3.00
- 3.00
- 1.95
- 1.70
- 1.70
- 2.11
- 1.80
- 1.80
- Fable 5.1 (+Scan)
- 2.80
- 3.10
- 3.00
- 2.66
- 2.50
- 2.30
- 2.82
- 3.00
- 2.30
- GPT-6 (+Scan)
- 3.11
- 4.10
- 3.60
- 2.98
- 3.20
- 2.90
- 3.00
- 3.60
- 2.90
- LiteReality-Agent
- 4.60
- 5.00
- 4.90
- 4.58
- 4.80
- 4.20
- 4.54
- 4.90
- 4.20
Results.
LiteReality-Agent has the highest human means (Table 4): layout 4.60, object similarity 4.58, and overall similarity 4.54, exceeding GPT-6 (+Scan) by 1.49, 1.60, and 1.54, respectively. For overall similarity, our method wins 53 of 65 paired participant–scene comparisons against GPT-6 (+Scan), with eleven ties and one loss. Both agent evaluators also rank LiteReality-Agent first and GPT-6 (+Scan) second; their scores differ from human ratings. These ratings measure perceived fidelity. The small sample, uneven coverage, and dependent ratings do not establish statistical significance or physical validity. Agent ratings do not replace human judgments.
5 Conclusion
We presented LiteReality-Agent, an open-source system that treats 3D reconstruction as a coding problem, turning RGB-D scans into realistic, articulated, and simulation-ready scenes. Its observe-edit-verify harness combines executable scene programs, specialised tools, and evidence-driven verification to improve reconstruction quality and reliability. Across ten scenes, our results show gains in visual fidelity, geometric consistency, and perceptual quality over frontier-model agent baselines. As coding agents advance, this orchestration framework offers a practical foundation for robust real-to-sim systems and downstream embodied AI.
References
Appendix A Additional Reconstruction Comparisons
Figures A1 and A2 show all nine reconstructed rooms using the same camera calibration and image crop as the main gallery, pairing human-height views with orthographic plan views.
Appendix B LiteReality-Agent Implementation Details
This appendix supplements Sec. 3 with the capture format, implementation choices, and intermediate visual examples.
B.1 Capture Data and Layout Repair
Table 5 details the scan data used for reconstruction.
- RGB frames
- Appearance references for objects, materials, and fixtures.
- Depth and confidence
- Geometric evidence and visibility checks.
- Camera calibration
- Intrinsics and poses for projection and matched-view rendering; timestamps associate observations.
- Derived point cloud
- A spatial view of the captured surfaces and missing regions.
- RoomPlan detections
- Room structure, openings, and semantic object boxes with metric dimensions and poses.
Graph construction and support.
Graph nodes represent the room, structural surfaces, openings, and objects. Relations record opening hosts, support, wall adjacency, and functional groups. Height and footprint overlap identify support candidates, with wall-hung objects distinguished from floor-standing furniture. Objects without plausible support are flagged. Expected containment, including chairs beneath tables, is distinct from conflicting footprints.
Bounded repair.
Before cropping and generation, candidate layouts are compared by error count, then summed error magnitude. Fidelity limits apply cumulatively against the original scan. The implementation caps horizontal displacement at 0.6 m and vertical displacement at 0.08 m. Per-axis size changes are limited to 15\% for tables, desks, chairs, sofas, and beds, and 35\% for other categories. Erroneous merges may be split into their original members; measured objects cannot be deleted to remove violations. Repair stops on validation, repeated lack of progress, or six agent-assisted rounds. Corrected boxes are handed to room assembly (Fig. A3).
B.2 Layout Agent: Relations, Repair, and Before–After Results
The layout stage corrects the detected boxes before they determine object crops, reconstruction dimensions, and placement. It combines a geometric scene graph, a deterministic repair search, and an optional image-guided agent for unresolved cases. This ordering avoids propagating a misplaced or oversized detection into asset generation.
Relations constrain the edits.
The graph distinguishes physical support from functional grouping. An object has one support parent—a floor, wall, ceiling, or another object—or is flagged as unsupported. A chair may belong to a desk’s functional group while being supported by the floor. This distinction allows a desk and its chair to move together without claiming that the desk supports the chair. Separate relations encode wall adjacency, opening hosts, and expected containment, such as a chair tucked under a table. These category-aware exceptions prevent plausible box overlaps from being treated as errors.
Propose, validate, and retain.
The geometric search tries wall alignment, corner fitting, separation, and small changes to box dimensions. Each candidate is checked against the room boundary, walls, other objects, and the scan-fidelity limits above. When geometry alone leaves an unresolved case, the optional agent receives the current box, nearby walls and objects, the violation, reference photographs, and feedback from rejected proposals. It can propose translation, resizing, attachment to one or two walls, or splitting a merged box into its original members. Proposals must preserve existing anchors, satisfy cumulative fidelity bounds, and improve the geometric score before they are retained. Rejected edits leave the accepted layout intact; unresolved findings remain in the report.
Recorded outcomes and scope.
The saved runs reduce the layout checker’s error count from 30 to 0. Eight scenes required changes; the two initially valid scenes were unchanged. Across 107 input boxes, 29 were moved and four were resized. These runs were resolved by the deterministic search and therefore do not measure the additional benefit of image-guided proposals. A zero count means that the boxes pass this checker’s tolerances and category exemptions. Generated meshes and later authored objects still require the separate collision and support checks in Appendix B.6.
Coordinated movement.
In the office (Fig. A4a), Table1 and Chair1 both move by (0.1445,0.0124,0) m. The shared 14.5 cm translation preserves their relative arrangement and removes the two recorded violations without resizing either box.
Corner fitting and local separation.
In the kitchen (b), Storage3 and Dishwasher0 each move about 5.3 cm and reduce their two horizontal dimensions by about 8.5 cm, resolving three boundary/wall violations. In the meeting room (c), five chairs are separated and the television is aligned to its wall, reducing six violations to zero. All six boxes retain their dimensions; the largest centre shift is 14.1 cm.
B.3 Object Reconstruction and Physical Metadata
Figure A5 shows both reconstruction routes using clean references generated from scan views. Raw captures remain the evidence for checking fidelity: completed occluded parts are estimates.
Generated-mesh rejection and retries.
Mesh checks look for implausible aspect ratios, disconnected fragments, extensive flat boundary surfaces, and dense bottom geometry suggesting that a floor or background was fused into the asset. The chair repair loop regenerates both the image reference and the mesh, varying the reconstruction seed between attempts. A retry is checked again before acceptance. If the retry budget is exhausted, the implementation retains the original asset and records the unresolved failure.
Estimating physical properties.
The procedural program defines links, joint axes, pivots, and limits. Authored mass or density overrides automatic estimates. Otherwise, category-dependent occupancy density times bounding-box volume estimates total mass, which is distributed across links using geometric volume estimates. Inertia and centre of mass are computed from link geometry; convex-hull and box estimates provide fallbacks for degenerate meshes. Material-name priors supply friction and restitution when unspecified. Restitution is retained in the asset metadata but is not directly used by the MJCF exporter. Each physical-property record retains its source.
Collision geometry and solver checks.
Near-convex parts can use a single hull; larger concave parts use convex decomposition. The decomposition budget depends on link mass to limit excessive contact complexity for lightweight objects. Per-object MuJoCo checks comprise a short drop, individual joint release, and tilted-gravity sliding. They report penetration, separation, unstable motion, and friction behaviour. Joint tests distinguish frame collisions from sibling interactions that may require a particular opening sequence.
B.4 Evidence Tools and Authoring State
Selecting and comparing views.
The view selector supports room, wall, and object queries (Fig. A6). Room queries seek complementary coverage; local queries rank views of the requested target. The render tool rebuilds the current program and pairs the output with its capture photograph using recorded calibration. This exposes discrepancies in shape, placement, and appearance without asking the agent to align unrelated viewpoints.
Persistent editing and materials.
Room.py contains room-level construction and placement, while object.py contains a procedural asset’s build recipe. Material retrieval saves colour, roughness, and normal maps together with a reusable recipe; recolouring changes the diffuse appearance while retaining the spatial pattern. Rebuilding these programs is the handoff between modules, ensuring that the exported geometry reflects the saved edits.
B.5 Stitched Wall Visualizations
Wall stitching and measurement.
Figure A8 shows stitched wall references, their coverage, and the metric overlay. A metric grid is laid on the detected wall plane. Each output pixel corresponds to a 3D location that is projected into candidate frames using their calibration. Selection favours frontal, central, nearby observations, with depth visibility used when available. Selected frames fill the rectified image without blending; a coverage mask records unobserved pixels. The metric-grid tool overlays distance along the wall and height above the floor. These coordinates can be used directly to place fixtures. The planar projection can distort protruding objects, so raw capture views remain necessary for lamps, clutter, and furniture.
B.6 Quality Control and MuJoCo Integration
Collision and support are separate checks.
A chair can overlap a table’s box without intersecting its actual legs or top. We therefore use mesh intersections to establish clashes and convex approximations to estimate a correction. The resolver moves unanchored objects horizontally within a bounded correction budget, writes the accumulated changes to the scene program, and rebuilds before rechecking. It reports cases that cannot be solved by these local motions.
For a declared support, the validator compares the object’s underside with the support’s top surface and measures footprint overlap. Gaps above 1 cm and penetration exceeding 2 cm are blocking findings; less than half of the footprint overlapping the support is reported for review. Missing or unknown support declarations also block validation. For recognised floor-standing objects without an explicit declaration, the floor-contact fallback uses a 5 cm tolerance. Structural attachments are recorded separately and are exempt from gravity-support checks. These implementation checks differ from the evaluation metric in Appendix D, which measures sampled bottom near-contact and is not the authoring gate.
Visual review and bounded sessions.
Deterministic checks address geometric failure modes; a separate, checklist-based model review can assess visual discrepancies. The maximum turn count and tool-call budget constrain the authoring session, while a reserved final portion of calls directs completion of edits. The reserve is configurable. Enforcing it by disabling exploratory tools requires a pre-tool hook; adapters without this hook implement a hard call-budget stop. In either case, the saved program must still be built and checked, and termination is not a QC verdict.
Exporting the physical scene.
The exporter combines four sources: shell geometry from Room.py, object poses and support declarations from room_layout.json, appearance from Room.glb, and per-object physics records. Walls are decomposed into structural boxes around door and window openings. Attached fixtures are fixed, movable objects have free joints, and articulated parts use their specified hinge or slide joints.
The transform between an asset’s local geometry and its placed instance also places its collision geometry and joint frames. When size changes, derived mass scales with volume, authored mass is retained, and inertia is recomputed from the placed geometry. Collider bounds are checked against the recorded object bounds. Joints with compiled effort metadata receive motor actuators; velocity limits are retained as controller metadata. Newly authored objects without physics records use export-time mass and collider estimates, and these fallbacks appear in the export report.
Figure 6 in the main paper illustrates the exported scene under perturbation and robot interaction.
B.7 Additional Scene-Editing Demonstrations
Figure A9 shows natural-language editing examples that complement the controlled programmatic edits in Fig. 6. The requests change the wall material, clear space for a meeting, and add decorations to the reconstructed office.
Controlled programmatic demonstrations.
The variants in Fig. 6 each start independently from one saved 3D office scene and use an identical camera, resolution, and render configuration. The following details describe these main-paper examples.
Material editing.
The carpet edit changes its colour while retaining the spatial texture, room geometry, and furniture placement. This isolates an appearance change from structural reconstruction.
Object removal.
The layout edit removes the meeting-table group and four guest-chair groups. Walls, shelves, and other fixtures remain in place, exposing the floor previously occupied by the furniture.
Fixture addition.
The lighting edit adds three pendant assemblies above the existing table. Each assembly contains a shade, suspension cord, and light source, with a ceiling-attachment declaration. The change affects both geometry and illumination.
Provenance and scope.
The images in Fig. 6 are Blender renders of the saved office reconstruction, produced by a reproducible scene-editing script. They are qualitative examples of what the editable representation permits, not additional measurements of autonomous agent success or physical validity. The render manifest records the source scene, camera, resolution, and sampling settings for each variant.
Appendix C Additional Experimental Details
Scan inputs.
For each scene, the +Scan condition supplements the RGB photographs with aligned LiDAR depth and confidence maps, camera intrinsics, poses, timestamps, a derived point cloud, and a RoomPlan USDZ layout collected or generated by LiteReality Scan. The RoomPlan layout encodes room structure and the semantic categories, dimensions, positions, and orientations of detected objects. LiteReality and LiteReality-Agent receive the same scan information as the +Scan baselines.
Evaluation views and camera alignment.
The ten evaluation scenes contain 27–91 capture views each. All six method–input configurations are evaluated on the same scene–frame pairs, yielding 3,720 reference–render comparisons. Reconstructed Blender scenes are aligned to the coordinate system of the recorded camera poses while preserving scene scale and individual object placements. Rendering uses the recorded camera poses, with intrinsics adjusted to 960\times 720.
Rendering configuration.
All scenes are rendered in Blender 5.2 using Cycles, with up to 64 samples per pixel and OptiX denoising. For each scene, all methods use the same light objects, world illumination, and colour-management settings from the corresponding LiteReality-Agent scene, while retaining their own materials, textures, and material emission. Architecture hidden for cutaway views is restored where identified. The shared lighting is not independently calibrated to the reference photographs.
Image preprocessing.
Reference photographs are downsampled from 1920\times 1440 to 960\times 720 using Lanczos interpolation and paired with renders by scene and frame identifier. No additional warping, cropping, masking, rotation, or exposure/colour correction is applied. All capture frames, including dark renders, are retained.
Metric implementation.
SSIM, PSNR, and RMSE are computed on stored RGB values normalised to [0,1], without linearisation. SSIM uses an 11\times 11 Gaussian window with \sigma=1.5, population covariance, and averaging across RGB channels. LPIPS uses pretrained AlexNet with version-0.1 calibration weights, evaluated at 960\times 720 with inputs normalised to [-1,1].
Aggregation.
For each metric, we report the arithmetic mean of per-frame scores over all 620 views. In particular, PSNR is averaged over individually computed per-frame PSNR values. Views receive equal weight, so scenes with more capture views contribute more to the aggregate.
Appendix D Geometric Evaluation Details
Depth agreement.
We compute the mean absolute error between rendered and captured depth using pixels with valid depth in the capture and all evaluated outputs, including RoomPlan. We average per-frame errors over the 611 frames with shared valid pixels and report depth MAE in centimeters.
Bottom near-contact.
We count furniture objects with at least one sampled bottom point within 1 cm of an external supporting surface. We report both the count and its percentage relative to all identified furniture objects in each method’s output. This criterion measures bottom support proximity; it does not require every leg or base component to contact a supporting surface.
Furniture intersections.
We detect strictly intersecting triangle surfaces in the evaluated source meshes using a 0.1 mm plane-side tolerance. This tolerance is not a penetration-depth threshold. Each furniture pair is counted once per scene, and counts are summed across the ten scenes. Intersections within a single furniture object and between furniture and architecture are excluded. The resulting counts describe detected surface intersections and require semantic interpretation.
Object populations.
Object-based metrics use the furniture objects identified in each method’s output. These populations differ across methods, so near-contact rates and intersection counts must be interpreted alongside the reported furniture counts.
Appendix E Additional Perceptual Evaluation Details
Rating criteria.
We evaluate LiteReality, Fable 5.1 (+Scan), GPT-6 (+Scan), and LiteReality-Agent on three criteria using a five-point scale, with higher scores indicating closer agreement with the reference scene. Layout accuracy concerns room structure and object positions and orientations. Object similarity concerns object shape, scale, and appearance. Overall scene similarity assesses the reconstruction as a whole. We report the criteria separately without constructing a composite score.
Questionnaire design.
The questionnaire presents a reference RGB image alongside reconstruction renders from the corresponding camera viewpoint, together with an orthographic plan-view comparison. Methods are displayed anonymously, with their positions randomised independently for each scene; displayed letters therefore do not identify a fixed method across scenes. Each participant evaluates five scenes sampled without replacement from the ten-scene benchmark and rates all four methods on all three criteria.
Sample inclusion and aggregation.
The reported human results use 13 completed submissions with resolved method identities, comprising 65 participant–scene evaluations and 780 individual ratings. Each method receives 65 ratings per criterion. We report arithmetic means, giving each participant–scene evaluation equal weight. Scene coverage ranges from three to eleven participants, so scenes are not equally weighted. Three additional submissions containing unresolved anonymous method identifiers are excluded from the current aggregation pending verification of the identifier mapping.
Agent-based evaluation.
We report two sets of agent-generated ratings, designated Agent-1 and Agent-2, for the same four methods and three criteria. Agent ratings are aggregated and presented separately from human ratings.
Additional comparisons.
LiteReality-Agent achieves the highest human mean overall scene similarity in each of the ten scenes. Its mean advantage over GPT-6 (+Scan) on this criterion is 1.54 points for humans and 1.30 points for each agent evaluator. Agent-1 scores LiteReality-Agent above the human mean on all three criteria, whereas Agent-2 assigns a higher layout score but lower object and overall similarity scores. Thus, the evaluations agree on the two leading methods while differing in absolute score levels.
Appendix F Limitations and Future Work
Physical properties lack ground-truth validation.
The physical properties used for simulation rely largely on language-model inference and category or material priors, with geometry-based estimates for quantities such as inertia. We do not have ground-truth measurements of these properties for the reconstructed objects. Simulation export and consistency checks therefore do not establish that the scenes reproduce real-world dynamics. Collecting measured physical properties and validating simulated behaviour against real interactions are important future work.
Layout consistency does not guarantee accuracy.
RoomPlan detections can contain errors in object dimensions and poses that persist in the reconstructed layout. Our collision and support corrections improve geometric consistency, but neither these checks nor visual agreement with captured images guarantee recovery of the true layout. Future work should more tightly integrate image evidence with collision and support constraints during layout refinement, and evaluate the resulting layouts against measured ground truth.
Broader evaluation should also cover larger and more structurally diverse environments.