사기성 컬링 (1/2) |
| programming/graphics 2003/01/18 03:07 |
화이트 데이 만들면서 조금이라도 좀 향상을 시켜보고자 적용했던 거 몇 가지 소개합니다. (글이 없어서 개인 홈페이지에 있던 거 재활용합니다. T_T)
읽어보면 아시겠지만 기발하거나 새로운 건 아니고, 그냥 적당히 게임 개발 상황에 맞춰 적당히 응용해본 것들입니다.
화이트 데이는 BSP 기반으로 만들었고, bsp 장점을 최대한 활용하는 쪽으로 프로그래밍을 했습니다. 여러 가지 이점이 있었지만 PVS (Potential Visibility Sets) 덕도 많이 봤습니다. 하지만 몇 가지 아쉬운 점이 있었습니다.
1. 정적인 정보
PVS 자체가 정적인 환경에 만들어지다 보니 동적인 변화에 따른 변화가 없는 단점이 있습니다. (문이 닫힌 상태와 열린 상태를 생각해보시면 될 거 같습니다.)
물론 각 상황에 따른 Set을 여러 벌 만들면 되겠지만, 화이트 데이의 경우 문만 백 개가 넘기 때문에 시도 자체도 별 의미가 없는 상황이다 보니...
2. 카메라의 방향과 무관하다
PVS가 원래 카메라의 조건과 상관없이 한 영역에서 보일 가능성이 있는 모든 영역들의 리스트를 가지는 것이기 때문에 포탈을 등지고 있을 때에 즉각적인 반응을 할 수가 없습니다.
어차피 프러스텀 컬링 단계에서 떨어져 나가기 때문에 무시했습니다만, 포탈 기반의 컬링을 같이 사용했다면 더욱 좋을 뻔 했습니다. (여기서 얘기하는 것은 PVS 자체가 포탈 기반이 아니라는 얘기는 아니고, 언리얼처럼 레벨 디자이너가 자의적으로 설정해서 프로그래머가 컨트롤 할 수 있는 포탈을 얘기하는 것입니다. - 레벨 디자이너의 추가적인 노가다에 의한 애로사항은 논외로... ^^) 포탈이 보이는 지 체크하는 것으로 그룹에 대해 보인다 안보인다를 결정할 수 있으니 효율적이죠.
3. 분할 영역
BSP의 리프를 베이스로 했기 때문에 좋은 영역 분할의 조건이 PVS에 적합한 조건과 운 좋게 비슷하기를 바라는 수 밖에 없습니다. 물론 만족스러운 정도의 결과를 얻을 수 있었지만, 리프의 크기나 위치에 따라선 좀 더 나눠져서 영역을 분할하고 그 영역에 대한 PVS를 얻었으면 하는 생각이 들더군요. (예를 들어서 현재 위치에서는 A를 볼 수 없지만 한발짝 옆에서는 A를 볼 수 있다고 했을 때, 현재 위치와 한발짝 옆이 같은 영역이라면 현재위치에서도 보인다는 결과를 얻게 되겠죠. 보이는 영역에 대해서도 마찬가지의 상황이 발생하겠죠.)
위의 3가지에 대해서 대부분 만족스러운 결과를 기대할 수 있는 방법은 포탈이라고 생각했습니다만, 프로젝트 진행상 손댈 수 없는 상황이었기 때문에, 구조적인 변형은 지양하고 몇 가지 조건만 추가해서 처리하는 방법에 대해서만 고민을 했습니다.
나름대로 두가지 방법으로 보완을 했는 데, 먼저 포탈 개념을 가져온 것에 대해서 먼저 얘기해보겠습니다. (사기에 가까운... ^^)
당시 배경에 대한 게임 데이타가 모두 나왔기 때문에 별다른 예외상황을 고려할 필요가 없었기 때문에, 비교적 부하가 많다고 생각되는 부분에만 집중해서 최적화를 했습니다.
첨부한 동영상은 실제 사기성 포탈이 적용된 동영상입니다. (포탈 설정된 곳은 특정 조건이 만족하는 위치인데, 이 포탈이 화면에 나타나면 보일만한 모든 것들은 이 포탈을 통해서 두 영역-포탈 저쪽과 이쪽-으로 나눌 수 있기 떄문에, 개발할 때는 절대 포탈이라고 이름 붙였습니다. 하지만 사실 사기에 가까운 설정이기 때문에 여기선 그냥 사기성 포탈이라고 부르겠습니다. ^^)
기본적으로 PVS가 적용된 상태이기 때문에 교실 안쪽은 1차적으로 거의 걸러진 상태입니다.
첫 프레임의 위치는, 카메라가 움직이지 않는 문을 바라보고 있는 위치이긴 하지만, 복도의 오브젝트들이 보이는 리프에 있다고 판단되는 상황입니다. (카메라가 속한 영역이 열린 문 쪽까지 잡혀 있고, 복도의 리프들도 꽤나 커서 그 상황을 예상하실 수 있을 겁니다.)
PVS가 이렇게 나올 수 밖에 없기 때문에 첫프레임의 위치에서는 복도의 오브젝트는 물론 복도 끝에서 수다 떨고 있는 캐릭터까지도 랜더링을 할 수 밖에 없었습니다.
(그래서 원래는 닫힌 문 너머로 오브젝트들이 렌더링 되고 있었습니다.)
그래서 여기에 사기성 포탈을 하나 설정했습니다.(동영상에 빨간색으로 찍히는 부분입니다.)
렌더링 체크 조건이 다음과 같다고 했을 때,
A. PVS 에 의하면 보일 가능성이 있는 위치에 있는 가 ? (NO -> skiprendering)
B. View Frustum 안에 있는 가 ? (NO -> skiprendering)
C. 렌더링 시도
A와 B사이에 다음과 같은 조건을 추가했습니다.
(B, C 사이 라도 큰 차이는 없습니다.)
1. 화면에 사기성 포탈이 있는가 ? (NO -> next rendering step)
2. 사기성 포탈보다 뒤에 있는가 ? (NO -> next rendering step)
3. 사기성 포탈이 닫혀 있는가 ? (YES -> skip rendering)
4. 사기성 포탈을 통해서 보일 가능성이 있는가 ? (NO -> skip rendering)
이 조건을 상기하시면서 동영상을 보시면, 복도의 오브젝트들이 4번 단계에서 렌더링 되지 않게 처리 된다는 걸 보여주는 것이라는 걸 아실 수 있을 겁니다. (만약 왼쪽 문이 닫힌다면 항상 3번을 넘어가지 못하겠죠. )
이 조건은 일반적인 포탈에서 사용하는
1. 속한 영역이 그 영역의 포탈을 통해서 보이는 가 ? (NO 혹은 닫혀있으면 -> skip rendering)
2. 그 포탈을 통해서 화면에 보일 가능성이 있는 가 ? (NO -> skip rendering)
조건과 거의 비슷함을 알 수 있습니다.
우선 포탈이 특별한 조건을 만족하기 때문에 (그 포탈로 완전히 두 공간으로 분할되기 떄문에 단순한 위치 계산으로 체크할 수 있습니다.) 닫혀 있다거나 보일 가능성이 있다거나 하는 조건은 거의 동일하게 적용할 수 있습니다.
약간 특별한 케이스에서만 적용하도록 했기 때문에, 이 방법이 다른 경우에 쓰일 일은 거의 없겠지만, 나름대로는 필요한 부분에 대해서 융통성 있게 다른 알고리즘을 도입하면 좋은 결과를 얻을 수 있다고 생각합니다.
그럼 이 방법이 게임 퍼포먼스 향상에 큰 도움이 되었느냐고 물으신다면, "글쎄요..." 라고 말씀드릴 수 밖에 없지만, 어느 정도의 쾌적한 플레이에 도움이 되었다고 생각합니다. (사실은, 생각하고 싶다고 해야 솔직할 거 같네요. T_T)
비교적 효과가 있던 두번째 방법은 다음에...
ps. 동영상에 오른쪽에 있는 문짝은 안 보이는 게 정상이겠지만, 포탈 저편의 영역인가 체크를 단순히 오브젝트의 바운딩 영역과 하다보니 저편에 있다고 판단이 안 되서 렌더링 되는 것입니다. (애초에 정교한 결과를 얻고자 한 것은 아니었기 때문에 그냥 두었습니다. ^^)
ps. 지금 생각해보면, 그 부분을 portal 식으로 처리하는 거 보단 오클루젼 컬링(언리얼의 안티 포탈)의 개념을 가져와서 막고 있는 벽을 설정해서 처리했어도 꽤 융통성있게 할 수도 있었겠다는 생각이 드네요.
읽어보면 아시겠지만 기발하거나 새로운 건 아니고, 그냥 적당히 게임 개발 상황에 맞춰 적당히 응용해본 것들입니다.
화이트 데이는 BSP 기반으로 만들었고, bsp 장점을 최대한 활용하는 쪽으로 프로그래밍을 했습니다. 여러 가지 이점이 있었지만 PVS (Potential Visibility Sets) 덕도 많이 봤습니다. 하지만 몇 가지 아쉬운 점이 있었습니다.
1. 정적인 정보
PVS 자체가 정적인 환경에 만들어지다 보니 동적인 변화에 따른 변화가 없는 단점이 있습니다. (문이 닫힌 상태와 열린 상태를 생각해보시면 될 거 같습니다.)
물론 각 상황에 따른 Set을 여러 벌 만들면 되겠지만, 화이트 데이의 경우 문만 백 개가 넘기 때문에 시도 자체도 별 의미가 없는 상황이다 보니...
2. 카메라의 방향과 무관하다
PVS가 원래 카메라의 조건과 상관없이 한 영역에서 보일 가능성이 있는 모든 영역들의 리스트를 가지는 것이기 때문에 포탈을 등지고 있을 때에 즉각적인 반응을 할 수가 없습니다.
어차피 프러스텀 컬링 단계에서 떨어져 나가기 때문에 무시했습니다만, 포탈 기반의 컬링을 같이 사용했다면 더욱 좋을 뻔 했습니다. (여기서 얘기하는 것은 PVS 자체가 포탈 기반이 아니라는 얘기는 아니고, 언리얼처럼 레벨 디자이너가 자의적으로 설정해서 프로그래머가 컨트롤 할 수 있는 포탈을 얘기하는 것입니다. - 레벨 디자이너의 추가적인 노가다에 의한 애로사항은 논외로... ^^) 포탈이 보이는 지 체크하는 것으로 그룹에 대해 보인다 안보인다를 결정할 수 있으니 효율적이죠.
3. 분할 영역
BSP의 리프를 베이스로 했기 때문에 좋은 영역 분할의 조건이 PVS에 적합한 조건과 운 좋게 비슷하기를 바라는 수 밖에 없습니다. 물론 만족스러운 정도의 결과를 얻을 수 있었지만, 리프의 크기나 위치에 따라선 좀 더 나눠져서 영역을 분할하고 그 영역에 대한 PVS를 얻었으면 하는 생각이 들더군요. (예를 들어서 현재 위치에서는 A를 볼 수 없지만 한발짝 옆에서는 A를 볼 수 있다고 했을 때, 현재 위치와 한발짝 옆이 같은 영역이라면 현재위치에서도 보인다는 결과를 얻게 되겠죠. 보이는 영역에 대해서도 마찬가지의 상황이 발생하겠죠.)
위의 3가지에 대해서 대부분 만족스러운 결과를 기대할 수 있는 방법은 포탈이라고 생각했습니다만, 프로젝트 진행상 손댈 수 없는 상황이었기 때문에, 구조적인 변형은 지양하고 몇 가지 조건만 추가해서 처리하는 방법에 대해서만 고민을 했습니다.
나름대로 두가지 방법으로 보완을 했는 데, 먼저 포탈 개념을 가져온 것에 대해서 먼저 얘기해보겠습니다. (사기에 가까운... ^^)
당시 배경에 대한 게임 데이타가 모두 나왔기 때문에 별다른 예외상황을 고려할 필요가 없었기 때문에, 비교적 부하가 많다고 생각되는 부분에만 집중해서 최적화를 했습니다.
첨부한 동영상은 실제 사기성 포탈이 적용된 동영상입니다. (포탈 설정된 곳은 특정 조건이 만족하는 위치인데, 이 포탈이 화면에 나타나면 보일만한 모든 것들은 이 포탈을 통해서 두 영역-포탈 저쪽과 이쪽-으로 나눌 수 있기 떄문에, 개발할 때는 절대 포탈이라고 이름 붙였습니다. 하지만 사실 사기에 가까운 설정이기 때문에 여기선 그냥 사기성 포탈이라고 부르겠습니다. ^^)
기본적으로 PVS가 적용된 상태이기 때문에 교실 안쪽은 1차적으로 거의 걸러진 상태입니다.
첫 프레임의 위치는, 카메라가 움직이지 않는 문을 바라보고 있는 위치이긴 하지만, 복도의 오브젝트들이 보이는 리프에 있다고 판단되는 상황입니다. (카메라가 속한 영역이 열린 문 쪽까지 잡혀 있고, 복도의 리프들도 꽤나 커서 그 상황을 예상하실 수 있을 겁니다.)
PVS가 이렇게 나올 수 밖에 없기 때문에 첫프레임의 위치에서는 복도의 오브젝트는 물론 복도 끝에서 수다 떨고 있는 캐릭터까지도 랜더링을 할 수 밖에 없었습니다.
(그래서 원래는 닫힌 문 너머로 오브젝트들이 렌더링 되고 있었습니다.)
그래서 여기에 사기성 포탈을 하나 설정했습니다.(동영상에 빨간색으로 찍히는 부분입니다.)
렌더링 체크 조건이 다음과 같다고 했을 때,
A. PVS 에 의하면 보일 가능성이 있는 위치에 있는 가 ? (NO -> skiprendering)
B. View Frustum 안에 있는 가 ? (NO -> skiprendering)
C. 렌더링 시도
A와 B사이에 다음과 같은 조건을 추가했습니다.
(B, C 사이 라도 큰 차이는 없습니다.)
1. 화면에 사기성 포탈이 있는가 ? (NO -> next rendering step)
2. 사기성 포탈보다 뒤에 있는가 ? (NO -> next rendering step)
3. 사기성 포탈이 닫혀 있는가 ? (YES -> skip rendering)
4. 사기성 포탈을 통해서 보일 가능성이 있는가 ? (NO -> skip rendering)
이 조건을 상기하시면서 동영상을 보시면, 복도의 오브젝트들이 4번 단계에서 렌더링 되지 않게 처리 된다는 걸 보여주는 것이라는 걸 아실 수 있을 겁니다. (만약 왼쪽 문이 닫힌다면 항상 3번을 넘어가지 못하겠죠. )
이 조건은 일반적인 포탈에서 사용하는
1. 속한 영역이 그 영역의 포탈을 통해서 보이는 가 ? (NO 혹은 닫혀있으면 -> skip rendering)
2. 그 포탈을 통해서 화면에 보일 가능성이 있는 가 ? (NO -> skip rendering)
조건과 거의 비슷함을 알 수 있습니다.
우선 포탈이 특별한 조건을 만족하기 때문에 (그 포탈로 완전히 두 공간으로 분할되기 떄문에 단순한 위치 계산으로 체크할 수 있습니다.) 닫혀 있다거나 보일 가능성이 있다거나 하는 조건은 거의 동일하게 적용할 수 있습니다.
약간 특별한 케이스에서만 적용하도록 했기 때문에, 이 방법이 다른 경우에 쓰일 일은 거의 없겠지만, 나름대로는 필요한 부분에 대해서 융통성 있게 다른 알고리즘을 도입하면 좋은 결과를 얻을 수 있다고 생각합니다.
그럼 이 방법이 게임 퍼포먼스 향상에 큰 도움이 되었느냐고 물으신다면, "글쎄요..." 라고 말씀드릴 수 밖에 없지만, 어느 정도의 쾌적한 플레이에 도움이 되었다고 생각합니다. (사실은, 생각하고 싶다고 해야 솔직할 거 같네요. T_T)
비교적 효과가 있던 두번째 방법은 다음에...
ps. 동영상에 오른쪽에 있는 문짝은 안 보이는 게 정상이겠지만, 포탈 저편의 영역인가 체크를 단순히 오브젝트의 바운딩 영역과 하다보니 저편에 있다고 판단이 안 되서 렌더링 되는 것입니다. (애초에 정교한 결과를 얻고자 한 것은 아니었기 때문에 그냥 두었습니다. ^^)
ps. 지금 생각해보면, 그 부분을 portal 식으로 처리하는 거 보단 오클루젼 컬링(언리얼의 안티 포탈)의 개념을 가져와서 막고 있는 벽을 설정해서 처리했어도 꽤 융통성있게 할 수도 있었겠다는 생각이 드네요.
댓글을 달아 주세요
위치에 중대한 일은 그것을 좋아했다!
좋은 위치! 너를 감사하십시요.
KASA에서 듣고 여기서 한번 더 보기 이해가 확실히 빠르게 되네요.
좋은 정보 얻어 갑니다~^^*
중대하고 유용한 위치!
여보세요, 아주 좋은 위치!
좋은 위치! 너를 감사하십시요.
그런 경이롭 위치를 위해 많게의 감사!
위치에 중대한 일은 그것을 좋아했다!
위치에 중대한 일은 그것을 좋아했다!