Engine-Native Editable 3D World Reconstruction with Objects and Lighting

3줄 요약

1. 칭화대·난카이대·NTU 등의 공동 연구진과 Ophilus.AI가 2026년 7월 arXiv에 올린 Lumera. 사진 한 장을 게임 엔진이 그대로 읽을 수 있는 3D 씬으로 옮기는 벤치마크이자 참조 파이프라인이다.
2. 차별점은 조명이다. UE5 프로젝트 2,513개에서 파라메트릭 광원 10.26만 개를 주석으로 뽑아, 지금까지 구워진 픽셀로만 남던 광원을 셀 수 있는 개체로 세웠다.
3. 3D 박스 파싱은 기존 방법을 큰 폭으로 앞섰다(mAP 0.1141 대 0.0021). 개별 광원 위치 추정은 0.5m 기준 F1 0.209에 그친다. 논문은 이 숫자를 성과로 포장하지 않고 남은 병목으로 내놓는다.

편집 가능한 씬이란 무엇인가

사진 한 장을 3D로 되돌리는 연구는 오래됐다. 그런데 게임 제작, 버추얼 프로덕션, 시뮬레이션, 로보틱스가 실제로 필요로 하는 결과물은 “그럴듯한 픽셀"이나 융합된 지오메트리 덩어리가 아니다. 옮길 수 있는 오브젝트 인스턴스, 교체하거나 다듬을 수 있는 메시, 그리고 위치와 색과 세기를 열어보고 고칠 수 있는 광원이다.

논문은 기존 계열이 각각 어디까지 왔는지를 먼저 정리한다.

여기에 최근 사정이 하나 더 붙는다. 3D 조건부 비디오 생성 모델들이 정확한 카메라 제어와 오브젝트 조작을 위해 명시적인 3D 씬을 입력으로 요구하기 시작했다. 그 조건을 만들어 줄 파서가 없으면 모델이 돌지 않는다. 논문의 표현으로는, 필요한 조건을 만드는 일이 곧 현재 단일 이미지 파서가 하지 못하는 일이다.

Lumera의 제안은 이 문제를 게임 엔진 구조화 파싱(game-engine structured parsing)으로 다시 놓는 것이다. 엔진은 이미 오브젝트 컴포넌트, 트랜스폼, 카메라, 머티리얼, SkyLight 프로브, 셀 수 있는 파라메트릭 광원을 저장하고 있다. 그렇다면 복원의 목표를 그 스키마에 맞추면 된다. 이름 자체가 이 순서를 담고 있다. Lumera는 Light-aware Unified Engine-native Reconstruction and Assembly의 머리글자다. 프로젝트 페이지가 방법 절에 붙인 표제도 같은 말을 한다. 구조화된 지각이 먼저, 제약된 편집이 나중.

Lumera-2K, UE5 프로젝트 2,513개를 갈아 넣다

인터넷에 공개된 무료 애셋으로 만들어진 UE5 프로젝트 2,513개에서 데이터를 뽑았다.

논문이 Table 1에서 비교한 기존 데이터셋 열여섯 종 가운데, 광원별 파라메트릭 주석(위치·타입·세기·색온도)을 셀 수 있는 인스턴스로 공개한 곳은 하나도 없다. 구워진 HDR 텍스처나 인트린식 분해는 여기에 넣어주지 않았다. ScanNet, 3D-FRONT, Hypersim, ProcTHOR, SpatialLM-Dataset, Holodeck 모두 실내 전용이기도 하다. Lumera-2K는 실내와 실외를 함께 담은 유일한 항목으로 표에 올라 있다.

데이터를 만드는 과정에서 세 가지 손질이 들어갔다.

카메라. UE5 프로젝트에 원래 들어 있는 카메라는 씬당 평균 3.0개뿐이라 학습 신호로 쓸 수 없다. 헤드리스 UE5 파이프라인으로 씬마다 16~100개의 유용한 뷰를 새로 계획했다. 전경 오브젝트를 관심 영역으로 군집화하고, 실내는 방 분할에서 실외는 오브젝트·건물 앵커에서 카메라를 표집하며, 벽을 마주 보거나 텅 빈 뷰를 걸러낸 뒤, 커버리지·참신성·화면 채움을 가중합한 점수로 다양한 카메라 집합을 탐욕적으로 고른다. 마지막으로 가벼운 이미지 QA가 백지·과노출·저노출 프레임을 떨어낸다.

라벨. 게임 애셋의 내부 이름은 SM_chair_01이나 BP_Seat_A 같은 식이라 그대로 쓸 수 없다. 오브젝트를 따로 렌더한 뷰에 애셋 이름 힌트와 맥락 이미지 한 장을 함께 넣어 VLM에게 간결한 시각 라벨을 요구했다. 프롬프트는 이미지 증거가 프로젝트 명명을 이기도록 지시하고, 정규화 단계가 wall·floor 같은 껍데기 라벨과 에디터 플레이스홀더를 억제한다.

광원. PointLight, SpotLight, DirectionalLight, RectLight, SkyLight 컴포넌트를 씬 단위와 카메라 단위로 모두 순회한다. 릴리스에는 위치, 방향, 세기 단위, 감쇠, 스포트 콘 파라미터, RGB 색상, 색온도 같은 네이티브 속성이 그대로 남는다. 학습 과제에서는 카메라 프러스텀과 영향 범위가 겹치는 활성 광원을 (x, y, z, r, g, b, I) 일곱 개 값으로 추상화해 오브젝트 박스와 같은 뷰 단위로 맞췄다.

박스와 빛을 같은 문법으로 쓴다

파싱은 SpatialLM-1.1-Qwen-0.5B에서 출발한 두 체크포인트가 맡는다. 베이스 아키텍처와 포인트 클라우드 인코더, 위치 토큰 이산화는 공유하지만 데이터 스트림·스키마·가중치·디코딩 설정은 따로 간다.

• Lumera-Box는 컬러 포인트 클라우드에서 방향을 가진 3D 박스와 텍스트 라벨을 뽑는다. 아키텍처는 건드리지 않고 감독 도메인만 바꿨다. 실내 스캔과 합성 방으로 학습한 공간 LLM은 밀집한 게임 씬으로 잘 옮겨가지 않기 때문에, 껍데기 라벨을 억제하는 전경 어휘, 같은 프로젝트의 멀티뷰 감독, 빈출 카테고리의 지배를 줄이는 클래스 재균형을 넣었다.
• Lumera-Light는 같은 백본으로 (x, y, z, r, g, b, I) 광원 튜플을 낸다.

둘을 분리한 이유를 논문은 셋으로 든다. 대부분의 뷰에서 박스가 광원보다 훨씬 촘촘해 함께 학습하면 드문 광원 신호가 고빈도 박스 토큰에 묻힌다. 체크포인트가 독립적이면 한쪽을 고쳐도 다른 쪽이 오염되지 않는다. 그리고 하류 조립 단계가 박스와 광원을 별개의 편집 개체 집합으로 소비하므로 함께 디코딩할 이유가 없다.

두 과제 모두 별도의 검출 헤드가 아니라 스키마만 갈아 끼운 코드 생성으로 다룬다는 점이 이 그림의 요지다. 메시 생성기가 면과 정점을 토큰으로 내고 리깅 모델이 관절과 스켈레톤 트리를 시퀀스로 내는 것과 같은 계보에, 파라메트릭 광원을 새 예측 대상으로 올려놓은 셈이다.

조립 단계, 그리고 목줄을 채운 에이전트

파싱 결과는 그대로 씬이 되지 않는다. 조립은 네 조각으로 이뤄진다.

1. 지오메트리 프런트엔드. Depth Anything 3가 카메라, 깊이, 컬러 포인트 클라우드를 준다. 이 지오메트리 자체는 최종 씬으로 쓰이지 않는다. 3D 개체와 입력 이미지를 잇는 미터 단위 다리 역할만 맡는다.
2. 인스턴스 메시. 예측된 박스를 이미지로 역투영해 사각형 프롬프트를 만들고, 예측 라벨과 함께 SAM 계열 분할기에 넣어 마스크를 얻는다. 마스크와 박스 내부 점이 가림이나 보정 오차로 어긋나면 3D 박스가 인스턴스의 정체성과 강체 경계로 남고, 마스크는 RGB 크롭 품질만 개선한다. SAM3D가 크롭마다 텍스처 메시를 복원한다.
3. 환경광. IntrinsicHDR이 이미지에서 HDR 파노라마 또는 SkyLight 큐브맵을 추정한다. 국소 광원 더하기 HDR 환경 프로브라는, 엔진에서 익숙한 조합이 여기서 완성된다.
4. 경계가 있는 정련. Generator와 Verifier 에이전트가 지오메트리 단계와 라이팅 단계를 나눠 각각 12라운드까지 돈다.

정련 루프의 설계가 흥미롭다. VIGA의 분석-합성 루프를 가져오되 실행 가능한 제약을 걸었다. 지오메트리 단계에서 에이전트가 만질 수 있는 것은 오브젝트의 yaw와 스케일뿐이고 위치 변화량은 0으로 고정된다. 라이팅 단계에서는 초기 씬에 이미 존재하는 광원, 환경 강도, 노출만 건드릴 수 있다. 카메라·메시·머티리얼·토폴로지는 단계마다 얼려둔다.

제안된 편집은 세 가지 검사를 통과해야 실행된다. 스코프 밖 코드를 찾는 정적 스캔, 필드 수준 화이트리스트에 대한 실행 전후 씬 차분 검사, 광원 캐리어 부재 같은 단계별 사전 조건 검사다. 위반이 하나라도 걸리면 실행 직전 스냅샷으로 되돌리고 위반 내용을 Verifier 보고서에 적는다. 이 분리가 막는 것은 VLM이 조명을 고치겠다며 지오메트리를 바꾸거나, 빠진 지오메트리를 보상하려고 조명을 비트는 흔한 실패다.

파이프라인이 회수하는 채널은 셋이다. 인스턴스별 방향 박스와 열린 어휘 라벨, 파라메트릭 광원 튜플, 그리고 HDR 환경 프로브. 프로젝트 페이지의 데모 씬 하나를 네 컷으로 갈라 놓으면 각 채널이 무엇을 담는지 한눈에 보인다.

오른쪽 위의 박스 더미를 보면 게임 씬의 밀도가 실감난다. 컵, 캔, 접시, 의자 다리까지 개별 인스턴스로 잡힌다. 왼쪽 아래의 광원 표시는 이 뷰에서 모델이 광원 하나를 짚어냈다는 표기이고, 앞의 F1 0.209라는 숫자가 실제로 어떤 장면에서 나온 것인지 짐작하게 한다. 오른쪽 아래는 그 결과를 다시 렌더한 씬이다. 카운터의 네온 반사와 스툴 배치가 살아남았고, 창밖의 배경 구조는 사라졌다. 이 버전이 전경 애셋에 집중하고 벽·바닥·지형 같은 큰 껍데기는 별도 파이프라인으로 넘긴다고 논문이 밝힌 대목과 맞는 그림이다.

성적표

평가는 UE 프로젝트 단위로 나눈 val 1,316뷰, test 1,314뷰에서 이뤄졌다. 잘못된 라벨, 0 이하 크기, 중복 ID, ID 폴백을 제거한 정제 프로토콜을 적용했다.

3D 박스 파싱 (val+test 병합 2,630뷰)

가장 강한 베이스라인인 WildDet3D와 견주면 mAP는 0.1120, IoU-B는 0.2332, F-score는 0.2196만큼 올라가고 중심 오차는 3.068m 줄어든다. 게임 도메인 감독이 실제로 효과가 있다는 뜻이다. 반대 방향의 숫자도 함께 실렸다. 관계 구조를 보는 SRF에서 0.1371, 앵커 리콜에서 0.3204만큼 뒤진다. 논문은 이를 두고 관계 복원이 풀리지 않았다고 적는다. N3D-VLM은 IoU가 베이스라인 중 높은 편인데 Chamfer와 중심 오차가 네 자릿수로 튀어, 전역 이동이나 스케일이 불안정하다는 해석을 붙였다.

파라메트릭 광원 (광원이 있는 575개 씬)

씬에 광원이 있다는 사실은 거의 놓치지 않는다(0.998). 개별 광원을 짚어내는 일은 다르다. 매칭된 광원의 위치 중앙 오차는 0.261m로 쓸 만하고 색도 그럭저럭이지만, 세기는 로그 스케일 MAE 0.431, 곱셈 오차로 환산하면 약 2.7배 수준으로 거칠다.

임계값을 풀어주면 그림이 달라진다.

2.0m까지 열어주면 F1이 0.456으로 오른다. 모델이 광원의 대략적인 이웃은 자주 맞히지만 충분한 수의 광원을 정밀하게 앉히지는 못한다는 의미다. 병목이 출력 형식 문제는 아니다. 채택된 예측 광원 2,536개 중 RGB 값이 잘못된 것은 둘뿐이고, 정규식 불일치나 무한대 값, 중복 ID, ID 퇴행은 관측되지 않았다. 논문은 화면 밖에 있거나 카메라에 아주 가까워 영향은 보이지만 광원 자체의 기하가 모호한 경우를 어려운 사례로 든다.

편집 가능한 조립. 인스턴스 55개짜리 실내 씬에 정답 박스를 넣고 정련 루프를 돌린 사례 연구에서, 12라운드 안에 VLM 점수가 6.1에서 8.3으로 오르고 Chamfer 거리가 초기값의 71.8%로 내려갔다. 초기 파스가 부실한 실외 씬에서는 루프의 이득이 거의 없었다. 저자들의 결론은 분명하다. 에이전트 정련은 쓸 만한 파스 위에서 동작하는 편집기이지 구조화 파싱의 대체물이 아니다.

가장 흥미로운 지점

내가 오래 들여다본 것은 이 논문이 자기 약점을 다루는 방식이다.

F1 0.209는 자랑할 숫자가 아니다. 그런데 저자들은 이 값을 감추는 대신 임계값 스윕을 통째로 실어서, 0.25m에서 0.109, 2.0m에서 0.456으로 변하는 곡선을 보여준다. 곡선의 모양이 곧 진단이다. 완만하게 오른다면 모델이 광원을 아예 못 찾는 것이고, 가파르게 오른다면 위치는 대강 알되 정밀도가 모자란 것이다. 여기에 더해 형식 오류 통계까지 붙였다. 2,536개 중 RGB 무효 2개. 파싱 실패로 점수가 깎인 게 아니라는 알리바이다. 실패를 보고할 때 실패의 종류를 특정할 수 있게 지표를 설계해 둔 셈인데, 이런 준비는 결과가 나온 뒤에 하기 어렵다.

에이전트에 대한 태도도 눈에 남는다. 요즘 파이프라인들이 마지막 단계에 에이전트를 붙여 놓고 “루프가 알아서 고친다"고 말하는 데 익숙해졌는데, Lumera는 에이전트가 만질 수 있는 필드를 화이트리스트로 좁히고, 스코프 밖으로 나가면 스냅샷으로 되돌린다. 그리고 실외 저품질 파스는 루프로 구제되지 않았다고 그대로 적었다. 자유도를 줄일수록 루프가 쓸모 있어진다는 관찰과, 루프가 못 구하는 영역이 존재한다는 관찰이 같은 절에 나란히 있다.

한 가지 마음에 걸리는 대목은 데이터의 출처다. Lumera-2K는 인터넷에 공개된 무료 UE5 애셋으로 만든 프로젝트 2,513개에서 나왔고, 논문 자신도 UE 스타일 애셋을 벗어난 일반화를 한계로 열거한다. 엔진 네이티브라는 표현이 지금은 사실상 언리얼 네이티브에 가깝다. 조명이 셀 수 있는 개체가 되었다는 성취가 다른 엔진과 실사 촬영본으로 얼마나 건너갈지는, 이 데이터셋만으로는 아직 답이 나오지 않는다.

논문 본문에는 코드나 데이터 공개에 대한 언급이 없고, 프로젝트 페이지는 코드와 Lumera-2K 데이터셋 양쪽에 “soon"만 걸어 두었다. 상태 표기는 아직 프리프린트다. 벤치마크를 표방한 작업이니 공개가 이 연구의 다음 관문이 될 것이다. 셀 수 있는 광원이라는 표현이 주장으로 남을지 다른 연구자가 재보는 눈금이 될지는 그 시점에 갈린다.

출처

Junhao Chen, Xinghao Chen, Henghaofan Zhang, Zihao Qiao, Saining Zhang, Yongzhi Li, Ruqi Huang, Sisi Li, Yimin Sheng, Jianyi Zhu, Hao Zhao (Tsinghua University, Nankai University, University of Electronic Science and Technology of China, Sun Yat-sen University, Nanyang Technological University, Ophilus.AI), “Engine-Native Editable 3D World Reconstruction with Objects and Lighting”, arXiv:2607.20889, 2026년 7월 23일. 앞의 세 저자가 동등 기여, Hao Zhao가 교신저자다.

• 논문: https://arxiv.org/abs/2607.20889
• 프로젝트 페이지: https://haidilao0328.github.io/Lumera/
• 개요 영상: https://www.youtube.com/watch?v=x7s8649kAO4

박스 파싱·광원·비교 그림은 arXiv HTML 판본(v1)에서, 채널 분해 4컷은 프로젝트 페이지의 버거 가게 데모 씬에서 가져와 한 장으로 합쳤다.