검색결과 리스트
분류 전체보기에 해당되는 글 27건
- 2010.05.20 SIZE_OF_ARRAY
- 2010.04.29 C# Event 사용법
- 2009.12.22 Hashing 사용 방법 및 주의사항
- 2008.11.15 윈도우 자동 로그온
- 2008.03.12 VF5 리얼타임 3D 그래픽스 1
- 2008.03.11 메모리 공간 스택, 힙, 스태틱(코드,데이터)
- 2008.03.11 [펌]프로세스 메모리 구조
- 2008.03.08 크레이지 범프
글
SIZE_OF_ARRAY
1. #define SIZE_OF_ARRAY(x) (sizeof(x) / sizeof(x[0]))
2. _countof()
글
C# Event 사용법
글
Hashing 사용 방법 및 주의사항
Hash 를 사용할때는 한가지를 명심하자.
Hash 자체는 검색의 키로서 이용되지만, 키 자체가 유니크하다고 볼 수 없다.
Hash 키를 통한 검색은 Hash에 해당하는 버킷(데이터의 배열 또는 리스트)의 첫번째를 의미한다고 보면된다.
즉, Hashing 함수를 거쳐 생성된 Hash 를 통해 검색을 한다음, Hashing 에 사용된
키값을 다시 비교하여야만 올바른 결과를 얻을수 있다.
글
윈도우 자동 로그온
- 시작 -> 실행 -> regedit 를 입력하여 레지스트리 편집기를 실행한다.
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon
- DefaultUserName 사용자ID 입력
- DefaultPassword 비밀번호 입력. 항목이 없으면 문자열 값으로 새로만들기
- AutoAdminLogon 문자열 값을 새로 만든 후 값을 1로 설정
글
VF5 리얼타임 3D 그래픽스
■ PC 기반 아케이드 시스템으로 실현되는 리얼타임3D 그래픽스
이번에는 연재 최초로 아케이드 게임을 다룬다. 아케이드 게임 시스템 기판으로 PC를 사용하는 것이 유행하여, 지난번에 열린 제44회 어뮤즈먼트머신쇼에서는 타이토가 최신 PC시스템인 코어2듀오 + 인텔Q965(PCI-Express)기반의 'TAITO Type X2'를 발표하는 등, 이 흐름은 계속되고 있다.
▶ '린드버그'기판. 뒷면에는 PC에서 보던 익숙한 단자들이 늘어서있다
사담-한국은 '펌프잇업'으로 이미 1999년도에 PC기반 기판인 Mk-3를 완성하였고, 이후 2001년 완성된 Mk-5를 이용하여 세계 최초 PC 연동 아케이드 네트워크 게임인 '아크쉐이드'를 제작한 바 있음. 이후 이 PC 기반 아케이드 시스템은 바다이야기로 대표되는 경마장, 릴게임을 서비스하는 성인 오락실의 부흥을 가져옴. ...이라고 누가 좀 말해줘.
이번에 발매된 세가의 초히트 3D 격투게임 '버쳐파이터5(VF5)'역시, 작년 발표된 세가의 PC 기반 시스템 기판인 '린드버그(LNDBERGH)'를 기반으로 작동한다. 린드버그의 게임 타이틀로는 1인칭 건슈팅 게임 '하우스오브더데드4(HOD4)', 테니스 게임인 '파워스매시3' 등이 있다.
아케이드 게임 시스템 기판이 PC 아키텍쳐로 옮겨온데는 몇 가지 이유가 있다. 첫째, 범용 부품으로서 PC 부품을 이용할 수 있어 시스템 코스트를 낯출 수 있는 것. 둘째, 이미 잘 알려진 PC 하드웨어의 지식이나 개발 환경을 이용할 수 있으므로 소프트웨어 개발 난이도가 낮아진다는 점이다. 또한, 플레이스테이션3나 XBox360과 같은 차세대 게임기가 PC의 유전자를 계승한 프로그래머블 아키텍쳐를 채용한 것에서 알 수 있듯(CPU의 차이는 여전히 존재), 그래픽스적인 측면에서 상호 이식성이 높다는 점 역시 큰 장점이다.
'린드버그'의 스펙 -펜티엄4(3GHz), 메인 메모리 1GB-는 PC의 관점에서 보면 초고급 사양은 아니지만, Windows와 같은 대규모 범용 OS를 사용하지 않고, 게임 컨텐츠에만 거의 풀 파워를 할애할 수 있는 아케이드 시스템임을 고려하면, 성능적으로 볼 때 충분히 타당하다고 볼 수 있다. 사용하는 OS에 대해서는 비공개. GPU에 대해서는 '셰이더 모델(SM)3.0 세대에 대응하는 NVIDIA의 GPU'라고 한다.
어쨌든, 이 사양은 2006년의 사양이며, 타이토의 'TypeX2'와 같이, 린드버그도 사양 확장이 가능한 PC 시스템의 우위성을 살려, 코어2듀오+PCI-Express 시스템으로 이행할 가능성은 부정할 수 없다.어쨌든, 이 사양은 2006년의 사양이며, 타이토의 'TypeX2'와 같이, 린드버그도 사양 확장이 가능한 PC 시스템의 우위성을 살려, 코어2듀오+PCI-Express 시스템으로 이행할 가능성은 부정할 수 없다.
사담-버쳐파이터 시리즈의 기판은 모델1, 2, 3 모두 NVIDIA의 GPU를 사용한 바 있다. 이번 린드버그 기판에 사용된 제품은 GeForce 7800에 사용된 GPU와 같다고 한다.
국내에서 Mk 보드 시리즈 개발시, Mk-3(셀러론 300Mhz)보드가 Mk-4보드(펜티엄3 800MHz) 진화한 이유는 개발 스펙상의 필요 사항이기도 했지만, 당시 단종으로 인해 더 이상 기존의 CPU확보가 어려워졌기 때문이기도 하다. 같은 이유로 4GB면 충분한 하드디스크의 용량은 10GB의 스펙으로 오버되기도 하였다.
■ 60fps 유지가 절대 조건이었던 VF5의 그래픽스
VF5의 그래픽스 테크놀러지에 상세히 접근하기 전에, VF5의 그래픽스 사양에 대해 우선 살펴보도록 하자. 대담하게 비유하자면, VF시리즈 뿐만 아니라 대전 격투 게임은 1/60초 단위로 끊임 없이 가위바위보를 하는 형태의 게임이다. 이 때문에, frame rate(화면 갱신율)이 일정하지 않으면 행동 조건에 불균형이 생겨 불공평한 상황이 생기게 된다. 때문에, 화면 갱신율을 철저히 지켜나가며 설계하는 것이 중요하다.
VF5는 PC를 기반으로 한 시스템 기판으로 그래픽스를 구현하기 때문에, OpenGL 기반으로 만들어지고 있다. 이와 같이 API를 끼고 있기에 하드웨어의 상태를 정확히 알 수 없는, 말하자면 직접 게임 어플리케이션 측을 관리할 수 없을 것만 같은 시스템상에서 화면 갱신율의 유지는 쉽지 않은 일이라 생각한다.
야마노우치 타케시
"60fps 유지가 최우선 과제라는 생각으로 임했습니다. 그래픽스에 병목이 생겼을 경우, 그 원인이 어디에 있는지 알 수 없는 문제에 고민했습니다. NVIDIA측으로부터 OpenGL 기반의 퍼포먼스 분석기가 제공되기 전에 프로젝트를 시작해버렸기 때문에, 이것은 우리가 제작해서 사용했습니다."
카토 타카시
"OpenGL에 명령어를 주고 나서 실제로 GPU가 그려낼 때 까지의 과정을 API 레벨에서는 파악할 수 없기 때문에, 처음에는 고생했어요. 최종적으로는 60fps 유지를 실현할 수 있었습니다. 위에서는 '60fps를 유지하지 못하면 잘라버린다!'고 말 할 정도였습니다(농담)."
캐릭터 하나당 9만5천개의 버텍스를 사용하며, 셸프 셰도우를 위해 2번 렌더링 한다(기본 렌더링을 포함하여 일반적인 경우의 3배가 된다)
VF5의 렌더링 해상도는 1280x768 픽셀 정했고, 이것을 리얼 720p의 HD급 모니터에 출력하고 있다. 통체에 사용하는 디스플레이 패널은 화면 크기나 소비전력등을 감안하여 액정으로 하였고, 그 중에서도 최고 해상도의 액정 패널을 선택했다고 한다. 잔상이 적고, 플레이어로부터 평판도 최고, 최대 해상도는 1366x768 픽셀. 하지만 렌더링 해상도와 패널의 최고 해상도가 다르다. 이것은 어찌된 일인가?
야마노우치
"렌더링 해상도는 1280x768 이므로 1366x768의 화면에 출력할 때는 수십 픽셀의 빈 영역이 생기게 됩니다. 어째서 1280x768이라고 묻는다면, 개발 환경을 모두 1280x768에 맞춰둔 상태였고, 만약 가로폭이 1366픽셀이 되어도 양 옆 43픽셀실 표시되지 않아도 문제가 없다고 판단했기 때문입니다."
1280x768 화면에서 60fps를 유지하고, 게다가 복수의 셰이더를 가동시키면서 렌더링한다는 것은 대단히 어려운 일일 것 같은 이미지. 게다가 앞서 말한 바와 같이 린드버그는 PCI-Express가 아닌 AGP 버스 시스템이므로 꽤 빠듯할 것 같은 느낌이 든다.
카토씨
"GPU의 병목 현상은 버스 측면보다 픽셀 부하 쪽이 더 컷습니다. 이것을 모든 조건하에 60fps를 유지할 수 있도록 튜닝 해 나갔습니다."
"개발 초기에는 GeForce FX 5900으로 했는데, 이때는 꽤 고생했습니다(웃음).최종적으로SM3.0을 사용하게 되어 좋았습니다.목표는 단일 플랫폼이니까 이식같은 건 생각하지 않고(웃음), 스펙을 모두 사용하는 느낌으로 제작하고 있습니다"
카토 타카시씨(CRI 미들웨어, 연구 개발부, 그래픽스 프로그래머)
"CRI 미들웨어에서 세가로 파견된 그래픽스 프로그래머 입니다. VF5는 OpenGL 2.0 기반으로 개발되었습니다. 지금은 PS3판 VF5를 개발하고 있습니다"
■ 3D 격투 게임이기에 가능했던 인간 LOD 시스템?
VF5는 3D 격투 게임이지만, 플레이어는 모자나 의상, 악세서리와 같은 아이템을 이용하여 캐릭터를 꾸밀 수 있다. 많은 아이템을 몸에 부착한 캐릭터는 당연히 렌더링 부하가 증가해 픽셀 부하가 높아진다.
야마노우치씨
"개발단계에서는 아이템을 잔뜩 붙인 캐릭터끼리 싸우면 화면 갱신율이 떨어지거나 해서 걱정이었습니다(웃음)."
VF5에서는 던지기 기술이 시작되면, "던지기 카메라"라고 불리는 시네마틱 촬영 기법으로 기술의 애니메이션을 보여주는 연출로, 캐릭터가 클로즈업 된다. 이 경우, 캐릭터가 크게 그려저 셰이더가 많은 픽셀에 적용되기 때문에 부하가 높아진다. 이와 같이, 상황에 따라 부하가 변하기 쉬운 그래픽스에서는 퍼포먼스를 평준화하기 위해서 통상 LOD(Level of detail) 시스템을 도입하는 경우가 많다.
게다가 최근 3D 게임 그래픽스에서는, 렌더링 하는 오브젝트와 카메라간의 거리를 판단해 셰이더의 종류를 바꾸는 "셰이더 LOD" 테크닉도 사용되고 있다. 즉, 카메라 시점으로부터 가깝고 크게 보이는 캐릭터는 풍부한 셰이더를 이용하여 렌더링하지만, 멀리 있는 작게 보이는 캐릭터에는 부하가 적은 간이 셰이더를 적용하는 기법이다.
하지만 VF5가 화면 갱신율 지상주의로 만들어졌다고는 해도, 60fps 유지를 위해 다이나믹 LOD 시스템을 사용하지는 않는다. VF5와 같은 3D 격투 게임은 기본적으로 카메라가 두 사람의 플레이어 캐릭터를 계속 비추고 있으므로, 평상시에는 LOD를 사용할 만큼 화면에 보이는 캐릭터 크기가 변할 일이 없기 때문이다. 멀리 있는 배경(원경)은 언제까지나 멀리 있다. 따라서, 원경에는 그만한 폴리곤을 할애하며, 셰이더 역시 적당한 품질로 적용해 가까이에 있는 배경(근경)이나 캐릭터에게 많은 폴리곤을 할애하고 셰이더 역시 고품질로 적용한다... 와 같은 원칙으로 만들고 있다.
야마노우치씨
"말하자면, 미리 사람이 LOD를 해둔다는 듯한 느낌일까요."
앞서 말한 바와 같이 렌더링 부하가 바뀌는 상황이 있을 수도 있지만, '아이템을 많이 장착했을 때', '던지기 기술로 카메라가 가까워졌을 때', 등등 부하가 많아지는 예측하여 상정할 수 있기 때문에, 이러한 경우에도 60fps를 유지할 수 있게 조정한다면 '최고 품질의 비주얼'과 '화면 갱신율 유지'라는 두마리 토끼를 잡을 수 있는 실마리가 보인다는 것이다.
■ VF5의 폴리곤 예산은 VF4의 4배!
VF5는 OpenGL API를 이용하여 그래픽스 프로그래밍을 하고 있지만, 셰이더 프로그래밍에는 OpenGL 기반의 셰이더 어셈블러 언어인 'ARB 어셈블러'를 사용한다. 그리고 OpenGL로는 부족한 특수 상황에 대해서는 직접적인 GPU 제어를 위해, OpenGL을 위한 NVIDIA의 확장 명령어(NV Extension)도 구사하고 있다.
린드버그를 이용해 개발한다고 해서 반드시 이렇게 해야하는 것은 아니고, 'HOD4'에서는 OpenGL Shader Language(GLSL)을 이용하거나, '파워스매시3'에서는 NVIDIA의 High Level Shader Language(HLSL)인 'Cg'를 사용하기도 한다. PS3는 OpenGL/ES를 채용하면서도 표준 셰이더 언어로는 'Cg'를 사용하고 있기때문에, VF5를 PS3로 이식하는데는 다소 고생했다... 라는 말도 들려온다. 덧붙여 PS3로 '파워스매시3'를 이식하는 부분은 그만큼 폈있다고 한다. 현 시점에서는 셰이더 설계를 위한 언어가 다른 것도 있고, 그 만큼 많은 셰이더를 만들지 않은 이유로 각 개발 팀 끼리의 셰이더 공유는 하지 않고 있다고 한다.
야마노우치씨
"그렇다고는 해도, 다른 팀에서 멋져보이는 셰이더가 돌아가고 있으면, 파워스매시3 팀 쪽에 모여 '이거 어떻게 만들었어?' 같은걸 물어보러 다니기는 했어요(웃음)."
폴리곤 수가 전부는 아니지만, VF4와 VF5의 폴리곤 사용 수는 얼마나 차이가 나는 것일까?
마키노씨
"VF4때는 한 캐릭터당 1만2000 폴리곤 정도였고요, VF5의 경우 한 캐릭터당 대략 4만개 정도 사용하고 있습니다."
무라이씨
"배경의 경우, VF4에는 대략 5만개 전후, VF5라면 대게 10만~30만 폴리곤 정도입니다. 스테이지에 따라 많이 다릅니다."
"VF5에서는 주로 배경, 스테이지의 디자인을 담당했습니다. 배경에는 노멀맵을 사치스럽게 사용할 수는 없었습니다만(웃음), 퀄리티는 절대로 떨어뜨리고 싶지 않았기 때문에 사용할 수 있는 기능과 기술을 모두 포함시키려고 노력했습니다. 나무 한그루, 책 한권도 모두 손수 만든 것입니다. 배경쪽도 눈여겨 봐주세요."
"VF5에서는 캐릭터의 그래픽 디자인을 담당했습니다. 질감이라든지, 꽤 신경써서 만들얼기 때문에 플레이중에도 그러한 부분들이 잘 보일 수 있다면 기쁠 것 같습니다."
VF4는 드림캐스트 아키텍쳐의 최종형이라 할 수 있는, 'NAOMI2' 기판으로 돌아가고 있던 작품이다. 하드웨어 기반의 지오메트리 엔진을 쓰고 있었으므로 당시로서는 최고의 폴리곤 성능이었지만, 시대가 지남에 따라 GPU는 진화하게 되었고 이에 따라 3배 정도의 폴리곤을 사용할 수 있게 되었다. 따라서 VF5에서는 폴리곤수에 크게 구애받지 않고 디자인 개발을 진행했다고 한다. 확실히 최근의 다른 PC 게임과 비교해서도 VF5의 폴리곤수는 꽤 많다고 느껴진다.
PC 게임에서는 NVIDIA의 SM3.0 대응 GPU로 한정해도 GeForce6200부터 7950GX2에 이르까지 그 타겟의 폭이 넓다. 타겟 하드웨어마다 최적의 3D모델을 만드는 것은 개발비나 데이터 크기와 직결되므로, 대개 그 시대의 중급 하드웨어에서 처리할 수 있는 정도의 폴리곤수로 3D 모델 디자인을 하는 경우가 많다. 그리고 게임 실행 도중 비교적 유연하게 컨트롤 가능한 텍스쳐, 셰이더, 그림자, 해상도, 포스트프로세스와 같은 부분에서 퀄리티와 퍼포먼스간의 밸런스를 조정할 수 있게 설계한 경우가 많다.
VF5는 타겟 GPU 스펙이 고급 하드웨어로 고정되어있기때문에, 비교적 풍부한 지오메트리 디자인을 실현할 수 있었다. 덧붙여 PS3나 Xbox360용 타이틀 쪽의 그래픽스의 폴리곤 모델이 평균적인 PC 게임보다 높다고 느껴지는 것도 같은 이유때문이다.
마키노씨
"폴리곤 수에서부터 텍스쳐 메모리 용량이라던가, 셰이더를 어느정도 적용하면 어느정도 부하가 걸리는지... 라던가, 그런 부분에서 고민이 많았지요."
■ 그림자 생성은 뎁스 셰도우 기법 + 스크린 스페이스 필터 프로세스를 조합한 비전의 기법으로
VF5 시리즈 최초로 셸프 셰도우 방식으로 그림자 생성를 하고 있다. 움직임이 격렬한 게임이므로 쉽게 눈치채기는 힘들지만, 차분히 응시해보도록 하자. 목에서부터 머리까지의 그림자가 어깨에 떨어지고, 얼굴의 요철에서도 그림자가 생기는 경우가 있다. 치켜 든 팔의 그림자가 자기 자신의 몸에 투사되고, 그러한 그림자가 상대 캐릭터나 배경에도 드리워지며, 입고 있는 의상의 그림자가 캐릭터의 맨살에도 비춰진다. 이른바 간이 그림자 생성 방식이 아니라 꽤 처리 능력이 요구되는 그림자 생성 방식인 것이다. 또한, 최신 유행인 소프트 셰도우 처리도 적용되고 있어, 현실 세계의 그림자에 가까운 윤곽선이 희미한 형태로 보인다. VF5는 "셰도우 맵 기법(뎁스 셰도우)"을 그림자 생성의 기본 메소드로 이용하고 있다.
이 기법에는 약점이 하나 있다. 카메라에 가까운 곳에 발생한 그림자에는 부족한 셰도우 맵 해상도로 인해 앨리어싱이 발생한다는 점이다.
이 약점을 극복하기위해 뎁스 셰도우 기법에서는 지금까지 여러가지 개선 시도가 있었다. 3DMark05의 Perspective Shadow Maps (PSM) 기법, 이니스사의 XDox360 테크니컬 데모에서는 Light-Space Perspective Shadow Maps (LSPSM) 기법, 3DMark06에서는 Cascaded Shadow Maps (CSM) 기법이 사용되어 각각 독특한 관점으로 약점 극복을 위해 도전하고 있다. 또, 올해 SIGGRAPH2006에서는 노스캐롤라이나 대학이 Logarithmic Shadow Maps (LOGSM)을 발표하고 있어 화제를 모았다. VF5의 그림자를 보면 그다지 눈에 띄는 앨리어싱이 없는데, 어떠한 방식으로 접근한 것일까?
마키노씨
"VF4에서는 로우 폴리곤 모델을 따로 준비해 스텐실 셰도우 볼륨 기법으로 그림자를 생성했었습니다만, VF5에서는 뎁스 셰도우 기법으로 새롭게 바꾸었습니다. 셰도우 맵의 해상도는 1024 x 1024 텍셀입니다."
카토씨
"이 정도의 셰도우 맵 한장으로는 도저히 앨리어싱을 피할 수 없기 때문에, 우리는 다소 변형된 테크닉을 개발해넣어 뎁스 셰도우 기법의 약점이 보이지 않도록 눈속임할 수 있었습니다."
뎁스 셰도우 기법 자체는 이론 그대로 넣었지만, 우선 뎁스 셰도우에 의한 앨리어싱이 포함된 그림자가 들어간 프레임을 생성해, 이 프레임을 바탕으로 2D 기반(화면 좌표계)의 흐릿한 마스킹 프레임을 생성한다. 다시 말해 그림자지는 부분과 빛이 드는 부분을 나눈 부분을 추출하는 프레임을 만든 후 이것을 흐릿하게 만들어 마스킹한다. 그리고 최종적으로 셰이더나 텍스쳐를 적용한 다른 프레임과 그림자 프레임을 섞어서 마스크를 합성하여 '소프트 셀프 셰도우'를 만들어낸다.
▶ 필터링 전의 셰도우 마스크를 사용한 게임 화면. 셰도우 맵 특유의 지글거림이 눈에 띈다
◀ 필터링 후의 셰도우 마스크 화면
▶ 필터링 후의 셰도우 마스크를 사용한 게임 화면. 지글거림이 해소되고 그림자 윤곽이 희미해졌다
이 기법의 특징은, 뎁스 셰도우 기법의 앨리어싱을 '2D 화상 처리'로 지워버리는 접근방식이라는데 있다. SM3.0 세대의 GeForce 계열의 소프트 셰도우라고 하면, '스프린터 셀3'에서 사용된 픽셀 셰이더의 조건분기명령인 적응형 멀티 샘플 기법을 구사하는 편이 스마트하다고 생각되기도 하지만....
야마노우치씨
"우리도 그 기법은 사실 개발 초기 단계에서 적용하여 시험해 보았습니다. 그렇지만. 씬의 그림자 생성 상황에 따라 연산 부하가 계속 바뀌게 되어서 60fps 사수라고 하는 목적을 이루기에는 적합하지 않았습니다."
카토씨
"우리가 사용하는 이 방법이라면 한결같이 대략 1ms의 시간이 걸리기 때문에, 근본적으로 연산 부하를 항상 일정하게 유지할 수 있습니다."
단지, '던지기 카메라' 연출시나, 오프닝 데모와 같이 캐릭터가 클로즈업 되는 경우에는 샷에서는 지글거림이 나타나는 것이 보일 수도 있다. 너무 카메라가 가까워져 앨리어싱이 커졌을 경우에는 이 VF5마스크 방식의 뎁스 셰도우 기법에서도 지우지 못한다.
▶ 린드버그는NVIDIA 의 GPU 베이스이므로, VF5의 뎁스 셰도우 생성시 NVIDIA SHADOW 기능(하드웨어PCF:Percentage Closer Filter )를 활용하고 있다
■ 그림자 생성은 사실 두가지 방식
VF5에서 그림자를 생성하기 위해 사실 위와 같은 방식만을 사용하는 것은 아니다. 화면을 보는 것 만으로는 그 차이를 알기가 어렵지만, 각 캐릭터에 의해 지면에 생기는 그림자는 사실 뎁스 셰도우 기법으로 생성되는 것이 아니다. 지면에 생기는 가장 눈에 띄는 그림자는, 예전부터 사용하던 간이 그림자 생성 방식인 실루엣 프로젝션 텍스쳐 매핑 방식을 사용하고 있다.
실루엣 프로젝션 텍스쳐 매핑은 뎁스 셰도우의 원형이라고도 할 수 있는 것으로, 그림자 생성원의 광원 위치에서 본 캐릭터의 실루엣(윤곽 형태)를 텍스쳐로 생성해, 이것을 광원부분의 프로젝터로부터 영상을 투영하듯 텍스쳐 매핑(프로젝션 텍스쳐 매핑) 하는 방식으로 구현된다. 부하가 적기때문에 PS2 게임에서 폭넓게 활용된 바 있으며, PC게임에서도 RPG나 RTS 장르에서는 아직도 사용하는 경우가 많은 기법이다. 프로젝션된 실루엣에서 거리가 먼 머리 부분으로 가면 갈 수록 흐릿하게 필터링하여 리얼한 프로젝션 그림자를 만들어낸다.
정리하자면, VF5는 마스크 뎁스 셰도우 기법과 실루엣 프로젝션 텍스쳐 매핑 이 두가지 기법을 조합하여 그림자를 생성하고 있다.
카토씨
"지면에 떨어지는 그림자는 가장 존재감이 크기 때문에 이것은 별도 생성하기로 하였습니다. 뎁스 셰도우로 만들면 다소 지저분해보이기 때문이죠."
무라이씨
"먼 배경의 그림자는 리얼타임으로 생성하지 않고, 오프라인에서 프리렌더로 구워서 만든 그림자이고, 그림자 생성 방식은 이와 같이 적재적소에 구분하여 사용하고 있습니다."
또한 배경 우브젝트의 그림자의 경우에도, 벽이나 책과 같이 존재감이 있는 오브젝트의 경우에는 뎁스 셰도우 기법에 의해 생성된 그림자가 두 명의 캐릭터에게도 제대로 떨어지도록 하고 있다. 만족스러운 화면을 만들기 위해 단일 기법을 사용하는 것이 아니라 여러가지 기법을 조합해 사용한다는 점은 일본의 장인정신적인 측면에서 접근한 것이라 할 수 있다.
■ 장인의 기술 : 인간 셰이더와 프로시졀 텍스쳐
VF5에서는 VF4보다 폴리곤 수가 많아지고, 그림자 생성도 확실히 하고 있지만, 그 뿐만 아니라 세세한 질감의 표현이 매우 리얼해보인다. 마치 프로그래머벌 셰이더를 구사하여 특수한 셰이더를 사용한 것처럼 보이는데, 실제로는 어떨까.
마키노씨
"기본적으로는 디퓨즈 맵, 스펙큘러 맵, 그리고 노멀 맵을 사용한 범프 맵핑입니다."
야마노우치씨
"피부, 머리카락, 옷에 대해선는 그래픽 디자이너의 센스에 의해 위와 같은 요소를 조정하여 사실적으로 보이게 한다는 느낌입니다. 사실적으로 보인다는 것은 그래픽 디자이너 역량의 승리라고 할 수 있죠(웃음)."
기본적으로, '디퓨즈, 스펙큘러, 노멀맵'의 3가지 요소로 구성되지만, 확실히 특별하게 커스터마이즈 된 셰이더도 있다고 한다. 예를 들면, 아키라의 도복의 올록볼록한 엠보싱은 노멀 맵에 의한 범프 맵핑으로 표현하고 있지만, 어깨 부분의 '흐릿하게 해어진' 부분은 노멀맵 + 알파 값을 사용하는 투명도 합성으로 만들어진다. 또, 물이 나오는 스테이지에서 옷이 젖으면, 젖은 것을 표현하기 위한 파라미터가 적용되어 젖어보이게 하는 것도 표현되고 있다.
독특한 점은, 파이의 차이나 드레스와 같이 번들번들한 독특한 이방성 반사(보는 각도에 의해 밝기나 색이 바뀌어 보이는)를 이용한 질감의 실크 공단 천에 대한 표현 방법. 환경 맵 표현에 사용하는 이방성 반사를 주변 배경을 반사 굴절하는데만 사용하지 않고 옷감의 소재를 반영하여 이것을 환경맵으로 적용한 뒤, 디퓨즈 스펙큘러를 조정하는 꽤나 커스터마이즈 된 형태로 사용하고 있다.
마키노씨
"물리적으로 올바른 처리 방법인지는 잘 모르겠습니다만, 그럴싸해 보입니다. 평소에 툴을 이용하여 이런저런 실험을 하다보면 가끔씩 무언가에 사용할 수 있을 것만 같은 질감을 우연히 만들어낼 수 있을 것 같은 느낌을 받아 그것을 저장해두고, 실재로 사용해 보았더니 이러한 결과가 나왔다고 할 수 있습니다."
그런데, 캐릭터 중심의 격투 게임이므로 확실히 피부의 질감 처리가 두드러질 수 밖에 없다. 피부에 특화된 셰이더를 '스킨 셰이더'라고 분류하기도 하는데, 의외로 VF5에서는 특별히 제작된 스킨 셰이더는 사용하지 않았다. 기본적으로 스펙큘러의 조정으로 피부의 신선함이나 땀의 느낌을 표현하고 있어, 이른바 서브 서페이스 스캐터링(SSS-표면하부 산란)셰이더와 같은 특수 처리는 집어 넣지 않았다. 피부도 다른 소재와 같이 기본 셰이더의 조정으로 그럴싸해 보이게 하고 있다.
"이것 저것 해보려고는 생각했습니다만, 솔직히 정확한 스킨 셰이더를 넣는 것은 퍼포먼스적으로 어렵네요."
마키노씨
"하지만 여자 캐릭터 한정으로 특별한 처리를 하고 있어요. 여자 캐릭터에게는 안보이는 반사판이 붙어서 돌아가고 있습니다(웃음)."
여성 캐릭터는 음영이 두드러지거나 셀프 셰도우가 강하게 생기면 미인도(?)가 떨어져보여서 보이지 않는 리플렉스 카메라판(광원을 반사하는 판)을 설정하여, 얼굴의 음영이 잘 나타나지 않도록 라이팅을 조정하고 있다. 반대로 남자의 경우 음영이 강하게 나오는 것이 멋있어보이기 때문에 특별히 그러한 처리는 하지 않는다고 한다. VF5의 여자 캐릭터는 '여배우 취급'으로, 시스템 레벨에서 라이팅에 신경 쓰고 있는 것이다.
VF5의 캐릭터 묘사를 주의 깊게 보면, 광원이 화면 안쪽에서 바깥(카메라)쪽을 향하고 있는 역광 상황의 씬에서는, 원래는 그림자가 표현되어야 할 곳에 피부의 윤곽 부분이나 옷의 윤곽으로부터 빛이 새어 나오는 표현을 볼 수 있다. HDR 렌더링으로 인해 빛이 넘쳐나오는 경우와는 달리 마치 서브 서페이스 스캐터링(SSS-표면하 산란)과 같은 느낌을 받을 수 있다.
이러한 '역광에서 번들거리는 표현'은 '광원 위치가 역광'일 때 '그 표면의 노멀 방향을 판단해 역광 위치에 있는 광원 효과를 표현할 수 있다'는 일정 조건을 충족할 때, '카메라에서 볼 때 외곽선 부분에서 빛이 넘쳐나오게 하는'처리를 한 뒤 거기에 광원의 색상을 블랜딩해서 렌더링하는 방식으로 구현하고 있다. NVIDIA에서 GeForce7800시리즈를 발표할 때 공개한 'Luna'라는 데모로 구현된 유사 SSS에서는 오브젝트의 두께를 계산하여 빛이 어느정도 새어나올지를 정하는 형태로 표현하지만, VF5에서는 그러한 복잡한 처리는 생략하고 있다.
VF5의 '역광 번들거림'은 간이 처리방식이므로 불규칙한 경우 즉, 셀프 셰도우로 그림자가 떨어진 부분에서도 빛이 새어나온다거나 하는 상황적인 에러도 있었다고 한다. 하지만 이러한 경우는 그래픽 디자이너 쪽에서 파라미터를 조정하면서 부자연스럽지 않은 정도로 억제하였다.
대단히 간소한 방식의 유사 SSS 처리이지만, 씬 전체적으로 보면 꽤 좋은 느낌으로 마무리 지어졌다. 머리, 뺨, 손이나 목덕미같이 피부가 투명한 느낌을 내는 것은 물론, 옷에도 같은 처리가 적용되므로 '옷감이 그다지 두껍지 않다' → '부드러운 옷감일 것이다'라는 이미지가 전해져 온다.
야마노우치씨
"이 빛의 표현을 만끽하고 싶은 사람은 슌이나 레이페이 같은 대머리 캐릭터를 주목해주세요. 대머리의 경우 매우 찬란하게 빛나고 있습니다(웃음)."
액체 금속과 같은 질감을 보여주는 라스트 보스 듀랄의 경우에는 다소 예외적으로 특별한 셰이더를 사용하였다고 한다. 듀랄의 질감은 4가지가 있는데, 이중 출현 조건이 낮은 2가지의 경우에 특별한 셰이더를 사용한 것이다.
박막 간섭 표현(역주-CD와 같은 광학 미디어의 기록면이나 프리즘을 통해 볼 수 있는)의 듀랄의 경우 카메라 각도나 주위의 배경에 의해 신비한 무지개빛 광택을 발하는 질감으로 표현하고 있으며, 이 질감 표현에는 텍스쳐를 사용하지 않았다. 버텍스 셰이더를 이용해 빛의 회절(Diffraction)을 시뮬레이션하여 이 무지개빛을 산출한다. 및은 색에 따라 파장이 다르지만, 그 다른 파장의 빛 사이에서 일어나는 간섭을 픽셀 단위로 계산한 결과로 최종적인 색을 결정하여 표현하는 것이다. 현재 3D 게임에서 실용적으로 구현하기 위한 연구가 진행되고 있는 '계산을 통해 텍스쳐를 생성하는 새로운 메소드'인 '프로시졀 텍스쳐(Procedual Texture)' 기법을 어느정도 미리 구현한 예라고 할 수 있다.
야마노우치씨
"이러한 빛의 회절 계산에는 굴적 벡트의 계산도 포함되어 있습니다만, '기왕 굴절 벡터 계산을 하고 있는 김에 빛을 굴절시키는 듀랄도 만들어보자'는 생각에서 완성된 것이 굴절 듀랄입니다."
굴절 듀랄은 필요에 의해 만들어진 굴절 벡터를 활용하여 듀랄을 제외한 렌더링 부분의 프레임으로부터 샘플을 얻는 것 만으로 실현된 것이다. 덧붙여서, 이 두가지 소재의 듀랄은 일정 조건을 만족하지 않으면 등장하지 않기 때문에 열심히 플레이해야 볼 수 있다.
■ 업계 최초!? 수면 표현에 텍스쳐링(VTF)을 디스플레이스 맵핑을 사용
VF5의 그래픽스에서 눈길을 끄는 것 중 하나는 바로 수면 표현이다. VF5의 수면은 크게 나누어 두 가지 방식으로, 하나는 깊이가 얕은 '웅덩이' 그리고 다른 하나는 비교적 수위가 높은 '물가'다. 수위가 낮은 웅덩이에 대한 수면 표현은 비교적 전통적인 접근방식을 택하고 있다. 수면에 비치는 것을 미리 저장된 저해상도의 텍스쳐에 넣어뒀다가 '반사 맵(≒환경 맵)'으로 사용하는 방식으로 구현한다.
이 웅덩이의 수면에는 단지 주위의 배경이나 캐릭터가 비칠 뿐만 아니라, 흔들리는 파문도 그려진다. 이 파문은 수위의 요철을 나타내는 하이트 맵을 파동 시뮬레이션해서 다이나믹하게 생성하며, 이 정보로부터 노멀 맵을 생성하고, 이것과 앞서 말한 반사 맵과 함께 사용해 최종적으로 환경 범프 맵핑을 구현한다.
파동 시뮬레이션이라고 하면 어쩐지 어려워보이지만, 실제 구현 방식은 기본적으로는 심플하다. 구체적으로는 그 시점에서의 물의 높이, 속도, 힘 3가지 요소를 텍스쳐에 저장해서, 이러한 정보로부터 다음 상태의 수면 높이를 계산한 텍스쳐를 다시 생성하며, 이 처리는 픽셀 셰이더가 실행하므로 CPU는 개입하지 않는다. 산출된 수면의 높이 값은 요철을 나타내는 하이트 맵 텍스쳐로 취급하며, 이것을 노멀 맵으로 변환해 환경 범프 맵핑으로 사용하는 것이다.
플레이에 열중하다보면 그냥 지나칠지도 모르지만, 캐릭터가 물에 다리를 넣으면 그 진동으로 파문이 퍼지는 연출이 계속되고 있다. 이것은 파동 시뮬레이션용의 텍스쳐에 그 캐릭터의 발자국 형태의 힘이 가해진것으로 다음 텍스쳐의 갱신에 영향을 준다.
그리고 다소 수위가 높은 '물가'에서는, 버텍스 레벨에서 수면이 위아래로 물결치는 애니메이션이 더해진다.
카토씨
"이 수면의 메시 모양이 바뀌는 파동 애니메이션은 NVIDIA의 GeForce6, 7시리즈에만 탑재된 버텍스 텍스쳐링(Vertex Texture Fetching)을 사용해 구현했습니다.
이 말에 다소 놀랐다. 그렇다. VTF는 현시점에서는 거의 사용되지 않는, 말하자면 맹장과도 같은 존재이기 때문이다. VTF는 버텍스 셰이더에서 텍스쳐를 참조할 수 있도록 한 기능. 텍스쳐라면 보통 이미지라고 하는 선입견이 있지만, 프로그래머블 셰이더 시대에 들어서는 텍스쳐의 활용 방법이 혁신적으로 변화하여 용도에 따라서는(셰이더 프로그램의 설계에 따라서는) 범용 벡터 데이터 배열 용도로 활용하는 경우도 많아지고 있는 추세다. 그렇다면 픽셀 셰이더 뿐만 아니라, 버텍스 셰이더에서도 텍스쳐를 범용 기억 영역으로 활용하고 싶다는 요망이 생기는 것 역시 자연스러운 흐름. 이 요망을 구현한 것이 VTF 기능이다.
◀ 높낮이를 기록한 하이트맵 텍스쳐를 VTF 기능을 이용, 버텍스 셰이더로 읽어내고, 이 값을 바탕으로 실제 지오메트리를 변이 시키는 처리를 디스플레이스먼트 맵핑(변위 맵핑)이라 한다
업계 최초의 SM3.0 대응 GPU인 GeForce 6800 시리즈가 발표될 당시, VTF는 'SM3.0 로만 표현 할 수 있는 대망의 기능'이라며 흥분되게 소개되었다. 그런데 그 후 라이벌인 ATI의 RADEON X1000 시리즈가 VTF를 지원하지 않는 상태로 등장하였고, ATI vs NVIDIA의 싸움 끝에 VTF는 마치 맹장과 같이 되어버렸던 것이다. 여담이지만, ATI가 VTF 기능을 추가하는 것을 별로 꺼려하는 것은 아니다. ATI가 디자인한 Xbox 360의 GPU는 VTF를 지원하고, 차세대 DirectX 10의 SM4.0에 대응하는 ATI의 GPU 역시 VTF를 지원할 것으로 확실시되고 있다. 물론 PS3의 GPU인 'RSX'는 GeForce 7800GTX 기반이므로 VTF는 확실히 지원한다.
야마노우치씨
"우리의 타겟 하드웨어는 린드버그 하나 뿐이기 때문에, 그 하드웨어의 기능을 모두 활용해도 됩니다. VTF는 편리해요. 오히려 없으면 울게될걸요(웃음). CPU에 부하를 주지 않고 기본적인 지오메트리 프로세싱이 GPU만으로 해결할 수 있다니 훌륭합니다."
파동 시뮬레이션은 32비트 부동 소수점(FP32) 텍스쳐를 이용해 픽셀 셰이더로 한다. 앞서 본 '웅덩이'에서는 정수 텍스쳐로 파동 시뮬레이션을 하지만, '물가'에서는 FP32 텍스쳐를 사용한다. 이유는 단순하다. VTF는 FP32 텍스쳐만 지원하기 때문이다.
FP32 텍스쳐 형태로 생성한 하이트 맵을 VTF와 픽셀 셰이더로 읽어들여 수면의 버텍스를 변이 시키는 변위 맵핑(Displacement Mapping)한다. 또한 이 FP32 파동 하이트 맵을 노멀 맵으로 변환하고 이를 이용해 픽셀 셰이더로 음영 처리한다. 이 시점에서 연구할만한 아이디어가 생각났다고 한다.
카토씨
"회사 근처에서 도시락을 사면 된장국이 딸려옵니다만, 그 된장국이 들어있는 컵을 흔들면서 생각난 아이디어입니다(웃음). VTF와 함께 사용하는 FP32 파동 하이트 맵에는 물결의 높이라던지 속도와 힘의 정보가 있으므로, 모처럼이니까 픽셀 단위의 라이팅을 할 때 이 정보를 활용하여 농담을 주어 탁함이나 투명한 느낌을 살렸습니다. VF5에 나오는 더러운 물의 표현은 이런 식으로 구현되고 있습니다."
야마노우치씨
"팀내에서는 '된장국 셰이더'라고 이름붙여 사용했지요(웃음)."
현재 상태로서는 폴리곤을 자동 분할하는 테셀레이터가 GPU에 내장되어 있지 않기 때문에 (DirectX 11 세대에는 내장될 가능성도 있다), VTF 그리고 변위 맵핑을 적용할 때, 해당 모델측의 버텍스 수(이 경우는 수면의 버텍스 수)를 미리 분할해 두어야 한다. VF5의 수면의 버텍스 수는 100x100 해상도로 미리 쪼개져 있다.
이 '물가'에서 역시 캐릭터가 움직이면 파동 시뮬레이션용 텍스쳐를 변화시키므로 캐릭터의 움직임에 따라 물결이 출렁이게 된다. 앞에서 본 웅덩이보다 다이나믹해서 시각적인 임펙트가 꽤 강하다.
카토씨
"발차기를 하는 등 물을 감아올릴 때는 물보라가 발생합니다. 이쪽을 눈여겨보면 VTF는 물방울의 충돌을 텍스쳐를 이용해 픽셀 셰이더로 검출해 내서, 물방울 하나 하나가 수면에 떨어질 때 파문이 발생하도록 만들었습니다. 아마 눈치채고 있는 사람은 얼마 없을 것이라 생각합니다만(웃음)."
물보라 자체의 물방울 하나 하나가 지오메트리를 가진 파티클로, 캐릭터의 다리가 수면에 닿을 때와 마찬가지로 일일히 상호 작용한다. 파동 시뮬레이션 용으로 사용하는 FP32 파동 하이트 맵에 적절한 시뮬레이션용 초기 설정치(높이, 속도, 힘)을 설정한다. 카토씨가 말하는 것과 같이, 눈에 띄는 일은 아니더라도 '왠지 모르게 전체적으로 리얼'해보이는 글로벌한 리얼리티를 살리는데는 매우 도움이 된다.
■ 눈밭에도 VTF를 사용한다!
이러한 VTF에 의한 변위 맵핑은 눈밭을 만드는데도 응용되고 있다. 수면의 물결과 같이 움직이지는 않지만, 쌓여있는 눈을 캐릭터의 발로 밟으면 FP32 텍스쳐로 만들어진 하이트 맵이 캐릭터의 발자국 모양으로 눌리게 되어, 결과적으로 발자국 형태로 패인 눈밭이 렌더링 되는 형태.
또한 눈밭의 음영 표현에는 간이 SSS 시뮬레이션도 사용하고 있다. 일전에 ATI가 발표한 바 있는 텍스쳐 스페이스의 블러 기법을 사용하는 것이다. 설원에 비춰지는 광량(실질적인 샤이니니스, 스펙큘러)를 텍스쳐에 렌더링한 뒤, 텍스쳐 좌표계상에서 블러링 해서 뿌옇게 만드는 처리를 거친다. 바꿔 말하자면, 눈밭의 요철에 생기는 스펙큘러를 정확히 위쪽 정면에서 촬영해둔 뒤 그 사진을 흐릿하게 만드는 처리를 거친 이미지라 할 수 있다.
▶ 오른쪽은 유사 SSS 적용 후
카토씨
"VTF로 눈밭의 높이를 변이시키고 있는데, 높은 곳은 스펙큘러가 많이 적용되어 반짝반짝 빛나지만 낮은 곳에 있는 눈의 표면은 대부분 디퓨즈에 의한 음영 처리를 하고 있습니다."
밟히지 않은 눈 표면은 반짝반짝 빛나 새로 내린 느낌을 주지만, 밟혀서 낮아진 눈은 밟혀 짜부러진 샤베트 같이 더러워진 느낌으로 표현한다.
카토씨
"스노우보드를 좋아해서 작년 시즌에 가서 사진을 찍어두고 연구했죠(웃음)."
■ 세가의 VTF 활용도는 세계 1위!?
야마노우치씨
"VTF를 잔뜩 사용했습니다."
VTF는 포그 표현에도 응용된다. 다소 핀트가 어긋난 말일 수도 있지만, 가장 일반적인 포그는 카메라에서 멀어질 수록 풍경을 흐리게 만드는 거리 포그(Distance Fog)다. 이와 별도의 경우, '안개'나 연기가 자욱하게 깔려있거나, 그것이 바람에 날리는 표현을 하는 경우에는 반투명한 '안개' 텍스쳐나 연기 텍스쳐를 붙인 파티클 스프라이트를 겹쳐서 렌더링하고 이를 애니메이션 시킨다. 이것만 있다면 그럴싸해 보이지만, 판투명을 여러번 사용하기 때문에 연산 부하가 걸리는 것과 다른 3D 모델과 겹쳤을 때 날카롭게 그 경계면이 드러나버리는 단점이 있다. 따라서 VF5에서는 다소 독특한 'VTF 포그'라는 것을 고안해 구현했다.
물가의 수면 처리에는 수면의 높이를 그레이 스케일로 표현한 하이트맵을 활용하는 것과 같이, VTF 포그에서는 FP32 텍스쳐에 안개의 농담 정보를 저장한다. 즉, 안개의 농담 분포를 FP32 텍스쳐를 이용해 표현하는 것이다. 팀내에서는 이것을 '포그 맵'이라 부르기로 했다.
실제 렌더링시에는 물가의 수면과 같이 스테이즈 바닥에 평행하게, 즉 수평으로 보이지 않는 면을 배치하고 이 보이지 않는 표면의 각 버텍스로부터 해당 포그 맵의 VTF를 잠조해 가져온 값을 버텍스 컬러로 이용해 '포그의 농담'을 표현한다. 즉, VTF와 포그 맵에서 가져온 정보로부터 높이 포그(Y FOG) 처리를 버텍스 단위로 실행한다.
이 방법을 사용할 때 포그의 최종적인 컬러 산출시에 선형 합성을 1회 실시해주면, 반투명에 의해 겹쳐 그리는 렌더링은 전혀 불필요해진다. 비교적 저렴한 처리로 복잡한 안개의 농담 표현을 바닥에 쫙 펼칠 수 있는 것이다. 게다가 이 포그맵을 스크롤시키면, 복잡한 농담의 안개가 바람에 의해 흐르는 것 처럼 그럴싸해 보인다.
카토씨
"여기서 끝이 아닙니다. 예를 들다면 울프의 자이언트 스윙가 같은 기술을 사용할 때는 이 '안개'가 휙휙 어지럽게 흩어지는 효과까지 보여줄 수 있습니다."
캐릭터가 수면에 영향을 미칠 때와 마찬가지 방법으로, 캐릭터의 행동에 따라 포그 맵이 상호작용 하는 것이다. 대단히 재밌다.
야마노우치씨
"이렇게 사라진 안개는 다시 자동적으로 흘러 들어와 보충되는 형태의 포그 맵 애니메이션이 적용되고 있습니다."
■ VF5에는 FP16 기반의 리얼 HDR 렌더링을 사용 : 톤 맵핑에도 VTF를 활용!
하이 다이나믹 레인지 렌더링(HDRR)은 최신 3D 게임의 그래픽스 트랜드다. VF5 역시 당연하다시피 HDR렌더링을 활용하고 있으며, 렌더 타켓 버퍼는 αRGB 각 16비트 부동 소수점(FP16)의 64 비트 버퍼(이하 FP-64 비트)를 채용하고 있다.
카토씨
"처음에는 환경 맵이나 반사 맵과 같은 텍스쳐도 FP16-64 비트 버퍼로 만들었습니다만, 두말 할 나위 없이 이러한 텍스쳐는 패치(읽어들이는 시간)가 오래 걸립니다. 따라서 텍스쳐는 αRGB 각 8비트의 평범한 정수 포맷을 사용하고, HDR 렌더링의 결과 고휘도가 되는 경우에는, 알파 부위에 추가적인 휘도 정보를 넣는 테크닉을 사용했습니다."
VF5 개발 현장 기준으로, FP16-64 비트의 렌더링은 반투명을 사용하면 약간 반응이 늦어지기도 했었지만, 그보다 FP16-64 비트 텍스쳐를 읽어들이는 시간이 오래걸리고, 렌더링 파이프라인에도 병목이 생기기 쉬웠다고 한다.
이 상태에서도 고휘도 부분의 정보가 사라지지 않은 것을 볼 수 있다
"FP 텍스쳐의 패치는 아마도 필터링 속도 부분이 느리지 않나 생각합니다. 다소의 코드 추가가 있지만(FP16-64 비트 텍스쳐를 필터링 첨부로 읽는 것 보다는), HDR 정보를 인코딩, 디코딩해서 정수 텍스쳐를 사용하는 방식 쪽이 더 빨랐습니다."
PC게임 중에서는 HDR FP16-64 비트 텍스쳐를 사용한 타이틀도 발매되고 있지만, PC 게임의 경우는 화면 갱신율이 가변적이라도 크게 문제될 것이 없기 때문에 할 수 있었던 것. VF5와 같이 60fps가 생명인 게임에서 '풀 HDR 파이프라인 설계'를 사용하는 것은 다음 세대 GPU에서나 가능할 것 같다.
HDR 렌더링으로 완성된 HDR 프레임은 그 상태 그대로는 FP16-64 비트 버퍼이며, 이를 RGB 각 8비트인 컬러 시스템을 사용하는 디스플레이 장치에서는 바로 표시할 수 없다. 따라서 이것을 RGP 각 8비트 컬러 시스템으로 조정하는 포스트 프로세스(후 처리)를 거친다. 이 때, HDR 프레임의 휘도량을 산출하고, 실제로 그 HDR 씬에 있는 캐릭터나 카메라 위치에 따라 적정 휘도로 보정하는 처리인 톤 맵핑(Tone Mapping) 처리를 하는 것이 일반적이다. 덧붙여, 이러한 HDR 프레임에 대한 라이팅 시뮬레이션과 같은 포스트 프로세싱 범위까지를 포함하여 HDR 렌더링이라 부르기도 한다.
톤 맵핑에서 까다로운 부분은 해당 HDR 프레임의 적정 휘도를 찾는 처리다. HDR 프레임을 CPU쪽으로 보내서 계산하거나 다시 한번 픽셀 파이프라인으로 보내 픽셀 셰이더를 사용하거나...하는 방법 외에도 몇가지 수법이 있지만, 어쨌든 조금 불필요해보이는 수고와 시간이 소요된다. 따라서 VF5에서는 이 톤 맵핑 처리를 독특한 방법으로 하여 이러한 문제를 줄이려는 시도가 이루어지고 있다. 무려 여기까지 VTF를 사용해서 대략 1 패스분의 처리를 단축하고 있는 것이다.
1x1픽셀까지 축소한 HDR 프레임을 텍스쳐로 이용하고, 이 텍스쳐를 VTF 기능을 사용해 버텍스 셰이더쪽에서 읽게 하여 영상의 평균 휘도를 버텍스 파이프라인 쪽에서 계산해 버린다. 그 결과를 톤 맵핑용 정수 이용하여 픽셀 파이프라인(픽셀 셰이더)에게 전달해주면 CPU를 사용하지 않으므로 불필요한 렌더링 파이프라인을 돌아가지 않고 톤 맵핑을 구현할 수 있다.
톤 맵핑에 의해서 적정 휘도로 화면이 조정될 때 까지는 서서히 밝기가 변화하는 형태로 카메라나 눈동자 조리개가 조여지는 듯한 느낌을 모방하고 있다. 역광 상태의 씬이나, 실내의 어두운 씬에서 잘 관찰해보면 이러한 연출을 볼 수 있다.
■ 물리 시뮬레이션 엔진은 자체 제작
물리 시뮬레이션 엔진은 세가 자체 제작품으로, 'VF4'의 담당자가 계속 담당하고 있어, 기본적인 설계 역시 VF4로부터 계승되고 있다. 충돌 판정을 위한 충돌체(컬리젼 메시) 설정은 기본적으로 캐릭터 한명의 로컬 영역의 충돌을 검출하기 위한 것으로, 서로 다른 캐릭터간의 충돌은 고려하지 않았다. 로컬 충돌이라고 하면 구체적으로 옷, 머리카락, 머리띠, 아이템 장착 등으로 인한 악세서리가 캐릭터의 몸통을 뚫지 않도록 하는 충돌 처리.
마키노씨
"충돌체는 기둥과 같은 것으로 만들고 있습니다. 머리띠와 같이 긴 것은 여러개의 관절로 되어 있는 것입니다만, 그럴싸해보이도록 우리 그래픽 디자인 팀에서 조정하고 있습니다."
▶ 시험삼아 녹색 충돌체를 크게 해보면 머리띠의 뼈가 이에 따라 큰 원을 그리며 내려간다
◀ 격자 무늬의 선이 그려진 부분이 천(cloth) 시뮬레이션이 적용되는 부분
▶ 앉았을 때에 천 시뮬레이션이 적용되어 스커트가 자연스렵게 변형된 모습을 볼 수 있다
맞은 펀치 방향에 따라 다른 쪽으로 날아간다던지, 하중을 실어서 펀치나 킥을 날리면 데미지가 커지는 것과 같은 물리 시뮬레이션을 격투 시스템에 포함시키려는 시도는 하지 않는 것일까?
야마노우치씨
"할 수 없지는 않습니다만, 그렇게 해서 팔린다면 그렇게 만들거에요(웃음). 단지 'VF'시리즈라고 하기는 어려울 것 같습니다. VF 시리즈에는 이럴 때는 이렇게 된다는 규칙이 있고 그에 따라 콤보가 정해진다 라는 암묵적인 게임의 룰이 있으니까요."
옷, 아이템, 머리카락, 악세서리는 지형이나 수면에 대한 충돌을 검출하고 있다. 예를 들어 다운되었을 때의 머리띠는 물에 뜨고, 긴 머리카락이은 지면에 파고들지 않으며 지면에 퍼지도록 되어있다.
VF5는 만들거나 캡쳐한 모션인 캐릭터 애니메이션을 플레이어의 조작이나 일정한 조건이 성립하면 재생하는 구조로 만들어져 있고, 리얼타임 물리 시뮬레이션을 적용하여 자세를 제어하는 일은 하지 않고 있다. 이것은 '게임으로서' VF 시리즈의 절대 룰을 지키기 위한 것이라고 한다.
야마노우치씨
"VF3때는 IK(Inverse Kinematics : 역방향 운동학)을 살린 게임성을 추가했었습니다. 스테이지의 단차라던가 경사로 인한 높이 차이가 있을 때 캐릭터가 이를 따라 움직이는 것을 당시의 프로그래머가 열심히 구혔앴습니다. VF4에서는 그렇지 않게 되었습니다만."
■ 정리
린드버그만을 위해 만들었기에 그 잠재력을 120% 살려서 그래픽스를 디자인해 나갔다는 경위가 흥미롭다. 특히 개발 타겟 GPU가 NVIDIA 제품이었기에 PC 게임 업계에서는 아무도 뒤돌아 보지 않았던 VTF 기능을 참신한 아이디어로 풀 활용하고 있는 것이 매우 독특하다.
하지만 '60fps 사수'라는 명제를 해결하기 위해서 셰이더의 부하를 낮추고 그 설계를 심플하게 했다는 것은 예상 외의 사실이었다. 디퓨즈, 스펙큘러, 노멀 맵이라는 기본 요소 뿐이지만 그래픽 디자이너의 센스와 아이디어를 발휘해 장인 정신으로 '그럴싸해 보이는 질감'을 만들어낸 것은 '일본이 아니었다면' 힘들었을 것 같다.
또한 '60fps 사수'를 철저히 하기 위해 자칫 생략하기 쉬운 그림자 부분을 확실히 생성하고 있다. 이것을 넣기 어려운 부분이 많았겠지만 '다른 나라에 질 수 없다'고 하는 '일본 기술자로서의 고집'과 같은 것이 느껴진다.
야마노우치씨는 'VF5는 애초에 그래픽스를 앞세운 작품은 아닌데요(웃음)' 이라고 겸손하게 말하고는 있지만, 아케이드 게임의 리얼타임 3D 그래픽스로서 향후 틀림없이 벤치마크 할 만한 존재로서 레퍼런스화 되어 갈 것이다.
현재 VF5는 아케이드에서 가동중이다. 게임센터에 들렀을 때는 부디 이러한 선진 그래픽스를 보아주었으면 한다. 또한 PS3 판 이식도 진행중이며 아케이드 버전을 제작한 팀과의 정보 공유를 통해 열심히 개발중이다. 동경 게임쇼 2006에서 PS3 버전 VF5의 플레이 가능한 버전이 공개되었는데, 그래픽스적인 측면에서 해상도 1280 x 720 임에도 불구하고 그림자의 앨리어싱을 줄이는 정도로 높은 이식도를 보여주고 있다. 이쪽 역시 기대된다.
(C) SEGA
http://www.virtuafighter.jp
글
[펌]프로세스 메모리 구조
프로세스에 대한 이해는 프로그래밍의 핵심이라고 할 수 있다. 프로세스는 간단하게 '수행중인 프로그램'이라고 정의할 수 있다(참고로 프로그램은 수행 가능한 디스크상의 이미지라고 정의할 수 있다). 다시 말해, 프로세스는 디스크에 저장돼 있던 실행 가능한 프로그램이 메모리에 적재돼 운영체제의 제어를 받는 상태를 말한다.
프로그램을 작성해 컴파일하고 링크하면 실행 가능한 파일이 생성된다(윈도우라면 *.exe라는 파일이, 유닉스라면 기본적으로 a.out이라는 파일이 생성된다). 쉘을 통해 사용자가 프로그램을 수행시키면, 커널은 이 프로그램을 제어에 적합한 자료구조로 만들어 메모리로 읽어낸 후, 커널의 프로세스 테이블에 등록하고, 메모리, 파일, 입출력 장치 같은 자원을 할당하는데, 이때부터 프로그램은 커널의 한 프로세스로서 실행 상태가 된다.
프로세스는 Win32의 경우에 CreateProcess(), 유닉스의 경우에는 fork() 시스템 콜을 사용해 새로운 프로세스를 생성하고, 프로세스간에는 다양한 IPC(Inter-Process Communication) 방법을 통해 데이터를 교환하거나 프로세스간의 동기화를 수행한다.
<그림 1>은 프로그램이 메모리에 적재된 모습을 나타낸다. 이 구조는 유닉스와 윈도우가 크게 다르지 않다 (JVM에서 돌아가는 자바 프로그램도 비슷한 구조를 갖는다). 그림에서 위쪽이 낮은 주소번지가 된다. 그림에서 보이는 네 개의 범위(텍스트, 데이터, 힙, 스택)를 각각 세그먼트라고 한다.각 세그먼트에 대해 좀더 자세하게 알아보자(여기서는 유닉스와 C를 기준으로 서술하지만, 윈도우에서도 공통적인 특성을 갖는다).
◆ 텍스트 : 프로그램의 실행 코드인 기계어 코드와 읽기 전용 데이터 등을 가진다(CPU가 읽어들여 수행한다고 해서 텍스트라고 부르며, 코드 영역이라고도 한다).
◆ 데이터 : C언어에서 전역 변수, 정적 변수 등으로 선언된 변수 영역(읽기/쓰기 가능)
◆ 힙 : 프로그램 수행 중 malloc(), free() 등의 시스템 콜로 할당되고, 해지되는 메모리 영역
◆ 스택 : C언어의 함수 호출시 지역 변수와 인수, 함수의 수행이 끝났을 때 리턴할 주소(return address)를 푸시한다(함수가 끝나면 이 값을 팝하고 리턴하게 된다).
운영체제는 프로그램의 텍스트 부분에 메모리를 읽기 전용으로만 사용하고, 프로세스간에는 메모리 영역을 침범하지 못하도록 한다. 따라서, 프로그램의 텍스트로 되어 있는 메모리 영역을 침범해 기록하면 버스 에러나 세그먼트 결함이 일어나서 프로그램이 종료된다. 여러분은 윈도우에서 '잘못된 연산을 수행해 프로그램을 종료합니다'란 메시지를 본적이 있을 것이다. 이 에러(잘못된 연산)의 95% 이상이 바로 앞서 이런 연유에서 발생한다.
C/C++와 같이 포인터(주소를 갖는 변수)를 사용해 메모리를 직접 액세스하는 언어로 개발할 때도 흔히 이와 같은 에러가 발생한다. 따라서 프로그램을 개발할 때 가장 중요한 점이 바로 메모리 관리다. 프로그램 오류의 80% 이상을 차지하는 이유를 살펴보면 다음과 같다.
◆ 초기화
◆ 해지
자바는 가비지 컬렉션을 통해 사용하지 않는 메모리를 자동으로 해지하지만, 필요에 따라 명시해 주는 것이 좋다. C/C++에서는 쓰지 않는 메모리에 대해 반드시 명시적으로 delete를 써줘야 한다.
C/C++는 할당된 메모리에 대한 포인터를 잃어버리는 경우가 생기는데, 이를 메모리 누수라고 한다.
메모리 누수는 프로그래머를 괴롭히는 가장 큰 골칫거리 중 하나다. 꼼꼼히 확인하는 습관을 들이는 것이 좋다.
멀티로 시작하는 단어의 사용
멀티 프로그래밍, 멀티 프로세싱, 멀티 태스킹, 멀티 쓰레드, 멀티 유저는 비슷비슷한 용어이기 때문에 혼돈해 사용하지만 의미가 모두 다르다.
◆ 멀티 프로그래밍 : 여러 프로그램이 메모리에 적재돼 수행되는 것. 하나의 프로그램이 수행되다가 입출력을 하면 CPU는 다른 프로그램으로 제어권을 넘긴다. 즉, 프로그램의 입출력을 기준으로 프로그램 수행의 스위칭이 일어난다(요즘은 좀처럼 쓰이지 않는 말이다).
◆ 멀티 프로세싱 : 다수의 프로세서가 작업을 처리하는 것. 운영체제가 멀티 프로세싱을 지원한다는 것은 다수의 CPU를 지원할 수 있다는 뜻이다. 여러 CPU가 운영체제와 메모리를 공유해 프로그램을 수행하는 방식을 SMP(대칭형 멀티 프로세싱)라고 한다(윈도우 NT가 이런 방식이다).
◆ 멀티 태스킹(시분할 시스템) : 태스크(Task, 운영체제가 수행하는 기본 단위)가 여럿인 것. 운영체제가 강제로 CPU 시간을 프로세스에 할당한다.
◆ 멀티 유저 : 멀티 유저는 기본적으로 멀티 태스킹이 되는 시스템에 다중 사용자 파일 시스템 등 다중 사용자를 지원하기 위한 기능을 추가한 것이다.
◆ 멀티 쓰레드 : 하나의 프로세스 내에 여러 개의 수행경로가 존재하고, 이를 동시에 수행하는 것. 하나의 프로세스가 동시에 두 가지 이상의 작업을 수행하는데 활용된다(쉽게 말해 프로세스 내에서 멀티 태스킹을 하는 것이라고 볼 수 있다).
여기서 멀티 쓰레드에 대해 좀더 구체적으로 알아보자. 쓰레드는 '수행 경로'라고 정의할 수 있다.
CPU가 텍스트(코드)를 읽어 수행할 때 수행되는 절차를 하나의 수행 경로라고 한다. 멀티 쓰레드란 결국 이런 수행 경로가 여러 개 있다는 뜻이다. 멀티 쓰레드도 멀티 태스킹과 마찬가지로 기본적으로 여러 쓰레드를 번갈아 수행한다. 텍스트, 데이터, 힙, 스택의 각 세그먼트에 대한 주소를 CPU 레지스터에 담고 있는데, 이 레지스터의 내용을 바꿔(컨텍스트 스위칭) 다른 쓰레드를 수행하도록 한다. 쓰레드 간에 프로세스가 갖고 있는 메모리와 코드 영역을 공유하므로, 컨텍스트 스위칭할 때 레지스터의 내용을 조금만 바꿔도 멀티 태스킹에 비해 컨텍스트 스위칭 하는 속도가 빠르다.
멀티 태스킹이나 멀티 쓰레드는 두 개 이상의 작업이 동시에 수행되므로, 동시에 수행되는 작업에 대해 동기화가 필연적으로 필요하다.
자바는 언어 차원에서 동기화를 지원한다. synchronized 키워드를 이용해 손쉽게 동기화를 구현할 수 있지만, 꼭 필요할 때만 사용하는 것이 좋다. synchronized를 사용한 것이 사용하지 않은 코드에 비해 약 3∼4배정도 느려지기 때문이다. 대부분의 유닉스와 윈도우는 운영체제 차원에서 Event, Critical Section, Mutex, Semaphore 등의 동기화 메커니즘을 제공한다.
출처 : http://makebob.tistory.com/entry/프로세스의-메모리-구조
글
크레이지 범프
크레이지 범프라는 프로그램인데 결과물 비교 스크린샷을 보면