방문자

오늘
—
어제
—
누적
—

불러오는 중

게임 개발 · 기술 동향 · 팀 블로그MIRO
헤드라인

three.js

Three.js r187, 카메라별로 가림 쿼리 결과를 유지

NormalTangentMirrorTest 렌더 샘플
그래픽 개념을 보여주는 Khronos glTF 참고 샘플입니다. 2018, Analytical Graphics, Inc.. · 이미지 출처 · 이용 조건

한 카메라의 판정이 다른 화면에 섞이던 문제

Three.js r187은 한국시간 2026년 10월 30일 공개됐습니다. 변경 목록에는 가림 쿼리 결과를 카메라별로 유지하는 수정이 포함됩니다. 여기서 가림 쿼리는 그린 물체가 다른 지오메트리에 가려졌는지 GPU 결과를 통해 판단하는 수단입니다. 이번 수정의 핵심은 쿼리를 더 빠르게 만드는 것이 아니라 여러 카메라의 결과를 잘못 공유하지 않도록 하는 데 있습니다.

관련 PR #35066은 렌더 컨텍스트가 장면과 카메라별이 아니라 출력 타깃의 구성과 호출 깊이 등으로 재사용되면서 문제가 생겼다고 설명합니다. 서로 다른 카메라가 같은 컨텍스트를 사용하면, 나중 카메라의 쿼리가 앞선 카메라의 결과를 덮어쓸 수 있었습니다.

화면 분할과 별도 타깃에서 나타납니다

하나의 캔버스에 카메라 두 개를 그리는 화면 분할뿐 아니라, 같은 형식의 별도 렌더 타깃에 그리는 경우도 PR의 확인 대상입니다. 타깃 객체가 다르다는 이유만으로 내부 판정 데이터까지 분리되어 있다고 볼 수 없었던 것입니다. 한 시점에서는 벽 뒤에 가려진 물체가 다른 시점에서는 보이는 장면이라면 차이가 드러날 수 있습니다.

수정은 컨텍스트 안에서 카메라를 키로 삼는 WeakMap을 사용해 가림 데이터를 나눕니다. WebGPU와 WebGL 백엔드에 변경이 들어갑니다. 이는 해당 백엔드 구조의 수정이며, 모든 WebGL 렌더링 문제나 임의의 사용자 정의 가림 로직까지 해결한다는 뜻은 아닙니다.

PR의 검증 범위를 읽는 방법

작성자는 평면 뒤의 구를 대상으로 단일 카메라, 분할 화면, 같은 형식의 두 타깃, 추가 오버레이 조합을 비교했습니다. 단일 카메라는 변경 전에도 정상인 반면, 여러 카메라가 같은 컨텍스트를 공유하는 조합에서 수정 전후 차이를 보고했습니다. 헤드리스 Chromium을 사용한 작성자의 결과이지, 이 글에서 실행한 테스트는 아닙니다.

이 구분은 업데이트 우선순위를 판단할 때 중요합니다. 단일 시점만 사용하는 화면과 미니맵·분할 화면처럼 여러 시점을 그리는 화면이 같은 위험을 갖는다고 가정할 필요는 없습니다. 먼저 자신의 코드가 가림 판정을 어디에서 읽는지와 카메라별 렌더 순서를 확인하는 편이 좋습니다.

프로젝트에서 비교할 항목

시험 장면을 만든다면 한 카메라에서는 물체를 가리고 다른 카메라에서는 보이게 배치해 보세요. 카메라 하나씩 렌더링한 기준 결과와 두 카메라를 연달아 그린 결과를 비교하면 공유 상태 문제를 찾기 쉽습니다. 이후 렌더 순서를 뒤집고, 화면 분할과 별도 타깃을 구분해 확인할 수 있습니다.

이 절차는 PR에서 확인한 원인을 프로젝트에 적용하는 제안입니다. 결과가 바뀌었다면 시각적인 스크린샷뿐 아니라 카메라, 타깃 형식, 렌더 순서와 판정 값을 함께 남기세요. 이번 변경을 전체 렌더링 성능 향상으로 표현하기보다, 다중 카메라에서 결과의 소유 관계를 바로잡은 수정으로 이해하는 것이 정확합니다.

출처

댓글

이 글에 대한 생각을 남겨 주세요.

댓글 삭제

헤드라인

같은 카테고리의 글

최신 게임 개발 동향 전체 보기 ↗