포털 컬링

편집 역사 토론
컴퓨터 그래픽스 게임 개발 마지막 수정: 2026-09-02 04:39:17

1. 개요[편집]

포털 컬링
Portal Culling
전제장면이 셀(방)과 포털(개구부)로 나뉜다
원리포털을 지날 때마다 시야 절두체를 교집합해 좁힌다
시점런타임 재귀 — PVS는 오프라인 전처리
강한 곳실내: 복도·문·창문이 많은 건축 공간
약한 곳실외: 포털이 될 개구부가 없다
보너스거울·워프 렌더링이 거의 공짜로 따라온다

방 안에서 보이는 세상은 결국 문틈만큼이다. 그 문틈을 자료구조로 만든 것이 포털이다.

포털 컬링(portal culling)은 실내 장면을 볼록한 셀(cell, 방)들로 나누고 셀 사이의 개구부를 포털(portal)로 명시한 뒤, 카메라가 속한 셀에서 출발해 포털을 통과할 때마다 시야 절두체를 그 포털의 사각뿔과 교집합해 가며 재귀적으로 보이는 셀만 추려 내는 가시성 판정 기법이다. 문을 하나 지날 때마다 볼 수 있는 각도가 좁아진다는, 사람이라면 누구나 아는 사실을 알고리즘으로 옮긴 것이다.

프러스텀 컬링이 “시야 밖이라 안 보인다”를, 오클루전 컬링이 “뭔가에 가려 안 보인다”를 담당한다면, 포털 컬링은 후자의 특수하고 강력한 사례다. 일반적인 오클루전 판정이 “무엇이 가리는가”를 매 프레임 찾아 헤매는 데 반해, 포털 방식은 벽이 전부 가리고 뚫린 곳만 안 가린다는 사실을 레벨 구조에 통째로 박아 두고 “안 가리는 곳”만 세는 쪽으로 문제를 뒤집는다. 실내에서 이 뒤집기의 효율이 압도적이라, 90년대 후반 실내 FPS 엔진의 국룰이 되었다.

2. 셀과 포털 — 자료구조[편집]

전처리에서 만드는 것은 인접 그래프 하나다.

  • 셀: 벽으로 완전히 둘러싸인 볼록 영역. 볼록성이 중요한 이유는 셀 안에서는 서로가 서로를 가리지 않는다고 가정할 수 있어서, 셀 단위 판정이 곧 최종 판정이 되기 때문이다. BSP 트리로 레벨을 컴파일하면 잎이 자동으로 볼록 셀이 되므로 이 둘은 역사적으로 늘 붙어 다녔다.
  • 포털: 두 셀을 잇는 뚫린 다각형. 문, 창문, 복도 입구. 방향이 있어서 “셀 A에서 셀 B로 나가는 포털”과 그 반대가 구분된다.
  • 그래프: 셀이 정점, 포털이 간선. 실내 건축물에서 이 그래프는 매우 성기다 — 방 하나에 문이 두세 개뿐이다. 이 희소성이 알고리즘 전체의 성능을 결정한다.

셀 분해를 자동으로 뽑는 것도, 레벨 디자이너가 손으로 포털을 놓는 것도 가능하다. 자동 분해는 축 정렬 벽이 많은 건축 모델에서는 잘 되지만 형상이 자유로워지면 셀이 잘게 부서지는 문제가 있어서, 상용 엔진들은 대체로 디자이너가 문틀 자리에 포털 브러시를 직접 놓는 반수동 방식을 택해 왔다. 어차피 “여기가 방의 경계”라는 판단은 레벨 디자인을 하는 사람이 제일 잘 안다.

3. 재귀 절두체 교집합[편집]

런타임 알고리즘은 놀랄 만큼 짧다.

render(cell, frustum):
    cell 안의 기하를 frustum 으로 컬링해 그린다
    for 각 포털 p in cell:
        if p 가 frustum 밖이면 continue
        f' = frustum ∩ (시점에서 p 의 윤곽으로 만든 사각뿔)
        if f' 가 비었으면 continue
        render(p 의 반대편 셀, f')

시점에서 포털의 각 변으로 평면을 하나씩 세우면 그것이 포털 사각뿔이고, 이걸 현재 절두체와 교집합하면 그 포털을 통해 볼 수 있는 공간이 정확히 나온다. 재귀가 깊어질수록 절두체는 단조적으로 좁아지므로 몇 단계만 지나면 대개 비어 버린다. 문을 세 개쯤 통과하면 보이는 게 없다는 것이 그래프 순회를 저절로 멈춰 준다.

문제는 교집합을 정확히 하면 절두체 평면 수가 재귀 단계마다 늘어난다는 것이다(포털이 사각형이면 단계당 최대 4개씩). 평면 20개짜리 절두체로 물체를 컬링하는 것은 배보다 배꼽이 크다. 그래서 실용적 구현은 거의 전부 보수적 근사를 쓴다.

  • 화면 공간 AABB. 포털을 화면에 투영해 축 정렬 사각형으로 감싸고, 재귀할 때 사각형끼리 교집합한다. 교집합이 사각형 하나로 유지되므로 평면 수가 항상 4개로 고정되고, 판정은 2D 사각형 겹침 검사 몇 번이면 끝난다. 뤼브케와 조지(1995)가 정리한 방식이고, “복잡한 볼록 다각형을 정확히 잘라내느니 사각형으로 대충 감싸고 재귀를 한 단계 더 도는 게 싸다”는 판단이다.1
  • 평면 수 상한. 정확한 교집합을 하되 평면이 kk 개를 넘으면 더 안 자르고 그대로 둔다. 보수적이므로 안전하다.

어느 쪽이든 보수적이라는 것이 핵심이다 — 안 보이는 걸 그리는 손해는 프레임 시간이지만, 보이는 걸 안 그리는 손해는 벽에 구멍이 뚫려 보이는 치명적 버그다.

4. 구현에서 물리는 것들[편집]

  • 사이클. 셀 그래프에는 고리가 흔하다(방 A→B→C→A). 방문 표시를 셀에 찍어 버리면 다른 포털 경로로 보이는 부분을 통째로 놓친다. 같은 셀에 서로 다른 절두체로 여러 번 들어가는 것이 정상 동작이므로, 방문 표시는 (셀, 절두체) 쌍 단위로 생각해야 하고 실무에서는 재귀 깊이 상한과 “이번에 들고 온 절두체가 이전 방문보다 넓지 않으면 가지치기” 같은 조건으로 폭발을 막는다.
  • 중복 제출. 여러 경로로 같은 셀에 도달하면 그 셀의 기하가 여러 번 그려진다. 이번 프레임 번호를 물체마다 찍어 두고 이미 제출된 물체는 건너뛰는 것이 표준 처방.
  • 셀에 걸친 물체. 문틀에 반쯤 걸친 큰 상자는 어느 셀 소속인가. 양쪽에 다 등록하거나(중복 제출 방지 필수), 셀 경계에서 잘라 두거나 둘 중 하나다. 동적 물체는 매 프레임 어느 셀에 있는지 다시 찾아야 하고, 이 조회가 의외로 잔버그의 온상이다.
  • 그림자. 카메라에서 안 보이는 셀의 물체가 보이는 셀에 그림자를 드리울 수 있다. 포털 컬링을 그림자 맵 렌더링에 그대로 쓰면 그림자가 사라진다. 광원 기준으로 별도의 포털 순회를 돌리거나 그림자 캐스터 목록을 따로 관리해야 하며, 그림자 매핑과 컬링을 섞을 때 가장 흔한 사고다.

5. PVS와의 대비[편집]

같은 셀-포털 구조를 쓰면서 계산 시점을 오프라인으로 옮긴 것이 PVS(Potentially Visible Set)다. 각 셀에서 포털 열을 따라 볼 수 있는 셀 집합을 컴파일 때 전부 구해 비트벡터로 구워 두고, 런타임에는 비트만 읽는다. 텔러와 세퀸(1991)이 “포털 열을 관통하는 직선이 존재하는가”를 선형계획법 문제로 정식화해 셀 대 셀 가시성을 정확히 계산하는 방법을 제시했고, Quake의 qvis가 이 계보다.2

포털 컬링(런타임)PVS(전처리)
계산 시점매 프레임맵 컴파일 시
정밀도시점 정확(현재 위치 기준)셀 단위 보수적(셀 어디서든 보이면 포함)
동적 장면문이 닫히면 포털을 끄면 그만정적 가정이 깨지면 무효
메모리셀 그래프만셀 수의 제곱에 비례하는 비트벡터
비용프레임당 순회컴파일에 분~시간

PVS가 “셀 어딘가에서 보일 수 있으면 보인다고 친다”는 보수성을 갖는 반면, 포털 컬링은 지금 카메라가 서 있는 정확한 위치에서 판정하므로 훨씬 촘촘하게 잘라낸다. 대신 매 프레임 값을 치른다. 그래서 실제 엔진은 둘을 겹쳐 쓴다 — PVS로 후보를 대충 추리고, 그 안에서 포털 순회로 더 좁히는 식이다. 소스 엔진의 areaportal이 이 조합의 대표적 사례로, 정적 PVS 위에 문이 닫히면 그 간선을 끊는 동적 포털을 얹었다. 닫힌 문 너머를 통째로 안 그리는 그 익숙한 최적화가 이것이다.

역사적으로는 에어리 등(1990)과 텔러·세퀸(1991)의 건축 워크스루 연구가 셀-포털 개념을 세웠고, Doom(1993)의 2D BSP와 Quake(1996)의 PVS가 이를 상업 엔진에 정착시켰다. 언리얼 엔진 1세대는 BSP 존(zone) 사이를 포털로 잇고 런타임에 재귀 순회를 도는 방식을 썼는데, 90년대 실내 FPS의 그 좁은 복도 레벨 디자인은 미적 선택이라기보다 가시성 알고리즘이 좋아하는 형상이었다는 편이 정확하다.

6. 거울과 워프 — 덤으로 따라오는 것[편집]

포털을 “다른 공간으로 난 창”으로 일반화하면 렌더링 트릭 두 가지가 거의 공짜로 나온다.

  • 거울. 포털의 반대편 셀을 자기 자신으로 두되, 카메라를 거울 평면에 대해 반사시킨 가상 카메라로 바꿔 같은 재귀를 돈다. 마주 보는 거울 두 장이면 무한 재귀가 되니 깊이 제한이 필수. 반사된 장면이 거울 뒤로 새지 않게 하려면 거울 평면을 근평면으로 삼는 사교 절단(oblique near-plane clipping)이 필요하고, 이게 없으면 거울 프레임 바깥으로 반사상이 튀어나온다.
  • 워프 포털. 두 포털을 짝지어 두고, 하나를 통과할 때 카메라를 상대 포털의 좌표계로 변환해 재귀 렌더링한다. 2007년 작 Portal 이 대중화한 그 구조다. 재귀 깊이 nn 이면 포털 안에 포털이 nn 겹 보이고, 대개 3~4단계에서 끊은 뒤 마지막은 정지 이미지로 때운다. 물리적으로도 같은 변환을 물체와 광선에 적용해야 해서, 렌더링보다 충돌·물리 쪽이 훨씬 어렵다.

두 경우 모두 실제로 그리는 부분만 스텐실 버퍼로 제한하는 것이 표준 구현이다. 포털 다각형을 스텐실 마스크에 찍고, 그 마스크 안에서만 반대편 장면을 그린다.

7. 실외에서는 왜 안 되나[편집]

포털 컬링의 전제는 “공간이 벽으로 나뉘고 개구부가 성기다” 하나다. 실외에서는 이 전제가 통째로 무너진다.

  • 셀 경계가 없다. 벌판을 억지로 격자 셀로 나눠도 셀 사이가 전부 뻥 뚫려 있으니, 모든 셀 경계가 화면만 한 포털이 된다. 절두체가 좁아지지 않아 재귀가 안 끝나고, 결국 프러스텀 컬링과 같은 일을 훨씬 비싸게 하는 꼴이 된다.
  • 가림의 성격이 다르다. 실내는 벽이라는 크고 평평한 가림막이 완전히 막지만, 실외는 언덕·나무·건물이 부분적으로 조금씩 가린다. 이런 가림은 개구부로 표현할 수 없고, 지형의 지평선 컬링이나 소수의 큰 가림막을 골라 쓰는 방식이 맞다.
  • 처방. 실외에서는 하드웨어 오클루전 질의, CPU 저해상도 소프트웨어 래스터화, 계층적 Z(Hi-Z) 같은 오클루전 컬링의 일반 도구를 쓰고, 여기에 레벨 오브 디테일과 경계 볼륨 계층 기반 계층 컬링을 얹는다.

현대 엔진에서 포털 컬링의 지분이 줄어든 이유도 결이 같다. 장면이 정적 실내 복도에서 파괴 가능한 오브젝트와 오픈월드로 옮겨가면서, 레벨을 방으로 미리 나눌 수 있다는 전제 자체가 드물어졌다. 그래도 실내 비중이 큰 게임에서는 여전히 유효하며, 특히 디자이너가 직접 통제할 수 있는 컬링이라는 점이 실무에서 크다 — 프레임이 안 나오면 문을 하나 더 놓으면 된다. 자동 오클루전 판정에는 없는 미덕이다.3

8. 관련 문서[편집]

9. Footnotes[편집]

  1. Luebke, D., Georges, C. (1995). “Portals and mirrors: simple, fast evaluation of potentially visible sets”. I3D ‘95. 제목의 “simple, fast”가 논문의 주장 전부다 — 정확한 절두체 교집합 대신 화면 공간 사각형으로 근사하면 코드가 백 줄대로 줄어들고 실측 성능은 오히려 낫다는 것. 그래픽스 논문에서 “대충 해도 된다”를 증명하는 쪽이 정밀하게 하는 쪽보다 인용이 많은 것은 흔한 일이다. ↩

  2. Teller, S., Séquin, C. H. (1991). “Visibility preprocessing for interactive walkthroughs”. SIGGRAPH ‘91. 포털 열을 뚫고 지나가는 직선의 존재 여부를 선형계획으로 판정한다는 발상이 핵심이고, 텔러의 1992년 학위논문이 이를 확장했다. 90년대 맵 제작자가 qvis를 밤새 돌려놓고 자던 그 고통의 이론적 출처. ↩

  3. “왜 이 문이 안 열려요”라는 질문에 “가시성 때문입니다”라고 답하는 레벨 디자이너가 실제로 있었다. 문이 닫혀 있어야 포털을 끌 수 있고, 포털을 꺼야 프레임이 나온다. 게임 레벨의 상당수 잠긴 문은 서사적 장치가 아니라 렌더링 예산의 산물이다. ↩