광역 조명이나 음성인식 등 스퀘어에닉스의 「직공기술」을 불필요하게 하는 자동화 최전선 - 1


계속 되어 행해진 것은 음성인식에 관한 연구다.
이것은 립싱크. 즉 성우가 말한 대사의 음성과 게임 캐릭터의 입의 움직임을 맞추는 을 목적으로 한 것이라고 한다. 최근의 게임은 많은 캐릭터가 마구 말하거나 하므로 이 작업은 상당한 노력을 필요로 하는 것이 되어 있을 것이라는 것은 게 상상할 수 있다.
 

대사 마다 입의 움직임을 맞추어 시선이나 표정 애니메이션을 결정해 간다. 이 작업은 숙련CG니메이3으로 행해지고 있었다고 하지만 1초쯤0.6 , 즉 한 명 당 1 1.6초분의 처리 밖에 할 수 없었던 것이라고 한다. 팀에서1 5초씩. 이것은 자동화하고 싶은 무리는 아닐 것이다.



성우가 말한 대사로부터 적절한 입 애니메이션을 생성한다고 한다는 것은 간단하지 않아서 어렵다. 여러가지 방식 시험 것 같지만 많은 성우에 의한 음성 데이터로부터 단일의 음소 데이타베이스를 만들어 범용에 적용하는 방식은 데이터를 늘리는 만큼 역효과가 되었다는 것. 성우 한 명 으로 음소 데이타베이스를 만들면 정도는 올랐지만 성우마다 각각 작업이 필요하게 된다. 단어 단위로 데이타베이스를 만들어 가면 거의100%의 식별율로는 되었지만 너무 시간이 들어서 실용적이지 않다는 것. 최종적으로는 성우 단위로 처리하는 방식이 현실적이라고 하는 판단이 되었다.



식별 엔진 자체를 자사에서 만들거나 기존의 엔진을 검토하거나 한 결과 최종적으로 선택된 것은 NHK 기술연구소가 제공하고 있는 엔진이 되었다고 한다. 장래적으로 순차 형 처리를 검토하고 있었던 것에 적응할 수 있는 것 외에 데이터 형식이나 음향 모델의 적응화법이 시작하고 있던 것 그리고 자사제보다 더 좋기 때문에 기존 엔진을 사용했다고 한다.



이 시스템이 생긴 것에 의해 종래와 비교해서 코스트는 1/8이 되어 퀄리티 향상도 실현 되었다고 한다. 향후 발매되는 타이틀에서는 이 시스템이 적용되고 있다라는 것으로(FF시리즈에서도 사용된다라는 것) 컷 씬을 볼 기회가 있으면 뒤에서 이러한 시스템이 움직이고 있는 것이라고 하는 것을 생각하자.



스퀘어 에닉스에서는 이것들 이외에도 자동화에 의한 처리의 확충을 예정하고 있어며 특히 「버추얼 액터」라고 예정에 들어가 있는 부분 등 군중, 모션, 페이셜 애니메이션 각각에 대하여 키 프레임을 중지한 애니메이션 생성을 가능하게 하는 것이라고 하는 것이므로 꽤 기대. 보다 유효한 부분에 직공기술을 투입할 수 있게 되면 게임 자체의 퀄리티 향상도 기대할 수 있다고 한다. 향후의 새로운 연구에도 기대하고 싶은 이다.


출처 : http://www.4gamer.net/games/032/G003263/20090903061/


저작자 표시
신고
by 흥배 2009.11.02 08:30

CEDEC마지막 날 스퀘어에닉스의 연구 개발부Natural Expression 자연스러운 표현을 목표로 한다」라고 제목을 붙인 강연을 했다.
 

처음 등단 한 것은 개발 디렉터 후지이 에이지씨. 먼저 Natural Expression 중요한가에 해서 말했다.
 

Natural Expression을 직역하면 그대로 「자연스러운 표현」이 되지만 Natural의 의미로서 「가공되어 있지 않다」라고 하는 것을 강조하고 있던 것으로부터 가공되어 있지 않은 → 손보지 않아도 좋은 것 같은 데이터를 자동 생성해 나가는 것을 목표로 하는 것 같다.


즉 스퀘어에닉스 사내에는 직공급의 우수한 아티스트나 기술자가 있는 것이지만 모션 캡쳐로 수중에 넣은 애니메이션 데이터는 니메이가 수정해 나가 크로스(옷감) 시뮬레이션에서 드레스로부터 무릎마디가 튀어 나 있으면 수작업으로 수정해야 할 것이다. 게임 개발에는 방금 전의 예로 말하면 Natural가 아닌 처리가 많아 직공의 기술이 필요한 처리가 많은 것이라고 한다. 하지만 직공을 늘리는 것은 간단하지 않다.


CG제작 부분에서 말하면 기기나 소프트의 코스트는 내리고 있는데 인건비가 상승하고 있다고 한다. 이것을 고성능 화하는 하드웨어의 파워를 잘 이용하는 것으로 억제할 수 없을것인가 라고 하는 것이 기본 명제다. 약간 뜻밖의 것으로 효율화에 의한 코스트 삭감의 시도의 일환으로 최첨단 기술개발이 진행되고 있는 것 같다.

이렇게 말한 자동화에 관해서 스퀘어에닉스 사내에서는 몇개의 대처를 하고 있는 것 같고 이번은 글로벌 일루미네이션 관계, 음성인식 관계 2종류에 대 발표가 있었다.


GPU에 의한 연산으로 글로벌 일루미네이션을

CEDEC를 시작하여 기술계의 이벤트 취재에서는 몇 번이나 소개한 이 있는 광역 조명:글로벌 일루미네이션은 부드럽고 자연스러운 음영을 만들기 위해 최근에는 필수 사항이 되고 있는 기술이라고 할 수 있을 것이다. 스퀘어에닉스에서는 비 리얼타임 CG에서의 고정밀의 글로벌 일루미네이션을 이용한 레이 트래싱의 연산을 GPU 베이스로 실시하는 시스템을 구축하고 있다고 한다.


에 나타난 렌더링 예에서는 1000 포톤을 사용한 포톤(광원으로부터 광자를 뿌리고 오브젝트 표면에 밝기를 매핑 하는 수법)에 의한 글로벌 일루미네이션의 화상이 소개되었다. 보통으로 렌더링 하면1시간 걸리는 데이터지만 풀 HD 해상도로 GPU 6(후반의 설명으로Quadro Plex FX5800이므로 GeForce GTX 280 상당이라고 생각해 두면 좋다)를 사용해 30초 정도로 렌더링 한다고 한다.

계속 하여 시스템의 특징에 대한 해설을 했다. 파라메트릭 곡면(베지에 곡면이나 스프라인 곡면 )을 직접 렌더링 하는 처리계를 만들어 3D툴상에서 파라메트릭 곡면 베이스로 만든 모델링 데이터를 다각형 데이터로 입력하고 또 파라메트릭 곡면으로 변환하여 렌더링 한다고 하는 흐름같다. 이 시스템에서는 병렬도를 올리기 위해 폭 우선의 레이 트래싱을 채용하고 있다라는 것.


레이 트래싱에서는 각 셀로 향 시점으로부터 레이(광선)쏘아 가는 것이지만 그 레이가 반사를 반복하 광원에 도달했을 때에 최종적인 색이 결정된다. 이 통상의 방식을 깊이 우선으로 하면 폭 우선이라고 하는 것은 1점 마다 구석으로부터 완전하게 휘도 연산을 진행시키는 것은 아닌 방식이다. 우선이나 깊이 우선이라고 하는 것은 트리 탐색 등에서 잘 사용되는 알고리즘의 차이이지만 레이 트래싱의 경우 우선 1 레이를 각 셀에 날리고 반사 면으로부터 2 레이 이후도 단계적으로 전체를 1계층씩 처리해 나가는 것이 폭 우선 레이 트래싱에 상당한다. 

레이 트래싱에 사용하는 렌더링 방정식을 노이만 급수 전개하면 반사 차수마다의 급수로서 재정의되므로 각각의 차수에 대한 처리가 가능하게 된다.


여기서 재미있는 것이 최적화의 알고리즘이다. 스퀘어에닉스의 시스템에서는 하치스가 메구미야씨의 커히렌트 레이 트래싱의 수법이 이용되고 있다고 한다. 이것은 폭 우선으로 얻을 수 있던 각 셀마다의 제각각인 레이를 대충 모으고 같은 방향의 것을 정리하면서 계산한다고 하는 수법이다.


또 어느 부분인가는 잘모르겠지만 캐쉬 오브리비아스 데이터 레이아웃이 취하고 있는 히르베르트 곡선에 따른 데이터 배치를 하고 있다라는 것. 히르베르트 곡선은 평면 내지 공간을 구석으로부터 재귀적으로 일필 쓰기로 묻어 주는 알고리즘으로 공간을 1차원적으로 재정의할 수 있어 공간적으로 비교적 가까이의 것이 전후에 거리낌 없기 때문에 캐쉬의 효과가 좋은 등 귀중한 보물이 되는 방식이다. 1 레이의 날리는 순서와 포톤을 회수할 때의 레이의 날리는 순서에서도 히르베르트 곡선이 사용되고 있다고 한다.

개발 상황을 보면 아직 전체가 완성이라고 하는 것은 아닌 것 같지만 벌써 실용 단계에 있는 것 같고(은근하게 흘리고 있었지만) 연내에 발매되는 타이틀에서 사용된다라는 것. 프리 더 무비 이외에 베이크 용의 라이트 맵 작성 등에도 사용되는 것.

덧붙여서 NVIDIA「레이 트레이닝 시작했습니다」고 하는 뉴스가 요전날 있던 것처럼 NVIDIA는 이전부터 GPU를 이용하 렌더링을 실시하는 어프로치를 Gelato고 하는 프로젝트 명으로 추진하고 있다. 이것을 사용하면 MAYA 등에서는 그대로 렌더링 할 수 있을 것이지만 이것을 사용하지 않는라고 물으면 「Gelato보다 훨씬 빠릅니다」라는 . 아무래도 꽤 고도의 글로벌 일루미네이션을 요구하고 있는 것 같고 그만한 최적화를 하지 않으면 실용성에도 영향을 것이다. 또 이 렌더링의 기술은 장래적으로는 리얼타임화를 목표로 하는 것 같고 5년 후의 하드웨어(게임기라고는 말하지 않았지만)로 리얼 타임 처리 시키는 것을 목표로 하고 있다고 한다.


나머지는 다음에 이어서 올리겠습니다.

출처 : http://www.4gamer.net/games/032/G003263/20090903061/


저작자 표시
신고
by 흥배 2009.10.28 01:19

CEDEC 2009리스트 대담:첨단을 달리는 게임 개발자들이 차세대의 기술을 말한다



CEDEC 2009의 마지막 날(93). IMAGIRE DAY라는 제목으로  3D그래픽스의 일련의 기술 트럭을 매듭짓는 형태로3D게임 개발 니악스」라는 제목 된 원탁이 개최되었다. 사회를 맡는 것은 4Gamer의 기사 집필에서도 친숙한 니시카와 젠지씨. 패널리스트로서 아래의 6의 현역 톱 개발자가 몇 개의 테마에 대하 의견을 주고 받는다는 내용이다.

트라이 에이스
                    고탄다 타카하루씨
실리콘 스튜디오                   타무라 나오키씨
라이트 트랜스포트 엔터테인먼트    후지타 마사 히로시씨
반다이남코게임스                  이마키이레 타카시씨
실리콘 스튜디오                   카와세 마사키씨
캡콘                              이시다 사토시씨

 

개개의 테마는 약간 독립하고 있으므로 필자의 설명을 섞으면서 주요한 테마로 좁혀 참석자들의 발언을 모아보려고 한다.



글로벌 일루미네이션은 게임 그래픽스에 필요한가?

 


몇년 전까지의 게임에서는 3D그래픽스의 렌더링은 오로지 직접 빛만으로 행해져 왔지만 GPU나 프로세서의 성능 향상에 맞추어 간접 빛을 고려하 렌더링을 실시하는 글로벌 일루미네이션(Global Illumination:이후GI)를 도입하는 게임 엔진이 나타나 오고 있다. 말할 필요도 없이 GI는 직접 비교해 리얼리티가 있는 화상을 얻을 수 있는 것이 큰 이점이다.
 

한편 GI고 해도 다양한 수법이 있지만 일반적으로 계산 부하가 높다 고 하는 이 있다. 게임성에 영향을 주는 물건은 아닌 만큼 과연 필요한가? 고 하는 의문은 지당할지도 모른다.

GI는 필요할 것일까라고 추궁 당한 고탄다씨는 「결국은 게임에 의한」것은 아닐까 라는 견해다.
 「단순하게GI
구현할까/하지 않을 것인가 라고 하는보다 게임에 맞추어 전체 밸런스로 구현해 나가게 되는 것은 아닐까」(고탄다씨).
 

또 후지타씨도 고탄다씨에게 동의 하면서 GI는 아티스트를 보좌하는 툴로서 유효하다고 말하고 있었다.
 「게임의 개발에는 다양한 아티스트가 들어 오므로 라이팅을 일정한 퀄리티에 컨트롤 하는 것이 어렵다. 그것을 GI 어시스트 하여 한층 더 게임에서 보여 주고 싶은 방향으로 아티스트가 독자적인 라이팅을 만들어 간다고 하는 형태가 유효하지 않은가」(후지타씨).

역시 두사람이 말하듯이
GI를 게임이 필요로 한다면 구현하고 그렇지 않으면 구현하지 않는다고 하는 것이 개발 현장에서의 파악하는 방법으로 될 것이다. 게다가 렌더링은 아니고 포스트 프로세싱으로 의사적으로 간접 빛의 표현을 실시하는 앰비언트 오크루존(Ambient Occlusion) 표현 등의 기술도 사용되기 시작하여 NVIDIA는 드라이버 레벨에서 앰비언트 오크루존을 실현하고 있기도 하지만 그러한 「맛내기적으로 쓰여지는 방법도 있지 않은가」라고 니시카와씨가 잡고 있었다.

 

DirectX 11 어떻게 받아 들이고 있을까

 


 

Windows 7과 함께 차세대 그래픽스API DirectX 11 등장한다. DirectX 11에서는 Level of Detail(거리에 따라 다각형수를 증감시키는 수법) 으로  텍셀레이션을 시작으로 하는 새로운 feature지원되어 그래픽스의 레벨이 향상하는 기대 갖게 하고 있다. 개발자들은 DirectX 11를 어떻게 보고 있는 것일까.

타무라씨는 「어수선한 인상」이라고 DirectX 11에 매우 엄하다.
 「쉐이더가 나온 배경에는 API가 비대화 하여 더 스마트하게 일원화 하고 싶다고 하는 것이 있었다. (DirectX 8이후에) 범용적인 쉐이더로 일원화 되어 API가 스마트하게 되어 행복해질 것이었지만 최근에는 바뀌어 온 것 같다. 이대로 쉐이더가 증가해 가면 과거에 API가 비대화 해 한계가 온 것처럼 또 한계가 오는 것은 아니겠는가(타무라씨) 라는 의문을 나타내 장래적으로 발본적인 변화가 있을 지도 모르다고 예측한다.
 

예를 들면 현재의 하드웨어 베이스의 렌더링으로부터 소프트웨어 렌더링으로 바뀌어 GPU CPU 고도로 병렬화해 리얼타임의 레이 트래싱이라고 하는 형태 변화할지도 모른다고 하는 것은 확실히 있을 것이다. 실제 CEDEC 2009에서 행해졌CrytekCarl Jones씨의 세션에서 고도로 병렬화한 앞으로 새로운 렌더링 알고리즘이 필요하게 된다고 하는 예측이 말해지고 있었다.
 

그러나 변화가 있다고 해도 당분간 것이라고 말하는 것이 각 참석자들의 견해다. 이시다씨는 「소프트웨어 렌더링은 아직 먼 것으로 DirectX 11의 다음도 현재와 같은 하드웨어 렌더링이 된다고 생각한다」라고 예측한다.

또 만일 리얼타임의 레이 트래싱이 가능하게 되었다고 해도 게임 그래픽스가 단번에 레이 트래싱으로 바뀔 것은 없다고 보고 있는 것 같다.

「게임에서 표현하고 싶은 그래픽스가 있어 그 때문에 레이 트레이닝이 좋다고 한다면 레이 트레이닝을 사용하면 좋고, rasterize가 좋으면 rasterize가 사용될 것이다」(후지타씨).
 혹은, 「디자이너가 지정한 곳만 레이 트레이으로 하는 방법이 나오는 것은 아닐까」(고탄다씨) 라고 현재의 수법에서 레이 트레이을 조합한 그래픽스가 이용되는 것은 아닐 라고 하는 예상이 말해지고 있었다.





출처 :  http://www.4gamer.net/games/032/G003263/20090904001/




저작자 표시
신고
by 흥배 2009.09.29 01:44

[CEDEC 2009]결정적 수단은 텐솔, 물리 시뮬레이션 도입의 급소

 Tensor : 3차원 공간에 있어서 9개의 성분을 가지며, 좌표 변환에 의해 좌표성분의 곱과 같은 형의 변환을 받는 양. 예를 들면, 물체의 관성 모멘트나 변형은 이것으로 표시됨. (출처 : 네이버)

 

 

물리 시뮬레이션(이후 물리)은 Havok 혹은 NVIDIA PhysX로 대표되는 물리 엔진이 준비되어  프로그래머나 게임디자이너의 도구로서 게임에 도입할 수 있게 되었다. 게임의 멋내기로서 혹은 게임성 그 자체에 물리를 넣는 타이틀은 드물지 않게 되었지만 그래도 아직 물리를 어려운, 행동 조정이 귀찮다라는 이유로 멀리하는 게임 크리에이터는 적지 않은 것 같다.
 

CEDEC 2009의 첫날에 행해졌던「게임 물리 취급 방법」이라고 세션은 그런 물리를 싫어하고 있는 게임디자이너나 프로그래머를 대상으로 게임에서 물리를 잘 이용하기 위한 포인트를 소개하는 내용. 4Gamer의 독자로서는 반대로 물리를 채용한 조정 부족의 게임에서 발생할 수 있는 기묘한 동작의 이유를 아는 단서로도 되는 내용을 포함하고 있었으므로 세션의 개요를 소개해 보고 싶다.



강체의 표현으로는 관성 tensor 조정이 키를 잡는다

 

 

게임에 있어서의 물리는 오로지 오브젝트끼리의 상호작용을 표현하는데 이용되고 있다. 오브젝트끼리가 충돌한다든가 구르고 부서지고 떨어진다……라고 하는 행동을 물리로 계산하는 것이다

 

데자이나의 손에 의한 키 프레임 애니메이션을 사용한 움직임에는 유한의 패턴 밖에 없지만 물리를 이용하면 무한의 패턴이 만들어진다. 패턴이 다양하게 되어 디자이너의 부담을 줄일 수 있다

 

세션을 담당한 것은 소니 컴퓨터 엔터테인먼트에 소속하는 마츠이케 유타카사씨, 타카하시루시씨, 사쿠라이 료스케씨 3명. 사쿠라이씨가 우선 게임 물리의 개요를 소개한 뒤, 마츠이케씨가 강체의 표현과 그 편성 포인트를 해설 그리고 마지막에 타카하시씨가 유체의 표현을 소개 하는 순서. 그 중에서도 가장 시간이 할애해진 것이 사쿠라이씨의 세션이었으므로 그 세션을 중심으로 정리해 보자.
 

게임에 있어서의 물리에 대해 재차 설명할 필요가 없다고 생각하지만 간단하게 정리하면 게임 중에 등장하는 오브젝트(물체)의 움직임을 물리 계산을 사용해 표현하는 것으로 보다 현실에 가까운 움직임을 표현하려는 물건이다. 사용되는 계산은 뉴턴 물리로 대표되는 고전물리의 레벨로 「물리라고 해도 대부분 어려운 것은 없다」(사쿠라이씨).
 

물리를 사용하는 결점에는 계산 부하가 높다고 하는 것을 들 수 있다. 극히 간단한 계산을 실시한다고 해도 오브젝트의 수가 증가하면 계산량이 증가하고, 게임에서는 프레임의 묘화에 맞추어 계산을 실시할 필요가 있으므로 계산 시간이 한정되는 것이 장애가 된다.
 

한편 이점은 「물리 법칙에 따라서 얻을 수 있는 행동의 패턴은 무한」(사쿠라이씨)이라고 하는 점이다.
 

물리를 이용하는 이점은 큰 것이지만 첫머리에서 말한 것처럼 조정이 어렵다는 이유로 채용을 피하는 게임디자이너가 적지 않다. 실제 「설정을 바꾼 것만으로 눈 깜짝할 순간에 행동이 불안정하게 된다」(마츠이케씨)라고 하는 것이 잘 일어난다.
 

게임 물리에서는 강체(딱딱한 오브젝트)에 형상, 위치, 속도, 질량이라고 하는 파라미터를 설정하여 계산시키지만 마츠이케씨에 의하면 파라미터 중에서 행동을 안정시키는 키가 되는 것이 관성 tensor이라고 한다.



 

물리 파라미터의 설정이 어려운 것이 게임 물리의 난점. 설정이 능숙하지 않으면 랙돌(여기서 말하는 랙돌은 물리로 작동되는 인체 등의)의 관절이 성장해 버리는 등 부자연스러운 움직임을 보이는 것도 적지 않다고 한다

 

강체가 가지는 파라미터 가운데 공동을 안정시키는 키가 되는 것이 관성 tensor이라고 한다.「관성 tensor 이해하지 않는 채 물리 시뮬레이션을 적용하는 것은 위험이 있다」(마츠이케씨)


 

관성 tensor이라고 하는 것은 회전 하기 쉬움(회전 모멘트)를 보다 일반화한 수학 표현이지만 여기에서는 회전 하기 쉬움을 나타내는 파라미터 정도로 생각해 두면 충분하다. 관성 tensor이 크면 회전 하기 어렵고, 또 회전 하기 시작하면 멈춤기 힘들다. 반대로 관성 tensor이 작으면 간단하게 돌기 시작하지만 회전은 간단하게 멈춘다.
 

관성 tensor은 물체의 형상이나 중량 배분으로부터 결정할 수 있지만 물리 엔진에서는 「관성 tensor이 너무 작아 지면 물체의 움직임이 안정되지 않는다」(마츠이케씨)라고 한다. 그 때문에 물체의 형상으로부터 상정되는 관성 tensor을 그대로 사용해 버리면 오브젝트의 움직임이 안정되지 않는 결과가 되기 쉽다고 한다.



 

관성 tensor은 물체를 회전하는 축으로부터 바라보면 대체로 크기를 알 수 있다. 회전축에서 본 크기가 작으면 관성 tensor은 작고, 크면 관성 tensor은 커지는 것이다

 

예를 들면 봉과 같은 강체라면 단면 방향의 관성 tensor만이 극단적으로 작아져 버리기 때문에 불안정하게 되기 쉽다고 한다. 불안정을 억제하려면 관성 tensor 실제보다 굵은 봉으로서 설정하면 잘 된다

 

 

대략적으로 컨스트레인트는 그림 중의 간이식에서 계산되지만 관성 tensor 차이가 오차를 크게 해 버리는 결과, 관절의 부자연스러운 성장이라고 하는 현상을 일으킨다

 

추의 질량은100kg, 쇠사슬은 네 개의 오브젝트로 나누어진 1kg의 질량을 가지는 쇠사슬로 내려지고 있다. 이 질량 배분을 바탕으로 오브젝트의 관성 tensor 설정하면 추를 털었을 때에 쇠사슬의 조인트가 떨어져 버리는 현상이 일어난다

 

실제로 시뮬레이션을 실행하고 있는 예. 왼쪽이 관성 tensor 질량 배분 대로로 설정한 예. 중앙이 쇠사슬과 추를 같은 질량으로 한 예. 오른쪽이 쇠사슬의 관성 tensor 크게 한 예로 왼쪽의 예가 가장 자연스럽게 움직이는 것처럼 보인다

 

랙돌의 관절의 부자연스러운 성장이라고 하는 현상도 관성 tensor을 조정하는 것으로 억제할 수 있다고 한다.
 

그럼 왜 랙돌의 관절이 부자연스럽게 성장하거나 하는 것일까. 관절은 물체와 물체끼리의 상호 작용……부딪친다든가, 붙인다라고 하는 계산(제약:컨스트레인트라고 한다)을 사용하여  움직임을 표현하고 있다. 물체끼리의 상호 작용이라고 하는 것은 간단하게 말하면 두 개의 물체의 속도와 위치, 그리고 두 개의 물체의 질량비를 사용하여 계산할 수 있지만 속도나 위치는 수학적 또 시간적인 제약으로부터 근사적으로 밖에 구할 수 없다. 관성 tensor은 질량 쪽에 걸려 오므로 관성 tensor의 차이가 근사의 오차를 확대해 버려 관절 등이 자연스러운 형태에는 표현할 수 없는 결과를 일으킨다고 한다.
 

그럼 실제로 무슨 일이 일어나는 것일까. 간단한 예로서 4개의 관절을 가지는 쇠사슬로 줄에 걸어서 내린 추의 예가 소개되었다.
 

오른쪽 중앙 그림(역주:바로 위 그림의 오른쪽)과 같은 쇠사슬 줄로 내린 추에 대해서 관성 tensor을 질량 배분대로 설정하면 추를 털었을 때에 조인트가 떨어져 버린다. 그것을 해결하려면 질량 배분을 바꾸는(쇠사슬에 대해서 추를 가볍게 하는) 방법도 있지만 쇠사슬 부분의 관성 tensor을 추에 대해서 크게 한다고 하는 조정으로 보다 자연스러운 움직임을 재현할 수 있다고 한다.
 

이것은 랙돌의 경우도 마찬가지로 실제 인체의 질량 배분대로 하면 관절이 성장해 버리는 현상이 일어난다. 아래의 예를 보면 좋겠다.



 

실제의 인체의 질량에 맞추어 오브젝트의 질량의 배분을 결정한다. 그 랙돌의 손을 고정해 움직이면 손의 관절이 성장해 버린다고 한다

 

실제로 시뮬레이션 한 예. 조금 알기 힘들지만 손을 고정하고 좌우에 랙돌을 거절하면 손의 관절이 떨어져 있는 것을 안다고 생각한다

 

고정되고 있는 손을 우선하여 질량을 다시 배분한다

 

04그러면 좌우로 털어도 관절이 성장하지 않는다

 



게임 물리와 실제의 물리는 다르다 ~ 의미를 이해한 위에 파라미터의 조절이 필요


이상 관절의 움직임에 더해 문의 움직임 등의 설명이 있었지만 간단하게 정리하면 「파라미터의 의미를 이해한 다음 파라미터를 잘 조절해 자연스러운 움직임을 재현하자」라고 한다.
 

관성 tensor과 같이 알기 힘든 파라미터를 의미를 이해하지 않고 조정해도 괜찮은 결과는 얻을 수 없다. 또 이해하고 현실 대로에 파라미터를 설정해도 역시 잘 되지 않는다. 랙돌의 중량 배분 등 현실과 동떨어지고 있지만 실제로 움직이면 「그것 같은」움직여 주는 것을 안다. 게임은 진짜 의미로의 물리 시뮬레이션은 아니니까 「그것 같은」움직임이 중요하다.
 

물리 엔진의 보급에 따라 향후도 물리를 넣는 게임이 증가할 것이다. 파라미터의 조정이 능숙하지 않은 게임도 물론 증가할 것이다. 게임 중 오브젝트의 부자연스러운 행동을 보면 이번 기사를 조금 생각해 내 주면 「아, 과연」이라고 납득할 수 있을지도 모른다.

 

출처 : http://www.4gamer.net/games/032/G003263/20090901058/

 

 

 

이 글은 스프링노트에서 작성되었습니다.

신고
by 흥배 2009.09.24 01:18

[CEDEC 2009]MS의 카와니시 히로유키씨가 차기 개발툴 「Visual Studio 10」의 병렬화 지원 기능을 소개


이미, 멀티 코어 프로세서는 가격적으로도 특별한 것은 아니다. 사진은 Phenom II X4 965 Black Edition/3.4GHz」

PC의 세계에서도 또 컨슈머(consumer) 게임기의 세계에서도 멀티 코어 프로세서가 급속히 퍼지고 있다. 싱글 코어로의 성능이 향상하던 시대라면 프로그래머가 가만히 있어도 하드웨어가 새로워지면 프로그램의 고속화를 기대할 수 있었지만 멀티 코어 시대는 그렇지 않다.
 

프로세서 전체의 퍼포먼스는 오르고 있어도 코어 하나 정도의 성능이 오르고 있다고는 할 수 없기 때문에 아무것도 생각하지 않은 프로그램은 전혀 성능이 오르지 않는 상황이 되고 있어 프로그래머 측에도 노력이 요구되고 있는 것이다. 많이 알려진 “프로그램의 병렬화”(자주 말하는 multi-thread 화와 거의 동의)이다.
 

게임은 비교적 multi-thread화가 어려운 소프트웨어로 4Gamer에 게재되는 각종 benchmark test 결과에서도 멀티 코어로의 성장이 적은 현실에 그것이 잘 나타나고 있다고 말할 수 있을 것이다.
 

그렇다고는 해도 멀티 코어화의 흐름 거술러 수는 없는 것으로 게임도 CPU 코어 수에 따라 확정성 높게 퍼포먼스를 늘릴 수 있는 병렬화의 궁리가 필수가 되고 있는 것도 확실하다.
 

CEDEC 2009의 2일 째에 행해졌던「측정할 수 있는 병렬화」라고 제목이 된 세션은 차기 개발툴「Microsoft Visual Studio 2010」(이하 Visual Studio 2010)가 지원 하는 병렬화 지원의 소개를 중심으로 병렬화의 포인트를 설명 하는 내용이었다. 게임에 특화한 이야기는 적고 또 프로그래머 전용의 세션인 만큼 게이머에게 직접 관계가 있는 이야기는 아니지만 툴의 지원이 충실하는 것으로써 게임의 병렬화도 진행되지 않을까라고 기대하면서 내용을 소개해 본다.



프로그램의 병렬화에 가로막는 다양한 곤란

 

마이크로소프트 디벨로퍼&플랫폼 통괄 본부 플랫폼 선교자 카와니시 히로유키씨

본세션을 담당한 것은 Microsoft의 일본 법인인 마이크로소프트에서 플랫폼 선교자를 맡은 카와니시 히로유키씨다. 마이크로소프트가 담당하는 기술 세션에서는 친숙한 「얼굴」이다. 아시는 분도 많다고 생각하지만 카와니시씨가 자랑으로 여기는 것은 그래픽스. 그 때문에 이 세션도 「뒤의 타이틀은「Larrabee」(라라비, 개발 코드네임)의 준비를 하자, 차세대 준비를 하려는 김」으로 할까라고 생각하고 있었다고 한다.
 

카와니시씨는 우선 CEDEC 2009에서 행해졌던 CrytekCarl Jones씨에 의한 세션에서 다루어지고 있었다고 하는 예측을 소개. 그것은 2013년 이후 CPU, GPU 함께 고도로 병렬화 해 경합 하게 될 것이다 라고 하는 내용이다.
 

카와니시씨는 여기서 고도로 병렬화한 CPU나 GPU에 대응하는 「새로운 렌더링 알고리즘이 요구된다」라고 말한다. 그것이 어떤 것이 될까는 모른다고 하면서 「Direct3D 패러렐과 같은 것이 나올지도 모른다」라고 예측하고 있었다.또 그렇게 멀지 않은 장래 등장할 Larrabee에 대해서도 「범용적인 알고리즘이 예를 들면 32기의 CPU로 움직이는 것이 실현된다」라고도 말하고 있었다.


Crytek의 Carl Jones씨가 말하고 있었다고 하는 병렬화의 예측. 2013년 이후 CPU와 GPU는 고도로 병렬화해 새로운 패러다임(paradigm)가 요구되게 된다고 한다

 

카와니시씨는 Larrabee 대단히 기대하고 있는 것 같다. Larrabee는 범용적인 Pentium 클래스의 CPU 코어를 다수 집적한 프로세서로 GPU과는 달리 범용적인 알고리즘을 메니 코어로 처리할 수 있다

 

병렬화에 가로막는 다양한 장매물. 섬세하게 설명은 하지 않지만 무엇을 병렬로 하는가 하는 설계 상의 난관에 더해 스렛드 간의 동기, 데드 락이라고 하는 기술상의 문제나 에러로부터의 회복이나 디버그가 어려운 점 등 처음부터 마지막까지 병렬화에는 다양한 난관이 기다리고 있다

 

장래적으로는 32 CPU, 64 CPU……라고 하는 메니 코어로 프로그램을 동작시킬 필요가 있어 프로그램의 측정할 수 있는 병렬화는 급무가 되고 있는 것이다. 하지만 병렬화는 그렇게 간단한 물건은 아니다.
 

현재 유감스럽지만 자동적으로 프로그램을 병렬로 해 주는 「자동 병렬화 컴파일러는 없다」(카와니시씨). 따라서 병렬화는 프로그래머가 스스로 실시하지 않을 수 없지만 거기에는 다양한 곤란이 있다고 하며 나타난 것이 오른쪽의 슬라이드다.이러한 곤란을 어느 정도 클리어로 해 주는(≒해결해 준다)  “영리한 개발툴”이 요구된다고 지적한다.



Visual Studio 2010에 들어간 병렬화를 지원하는 기능

 

Visual Studio 2010에 구현되고 있는 태스크 스케쥴러. 여기서 말하는 태스크는 「병렬로 실행시키고 싶은 일」이라고 이해해 주었으면 한다. 프로그램측이 태스크 스케쥴러에 태스크를 건네주면 그것을 적절한 타이밍에 스레드로서 Windows에 실행시킨다고 하는 이미지다

 

베타인 Windows프 로그래밍에서는 병렬화할 수 있는 처리를 스레드로 구현하고 Windows API를 사용해 스레드를 기동시킨다라고 하는 일을 실시한다.
 

기동된 스레드는 Windows 커널의 스케쥴러가 적당한 CPU에 할당해 주지만 스레드를 처리시키는 차례 등은 프로그래머 스스로가 결정할 필요가 있다. 차례의 사정으로 놀고 있던 CPU가 나와 버리는 것은 바람직하지 않지만--CPU 수에 따라 성능을 올리고 싶으면 놀고 있는 CPU는 가능한 한 줄이고 싶다--, CPU를 효율적으로 일하게 하는 것은 꽤 어렵다고 하는 문제가 있다.
 

거기서 Visual Studio 10의 런타임에는「유저 모드 스케쥴러」라는 것이 구현되어 있다고 한다.
 

유저 모드 스케쥴러는 프로그램측에서 건네받은 태스크를 적절한 타이밍(=CPU가 보다 효율 좋게 일하는 타이밍)으로 태스크를 Windows의 스레드로서 실행시키는 기능을 가지고 있다.
 

예를 들면 「가능한 한 캐쉬가 두꺼운 태스크를 스케줄 한다」(카와니시씨)라고 한 것까지 자동적으로 해 준다라는 것.  「캐쉬가 두꺼운 태스크」라고 하는 것은 「캐쉬가 히트 하고 있을 태스크」라고 하는 의미이지만 유저 모드 스케쥴러의 자원 매니저는 PC에 탑재되고 있는 CPU 코어 수등을 파악하고 있어 기동하는 스레드의 수를 CPU 코어 수에 따라 조절한다고 하는 것도 자동적으로 행해진다라는 것이다.
 

여기서 데먼스트레이션을 했다. 그 내용은 아래에 게재한 사진으로 확인해 주었으면 한다.



 

바이너리 트리의 탐색을 재귀적으로 실시하는 C#의 데모 프로그램. 단순하게 스레드화 하면 ,500 이상의 스레드가 일어선다

 

메모장에 쓰여진 「17670」은 싱글스 레드로의 실행 시간(17.670초)로 「16866」은 multi-thread화 했을 때의 실행 시간(16.866초). 거의 변하지 않는 것은 4 코어의 플랫폼에서 500 이상의  스레드를 동시에 기동시켰기 때문이다.스레드 수가 너무 많아서 콘텍스트 스위칭이나 메모리 확보 등의 오버헤드가 커져 멀티 코어의 메리트를 살릴 수 없다

 

스레드 대신에 Visual Studio 10의 태스크로서 기동시키도록 고쳐 쓴다

 

그러면 불과 6초만으로 같은 처리가 종료했다.유저 모드 스케쥴러가 CPU 코어 수에 응한 태스크를 기동시켰기 때문이다

 



parallel_for 이용 예이지만 실제로는 정상적으로 동작하지 않는다. 병렬화 된 for문장 중에서 변수 u,v가 변화하기 때문이다. 이와 같이 스레드간에 공용되는 데이터가 있는 케이스에서는 단순하게 for 문장을 parallel_for로 옮겨놓을 수 없다

 

이 바이너리 트리의 데모는 약간 극단적이기는 하지만 유저 모드 스케쥴러의 효과를 매우 잘 아는 예다. 프로그래머는 플랫폼에 탑재되고 있는 CPU 코어 수를 의식할 필요는 없이 병렬화 할 수 있는 부분을 태스크로서 건네주는 것만으로 적당한 스레드로서 실행해 주는 모습을 알 수 있다.
 

또, Visual Studio 2010에는 병렬화를 지원하는 라이브러리 세트가 들어가 있어 루프를 병렬화한 parallel_for(for 문장을 병렬에 열린다), parallel_foreach(foreach를 병렬에 열린다)라고 하는 구조를 이용할 수 있는 것 같다.

....... 이하는 생략합니다.


 

 

출처 : http://www.4gamer.net/games/032/G003263/20090903008/

 

이 글은 스프링노트에서 작성되었습니다.

신고
by 흥배 2009.09.17 01:06
| 1 |

티스토리 툴바