오즈라엘

개요

기술이 발전하고 시간이 지남에 따라 그래픽카드 성능 역시 계속 발전해왔습니다. 그 덕에 더욱 놀랍고 사실적인 그래픽을 표현할 수 있게 되어왔습니다. 그 결과 현대의 PC 및 콘솔 게임의 그래픽은 현실과 그래픽을 분간하기 어려울 지경입니다. 이토록 그래픽 카드는 얼마나 더 멋진 그래픽을 얼마나 더 고속으로 처리할 수 있는 지가 가장 큰 이슈이고 이에 초점을 맞추어서 발전해왔습니다.

이미지 출처 : http://www.slideshare.net/ozlael/unitylightingslide-public

하지만 모바일 기기의 그래픽카드는 조금 다른 행보를 갖습니다.  모바일기기는 항상 전원이 연결되어있는 상황이 아니기때문에 전력 소모가 가장 큰 이슈가 됩니다. 또한 휴대가 용이하게 만들어야 하기 때문에 칩셋을 얼마나 물리적으로 작게 만드냐가 관건입니다. 게다가 물리적으로 작게 만드려면 쿨러를 장착할 수가 없기때문에 발열도 큰 문제가 됩니다. 이러한 모바일 기기의 특징들때문에 모바일에서는 Tile Based Rendering(타일 기반 렌더링)이라는 독특한 방식을 사용합니다. 이번 글에서는 Tile Based Rendering에 대해서 알아보고, 유니티에서 Tile Based Rendering을 고려시 주의점에 대해 다루고자 합니다.

Tile Based Rendering

우선 Tile Based Rendering에 대한 설명에 앞서 데스크톱의 렌더링 과정을 간단히 살펴보겠습니다. OpenGL에서 드로우콜을 날리면 지오메트리 데이터가 버텍스 쉐이더를 거쳐서 트랜스폼된 뒤 레스터화되고 픽셀쉐이더로 넘어가서 픽셀 컬러를 거칩니다. 픽셀쉐이더의 결과물은 바로 프레임 버퍼로 출력이 되면서 필요에따라 블렌딩 처리가 됩니다. 이처럼 드로우콜의 명령이 프레임버퍼까지 전달되는 과정이 한번의 패스로 이루어지고 매번 프레임버퍼 영역 전체가 갱신이 됩니다. 즉, 드로우콜 한번 당 한번에 바로 화면 전체에 렌더링합니다. (그래서 이러한 전통적인 렌더링 방식을 Immediate Mode Rendering이라 부르기도 합니다.)

이미지 출처 : http://www.ntu.edu.sg/home/ehchua/

하지만 모바일에서는 조금은 다른 방식을 사용합니다. 앞서 언급하였듯이 모바일에서는 전력 소모와 물리적 크기 등을 고려해야합니다. 이를 위해서 많은 고려사항들이 반영되며 설계가 됩니다만 그 중 가장 큰 고려 사항중 하나가 바로 대역폭입니다. 대역폭을 넉넉하게 쓰다보면 전력소모가 심해지고 물리적 칩셋 크기도 커집니다. 이는 발열로 이어지게 되는데 당연히 발열을 완화시킬 쿨러를 달 공간도 없습니다. 그래서 모바일에서는 대역폭을 줄이기위해 Tile Based Rendering(이하 TBR)이라는 아키텍쳐를 채용하고 있습니다.

앞서 말했던 것 처럼 전통적으로 데스크톱의 그래픽에서는 드로우콜마다 프레임 버퍼 전체를 갱신합니다. 하지만 높은 해상도의 프레임버퍼 전체를 매 번 갱신하는 것은 높은 메모리 대역폭을 요구하게 됩니다. 따라서 모바일에서는 프레임버퍼 전체를 매 번 갱신하는것이 아니라 타일 단위로 쪼개서 갱신을 하는 방식을 사용합니다. 드로우콜 발생 시 즉시 프레임버퍼에 기록하는 것이 아니라, 칩셋에 내장된 메모리에 존재하는 타일에 렌더링합니다. 이로 인해서 매번 화면 전체를 렌더링 하는 것이 아니라 실제 도형이 그려지는 타일만 렌더링 하게 됩니다.

이미지 출처 : Performance Tuning for Tile-Based Architectures

우선, 프레임버퍼를 일정 크기의 타일로 영역을 나눕니다. (이 타일 크기는 칩셋 벤더마다 차이가 있습니다.) 드로우콜이 발생하면 지오메트리 데이터가 버텍스쉐이더를 거쳐서 트랜스폼을 수행 후 레스터화됩니다. 여기까지는 전통적인 렌더링 방식과 동일합니다만 그 이후부터가 달라집니다. 버텍스 쉐이더의 결과가 바로 픽셀 쉐이더로 넘어가지 않고 타일을 선택하는 과정을 거칩니다. 그 후에 픽셀쉐이더가 수행되고 칩 내부 버퍼에 존재하는 타일에 그려집니다. 그 후 타일들이 완성되면 프레임버퍼에 그려집니다. 이런 식으로 타일 단위로 프레임버퍼를 갱신해주기때문에 적은 대역폭으로도 화면을 렌더링 할 수 있게됩니다.

이미지 출처 : http://wenku.baidu.com/view/85ea8fec998fcc22bcd10dcb.html

Tile Based Deferred Rendering

또한, TBR에서 변형되어 파생한 Tile Based Deferred Rendering(이하 TBDR) 라는 방식도 있습니다. 이 방식은 기본적으로는 TBR입니다. 다만 버텍스 쉐이더에서 트랜스폼 연산을 거치고나서 바로 픽셀 쉐이더로 넘기는 것이 아닙니다. 대신 버텍스 쉐이더의 결과를 중간 데이터를 담는 파라미터 버퍼에 담아둡니다. (이 버퍼를 ImgTec에서는 파라미터 버퍼라 부르고, ARM에서는 폴리곤 리스트라 부르는 등 여러 이름이 존재하지만 편의상 파라미터 버퍼로 통일하여 칭하겠습니다.) 이 파라미터 버퍼에 담은 후 픽셀 쉐이더로 바로 넘기는 것이 아니라, 매 드로우 콜 마다 버텍스 쉐이더의 결과를 계속 담아둡니다. 그 후 모든 드로우콜이 끝나면 그때서야 비로소 타일을 렌더링하고 프레임버퍼에 출력합니다. 그렇게되면 한 타일에 들어오는 모든 폴리곤을 한번에 처리 할 수가 있게됩니다. 이 과정에서 타일의 각 픽셀에는 은면제거가 처리되고 나서 도달하기 때문에 픽셀 오버드로우가 발생하지 않습니다. 이러한식으로 TBR을 지연해서 처리하기때문에 Tile Based Deferred Rendering(타일 기반 지연 렌더링)이라고 불립니다. 

이미지 출처 : Unity: iOS and Android - Cross Platform Challenges and Solutions

예전에는 TBDR 방식이 ImgTec의 PowerVR 즉 아이폰과 아이패드에서만 사용되었으나 최근들어서는 다른 칩셋들에서도 사용되고 있습니다. 하지만 여전히 안드로이드 기기는 TBDR보다는 TBR이 많이 사용되고 있습니다. 따라서 현 시점에서는 TBR을 사용하는 디바이스와 TBDR을 사용하는 디바이스가 공존하고 있는 상태입니다. (타일 기반이 아닌 전통적인 렌더링 기법을 쓰는 디바이스는 점유율이 매우 낮아서 논외로 합니다.)

이처럼 모바일에서는 타일 단위로 쪼개서 렌더링하는 방식을 사용하다보니 몇 가지 주의 사항이 존재합니다. 서론이 좀 길어지긴 했는데 결국 전달고자 하는 내용들은 다음과 같습니다.

이어지는 내용 : 

모바일 기기의 Tile Based Rendering(타일 기반 렌더링)과 유니티에서의 주의 사항 #2 : TBR 대응 리소스 제작시 주의점

Unity5로 리메이크한 Republique가 에셋스토어에 올라왔습니다. 그와 함께 유니티 공식 블로그에 "THE REPUBLIQUE REMASTERED IN UNITY 5 LEARN PROJECT IS HERE!"라는 글이 함께 올라왔습니다. 이 글은 유니티 공식 블로그의 글을 번역한 글입니다.

몇 달 전 Camouflaj에서 Remastering Republique: The Journey to Unity 5라는 주제로 영상 및 글을 올렸습니다. 또한 이제는 프로젝트의 일부를 에셋스토어에 공유하였습니다. 이를 통해서 Unity5를 실제 게임에서 어떻게 활용 할 수 있는 지를 확인할 수 있을 것입니다.

이 프로젝트 파일에는 교도소, 중앙 홀, 터미널 등 여러 공간이 포함되어 있습니다. 이를 통해서 리플렉션 프로브, Enlighten, 새로운 에니메이션 및 오디오 기능 등 Unity5의 기능들이 어떻게 사용되고 있는 지 확인할 수 있습니다.

ENLIGHTEN

Republique의 중앙 홀은 스튜디오에서 Unity5로 작업 한 첫번째 공간입니다. 우리(Camouflaj)는 Enlighten을 통해서 매우 놀라운 개선을 이를 수 있었습니다. 특히 씬의 천장에서 내려오는 빛은 매우 큰 효과를 보여주었습니다.

발광(Emissive) 재질은 Unity5에 추가된 것 중 하나입니다. 형광등 재질의 발광 강도(Emission intensity)를 증가시킴으로써 반사광을 만들어 씬을 밝게 조절하는 것을 보실 수 있습니다. continuous baking을 활성화시키면 즉각적으로 결과를 확인하게 됩니다. 이로써 라이팅 작업 시간을 매우 줄일 수 있게됩니다.

다음 이미지는 Emission 값을 보여주고있습니다. 이는 에니메이션 트랙을 추가하여 값을 네이메이션 시킬 수 있습니다. (역주:예를 들어 형광등의 깜빡임 등)

라이팅 탭의 간접광 강도(Indirect Intensity)를 증가시킴으로써 씬이 동적으로 업데이트되고 한층 밝아지는 것을 확인할 수 있습니다. 이는 실시간으로 보여지고 있습니다.

리플렉션 프로브는 주변 환경을 반사시킴으로써 실제같은 금속을 만들 수 있게 해줍니다. 

다음 이미지의 기둥의 표면은 금속으로 되어있습니다. 반사력(reflectivity)를 높임으로써 공간적으로 정확한 반사를 얻을 수 있습니다.

아래 이미지와 같이 부드러움(smoothness)을 줄이면 반사 이미지는 거칠어지고 흐려집니다. 

UNITY5 AUDIO

유니티5의 오디오 믹서는 오디오를 분류하고 출력 버스를 특정지을 수 있습니다. 이로인해 오디오를 더욱 유연하게 전송하고 혼합할 수 있습니다.  ‘Ambience’그룹은 2D와 3D 서브 그룹으로 나뉩니다. 자연적으로, 3D 환경 오디오는 3D 서브 그룹으로 전송되고, 3D 버스로 할당된 오디오는 알맞는 그룹으로 연결됩니다. 각각의 그룹에서는, 볼륨(volume)과 피치(pitch)를 조절할 수 있고 오디오 필터가 적용됩니다. 또한, 개별적 혹은 전체적으로 그룹들을 실시간으로 음소거 시키거나 독주화 시킬 수 있습니다. 오디오 믹서 우측 상단의 ‘Edit on Play Mode’를 클릭하면 게임이 실행되는 동안에 편집이 가능합니다. 그 예로 우리는 게임이 실행되는 동안 ‘SFX Reverb’를  추가하여 발자국을 편집하였습니다.

만족스러운 튜닝을 마친 상태라면 오디오 셋팅을 스냅샷으로 저장할 수 있습니다. 이 스냅샷은 오디오 혼합 상태를 저장하고 다양한 사운드 프로필을 생성하여 유용하게 활용 될 수 있습니다.

MECANIM

플레이할 준비가 되었다면 한번 실행해보십시요. 좌 클릭으로 호프(케릭터 이름)를 움직일 수 있습니다. WASD로 카메라를 컨트롤 할 수 있습니다. 이 프로젝트에는 몇몇의 에니메이션이 포함되어있습니다. 하지만, 메카님 API를 이용하면 메카님 에셋을 생성하고 편집할 수 있는 많은 종류의 툴을 만들 수 있습니다.

이 프로젝트에서는, Hope에 사용된 에니메이터를 재생성하는 버튼이 존재합니다. 스크립트는 Project 폴더에 비슷한 에니메이터를 생성합니다. 

[MenuItem ("Hope/Create Controller")]

static void CreateController () {

// Creates the controller

var controller = UnityEditor.Animations.AnimatorController.CreateAnimatorControllerAtPath ("Assets/HopeScriptCtrl.controller");

// Add parameters

controller.AddParameter("Walk", AnimatorControllerParameterType.Bool);

controller.AddParameter("TurnLeft", AnimatorControllerParameterType.Bool);

controller.AddParameter("TurnRight", AnimatorControllerParameterType.Bool);

controller.AddParameter("HalfTurn", AnimatorControllerParameterType.Bool);

// Add StateMachines

var rootStateMachine = controller.layers[0].stateMachine;

var stateMachineStand = rootStateMachine.AddStateMachine("Stand");

// Add States

var stateIdle = stateMachineStand.AddState("Idle");

var stateTurnLeft = stateMachineStand.AddState("TurnLeft");

var stateTurnRight = stateMachineStand.AddState("TurnRight");

var stateHalfTurn = stateMachineStand.AddState("HalfTurn");

var stateWalk = stateMachineStand.AddState("Walk");

stateIdle.motion = AssetDatabase.LoadAssetAtPath("Assets/Animations/Hope Animations/StandingIdleLooking.fbx", typeof(AnimationClip)) as Motion;

stateTurnLeft.motion = AssetDatabase.LoadAssetAtPath("Assets/Animations/Hope Animations/MoveStand90_L.fbx", typeof(AnimationClip)) as Motion;

stateTurnRight.motion = AssetDatabase.LoadAssetAtPath("Assets/Animations/Hope Animations/MoveStand90_R.fbx", typeof(AnimationClip)) as Motion;

stateHalfTurn.motion = AssetDatabase.LoadAssetAtPath("Assets/Animations/Hope Animations/MoveStand180.fbx", typeof(AnimationClip)) as Motion;

stateWalk.motion = AssetDatabase.LoadAssetAtPath("Assets/Animations/Hope Animations/MoveWalk_F.fbx", typeof(AnimationClip)) as Motion;

// Add Transitions

var idle2TurnLeft = stateIdle.AddTransition (stateTurnLeft);

var turnLeft2Idle = stateTurnLeft.AddTransition (stateIdle);

idle2TurnLeft.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, "TurnLeft");

idle2TurnLeft.duration = 0.025f;

turnLeft2Idle.hasExitTime = true;

turnLeft2Idle.exitTime = 0.85f;

turnLeft2Idle.duration = 0.15f;

var idle2TurnRight = stateIdle.AddTransition (stateTurnRight);

var turnRight2Idle = stateTurnRight.AddTransition (stateIdle);

idle2TurnRight.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, "TurnRight");

idle2TurnRight.duration = 0.025f;

turnRight2Idle.hasExitTime = true;

turnRight2Idle.exitTime = 0.85f;

turnRight2Idle.duration = 0.15f;

var idle2HalfTurn = stateIdle.AddTransition (stateHalfTurn);

var halfTurn2Idle = stateHalfTurn.AddTransition (stateIdle);

idle2HalfTurn.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, "HalfTurn");

idle2HalfTurn.duration = 0.025f;

halfTurn2Idle.hasExitTime = true;

halfTurn2Idle.exitTime = 0.85f;

halfTurn2Idle.duration = 0.15f;

var idle2Walk = stateIdle.AddTransition (stateWalk);

var walk2Idle = stateWalk.AddTransition (stateIdle);

idle2Walk.AddCondition(UnityEditor.Animations.AnimatorConditionMode.If, 0, "Walk");

idle2Walk.duration = 0.025f;

walk2Idle.AddCondition(UnityEditor.Animations.AnimatorConditionMode.IfNot, 0, "Walk");

walk2Idle.duration = 0.25f;

}

이 프로젝트가 여러분들께 도움이 되셨길 바랍니다. ( 에셋 스토어 링크 : https://www.assetstore.unity3d.com/en/#!/content/34352?utm_source=unity3d&utm_medium=blog&utm_campaign=ASContent_Camouflaj)

*참고 : 최종 버젼의 게임 비쥬얼은 이 프로젝트와 약간은 달라질 수도 있습니다.

들어가기에 앞서: 이 글은 2011년에 작성된 글입니다.

현재 LG와 삼성이 3D TV 시장을 놓고 박터지게 싸우고 있지요. 각각 현빈과 원빈을 모델로 앞세워 싸우는데 과연 어느 빈이 이길까요 ㅎ 모델로만 본다면 원빈이 승리? (원빈 > 현빈 >시공을 초월한 넘사벽 > you & me ) 

누구는 깜빡거린다 까고 누구는 풀HD가 아니라 까는데, 이는 안경을 사용한 S-3D 방식의 차이 때문이지요. 이 두 방식은 나중에 시간 되면 이야기 하겠습니다.

하지만, 이 메이저 리그와 다른 마이너 리그에서는 무안경 3D( Glass-free Stereoscopic 3D) 디바이스들이 각축전을 벌이시 시작합니다. 주로 모바일 장치들이 적용되서 나오고 있는데요, LG 옵티머스 3D, 삼성 W960, HTC EVO 3D, 샤프 SH-12C 등 스마트폰이 주 무대가 되고 있습니다. 하지만 코원 3D, 닌텐도 3DS 등 게임기 및 PMP등 여러 종류의 모바일 장치들에서도 나오고 있지요. 뿐만 아니라 모니터 및 TV 등 모바일이 아닌 디스플레이 시장에서도 무안경 제품이 꿈틀거리고 있지요. 본 포스팅에서는 이런 무안경 3D 기법에 대해 정리해보고자 합니다.

이 제품들은 처음 언급한 안경 방식의 TV들과는 달리 안경이 없이 입체 3D를 구현하지요. (이름 그대로 無안경, Glass-free, Glassless, Naked Eye) 안경을 쓰는 방식은 안경을 통해 필터링을 거쳐 왼쪽 눈과 오른쪽 눈에 각각에 맞는 영상을 보여주지만, 과연 안경이 없는 방식은 어떠한 방식으로 영상을 구분해서 입력을 시켜주는 것일까요? 

패렐렉스 베리어(parallax barrier)

앞서 언급한 모바일 장치들이 사용하는 방식은 패럴렉스 베리어(parallax barrier)라는 방식입니다. 디스플레이 앞에 방벽을 두어 좌안 우안의 시차를 만들어 내는 방식인데요, 그래서 시차방벽이라고도 부릅니다. 일단 기본 원리를 살펴볼까요?

우선 화면에는 수직 1라인씩 좌우 영상을 교대로 배치합니다.

이미지 출처 : http://www.osa.org/

그 전면에 영상과 같은 주기로 배리어를 설치합니다. 배리어 사이로 열린 부분을 슬릿(slit)이라 부르는데, 이 부분은 영상의 수직 1라인과 같은 시야각으로 설정 합니다.

이미지 출처 : http://www.lenstar.org/history/ch1.htm

이 것을 일정한 거리의 정면에서 보게 되면, 좌안에는 좌측 영상이 우안에는 우측 영상이 들어가게 되며 다른 눈의 영상은 차단되는 방벽의 형태가 됩니다.

이미지 출처 : http://en.wikipedia.org/wiki/

뭔가 억지스럽지만 안경 없이 볼 수 있는 실용적이고 젖절한 방식이지요. 

게다가, 이 배리어는 액정으로 만들 수 있기 때문에 2D, 3D 모드 변환은 배리어의 On/Off로 쉽게 변환이 가능 합니다. 그래서 이런 액정을 사용한 베리어 방식은 스위쳐블 페럴렉스 베리어(Switchable parallax barrier)로 불리우기도 합니다.

이미지 출처 : http://cafe.daum.net/projector

2D와 3D의 전환이 자유롭긴하지만 검은 배리어가 가리는 만큼 밝기가 반감되는 문제가 있습니다. 이런 문제때문에 3D 모드 시에는 백라이트의 밝기를 높이고, 베리어를 디스플레이와 백라이트 사이로 위치시킵니다. ( 위 그림은 배리어가 맨 위에 있는 반면, 아래 그림은 LCD가 맨 위에 있지요.)

이미지 출처 : http://www.televisions.com/tv-articles/TV-in-3D/Displaying-3D-Without-Glasses.php

또 다른 문제는 하나의 디스플레이를 좌안 우안으로 나누어 보내다 보니 체감 해상도가 줄어들게 된다는 것입니다. 공간 분할 방식의 고질적인 문제지요. 대략 이런 느낌으로 가로 해상도가 줄어들게 됩니다.

이미지 출처 : http://ozlael.egloos.com/3651808 ㅋㅋ

사진만으로는 느낌이 잘 와닿지가 않는데 세로로 줄이 쫙쫙 가 있는 느낌이라 실제로 보면 상당히 거슬립니다. 해상도 저하를 완전히 해결 할 수는 없지만, 스텝 베리어를 이용하여 해상도 저하가 수평으로 몰려 있는 것을 수평 및 수직으로 균등화 할 수도 있습니다.   

더 나가서, 배리어 두개를 맞물리게 두고 프레임 별로 바꿔서 시분할 방식을 적용할 수도 있습니다.

이미지 출처 : http://spie.org/x35370.xml?ArticleID=x35370

하지만, 밝기는 여차해서 개선하고, 해상도는 저차해서 개선한다 쳐도 가장 큰 문제는 따로 있지요. 애초에 배리어를 둘 때 관찰자의 위치를 한정하고 둔다는 것입니다. 즉, 정해진 일정 위치를 벗어나면 영상이 분리되는 등 정상적으로 보이지 않는다는 것이지요. 항상 일정한 거리에서 정면에서만 봐야 한다는 제약때문에 주로 모바일 장치에 쓰이는 기술로 굳혀버린 것입니다. 

이 제약을 개선하기 위해 동공 추적 기법( Eye-tracking, Head-tracking)을 적용하거나, 해상도가 그만큼 줄긴 하지만 아예 시점을 여러개로 만드는 방법도 있습니다.

이미지 출처 : https://physicsforme.wordpress.com/2011/06/03/3d-tv-without-glasses/

패럴렉스 배리어 방식은 현 시점에서 안경 없이 3D를 구현하기는 가장 좋은 방식이지요. 하지만 아직은 이처럼 기술 향상 시점이라 단점도 많습니다. 

렌티큘라 렌즈(Lenticular Lens)

또 다른 무안경 3D(Glass-free, Glassless, Naked Eye Stereoscopic 3D)의 방식으로는 렌티큘러 렌즈(Lenticular Lens)가 있습니다. 사실, 패러렐렉스 베리어(parallax barrier) 방식과는 달리 렌티큘러 렌즈 방식은 어릴적부터 항상 자주 접할 수 있었습니다. 어릴적 자주 보던 책받침이나 케릭터 운동화에 박혀있던 입체 영상 그림이 바로 렌티큘러 렌즈 방식이지요. 자, 그럼 기억을 더듬어 볼까요? 그 사진의 표면이 어떠했나요? 평평했나요? 아니지요. 울퉁불퉁했던 기억이 나실겁니다. 그 울퉁붕퉁한게 작은 세로형 렌즈인데 이를 렌티큘러 렌즈라고 부릅니다. 이 렌즈가 이미지를 좌우로 구분해 주는 것이지요.

일단 디스플레이에는 좌 우 영상을 번갈아 배치하는 것은 앞서 설명드린 패러렐렉스 베리어 방식과 다름이 없습니다. 대신 시차 방벽 대신에, 디스플레이의 좌우 영상 셋트의 배치 주기로 되어있는 반 원통형 렌즈의 배열 시트를 입힙니다. 수직으로 시트가 구성 되기 때문에 수직 렌트큘라 시트(Vertical lenticular sheet)라고도 부릅니다.

이미지 출처 : http://www.squidoo.com/lenticular-lens

이 렌즈의 굴절을 이용해서 좌측과 우측으로 각각 영상을 보내는 것이지요.

이미지 출처 : http://www.rays3d.net/about-lenticular.html

기본적으로는, 디스플레이 앞에 항상 물리적인 시트를 두고 있어야 하기 때문에 2D로의 변환이 불가능 합니다. 그래서 보통은 가정용 디스플레이 장치 보다는 광고 전광판이나 이미지 판촉물에 쓰입니다. 3D를 구현하는 방법 외 시각에 따라 그림이 바뀌는 효과로 쓰이기도 하죠.

하지만 요즘에는 전자식 능동형 렌티큘러(Electro-Active Lenticular)가 개발되서 상용화 되고 있습니다. 전자 액정의 분자에 전압을 가해서 굴절률을 변화 시키는 방식인데, 제가 디스플레이 전문 공돌이는 아니라서 자세한 내용은 잘 모르겠네요. ㅎㅎ  

(누가 해석점 ㅋ 마이크로 렌즈 모양의 PI로 구성된 투명한 틀 안에 액정이 채워져 있고 외부에는 전압이 가해진 상태의 액정분자와 동일한 굴절률을 갖는 물질로 이루어진 replica로 구성되어 있다. 이 구조의 마이크로 렌즈 상하에는 ITO전극이 위치하여 전압을 인가할 수 있도록 하였다. 전압이 인가되지 않는 3차원 상태에서는 내부의 액정 분자와 외부의 replica 사이에 굴절률 차이가 발생하게 되어 렌티큘러 렌즈를 통과하는 효과를 나타낸다. 반면, ITO전압이 인가되는 2차원 상태에서는 액정의 상태가 변화하여 외부의 replica와 동일한 굴절률을 갖게 되고 입력된 빛을 그대로 통과시키게 된다.)

이미지 출처 : http://www.kdia.org

하지만 딱 봐도 느껴지는 것 처럼 전자 렌즈의 제조 단가가 높아 주로 쓰이지는 않았으나, 최근 들어서는 이를 많이 적용하기 시작하는 것 같더군요.

랜티큘라 역시 패러렐렉스 배리어 방식과 마찬가지로 다중 시야( multi-view)를 구현 시 이미지 공간을 세로로 더 나누어 쓰기 때문에 세로 해상도가 급격히 줄어들게 됩니다. 이를 개선하기 위해 렌티큘러 렌즈를 정 세로가 아닌 사선으로 배치하여 개선하기도 합니다.

이미지 출처 : http://cafe.daum.net/lentienp

집적 영상 (integral image)

집적 영상 시스템(integral imaging system, 인테그랄 이미지)라는 렌즈를 이용하는 방법이 또 있습니다. 랜티큘러 시트 방식과 비슷한 컨셉인데요, 렌티큘라 시트 방식은 반 실린더를 세로로 나열 한 반면, 인테그랄 이미지 방식은 작은 반구 렌즈들을 가로 세로 나란히 배열합니다. 이 모양이 파리의 눈과 비슷한 방식이여서 파리 눈 렌즈(fly’s eye lens)라 불리기도 합니다.

이미지 출처 : http://patent2.kipris.or.kr/pat/biblioa.do?method=biblioFrame&start=biblio&searchFg=N

이러처럼 작은 볼록 렌즈의 집합을 정면으로 보게 되면 머리의 기울기에 상관 없이 입체 영상을 볼 수 있습니다. 렌티큘라 시트는 빛이 좌우 수평으로 퍼지는 반면 인테그랄 이미지는 수평만이 아닌 사방으로 퍼지기 때문입니다. 즉, 누워서도 시청이 가능하다는 것이지요. 하지만 영상을 만들어 내는 것이 간단하지도 않고 아직까지 연구가 진행중인 방식입니다.

이미지 출처 : http://en.wikipedia.org/wiki/Integral_imaging

HR3D (High-Rank 3D)

통상적으로는 무안경 입체 영상 기술은 지금까지 말씀 드린 세 방법이 대표적입니다만, 얼마 전 MIT 공돌이들에 의해 HR3D라는 새로운 기술이 발표 되었습니다. 앞의 세 방식에 비해 특이한 컨셉이 존재하는데, HR3D는 LCD 디스플레이를 두개를 사용한다는 것입니다. 패러렐렉스 베리어 방식처럼 디스플레이 앞에 베리어를 두지만 이 베리어 역시 디스플레이인 것입니다.( 상: 패러렐렉스 베리어, 하: HR3D)

이미지 출처 : http://web.media.mit.edu/~mhirsch/hr3d/

패러렐렉스 베리어는 일정한 패턴으로 좌우 영상이 존재하고 그에 상응하는 주기로 장벽이 존재하지만, HR3D는 복잡하고 경이로운 수학의 세계(?) 를 거쳐 영상에 최적화 된 패턴을 만들어내고 그에 의해 후면 패널 영상과 전면 패널의 장벽이 만들어 집니다. (패턴 만들어 내는 공식은 알지도 못하겠고 알고 싶지도 않아요;;)

이토록 동적인 장벽이 만들어 지므로 시선의 방향 및 기울기에 구애 받지 않고 입체 영상을 만들어 낼 수 있습니다. 즉 관찰자가 어디 있던지 유동적으로 대처가 가능 하다는 것이지요. 또한 장벽으로 인한 밝기 저하가 없고 그에 따라 백라이트 전력도 절약 된다고 합니다. 뭐, 실제로 보지도 못했고 발표된지 1년도 채 안된 기술인지라 약을 파는 것인지 뭔지는 잘 모르겠습니다만 점차 시간이 지나면서 상용화가 시작되면 본격적으로 검증이 되겠지요. :-)

홀로그래피(Holography)

사실 제일 궁극의 무안경 3D 입체 영상 기술은 홀로그래피(Holography)이죠. 홀로그램(hologram)이라고도 불리는데 엄밀히 따지자면 기술 자체의 명칭은 홀로그래피이고 홀로그램은 이로 인해 만들어지는 컨텐츠를 가리킵니다. 어쨌든간에 뭐 아직까지는 미래 기술이고 미 국방부쯤은 되어야 쓸까 말까 정도니 자세히 다루지는 않겠습니다. (어짜피 저도 잘 모르고 ㅎㅈㅎ)

이미지 출처 : http://blogs.vassar.edu/ltt/2011/04/01/a-look-into-the-structure-and-creation-of-holograms/

하지만 현재 어느정도는 만들어 낼 수 있고 지속적으로 연구가 되고있습니다. 현존하는 방식 또한 여러 가지가 존재하는데 그 중 하나로 360º Light Field Display란 방식이 있지요. 욜라 빨리 회전하는 거울판에 빛을 투영시키는데, 거울의 회전 각에 맞는 영상을 내 보내서 마치 입체적으로 영상이 존재하는 것 처럼 보이게 하는 방식입니다. 뭔가 ㅄ같지만 멋있어

이미지 출처 : http://gl.ict.usc.edu/Research/3DDisplay/

뭐 이처럼 지속적인 홀로그래피 기술이 연구되고 있으니 죽기전에는 집 거실에서 홀로그램을 볼 수 있겠지요. 20년 전 우리가 콧물 질질 흘리며 동네 문방구에서 오락할 때 까지만 해도, 거실에 있는 PlayStation이나 XBOX로 3D 게임을 즐기는 모습을 상상이나 할 수 있었습니까? 앞으로 20년만 참고 기다리면 디스플레이 공돌느님들이 홀로그램쯤은 거뜬히 만들어 줄 테니 꾹 참고 기다립시다. 

끝으로 이 세계의 공돌이들을 찬양하며 이만 줄일까 합니다. May the force be with you!

Stereoscopic 커뮤니티 및 각종 관련 문서들을 보면 참고 이미지로 좌안 우안의 이미지를 나란히 나열하는 것을 볼 수 있습니다.

들어가기에 앞서 : 이 글은 2012년도에 작성한 글입니다 :)

들어가며

 현재 전 세계적으로 3D 입체 영상의 붐이 일고 있고, 게임업계도 이에 편승하여 입체 영상을 지원하는 게임들을 발매하고 있습니다. UBI 소프트는 2012년에는 절반 이상의 타이틀이 정식으로 입체 3D를 지원할 것이라고 발표하기도 하였습니다. 실제로도 스타크래프트 2, 크라이시스 2, 베틀필드 3 등 최근 출시작들은 거의 다 입체 3D를 지원하고 있지요. 곧 있으면 나올 디아블로 3도 입체 영상을 지원하는 것으로 알려져 있습니다. PC 뿐안 아니라 엑박,플스 등 콘솔 게임기도 3D 입체 영상을 지원하지요. 닌텐도는 3DTV 보급률이 20%를 넘었을 시 콘솔에서 입체 3D를 지원할 예정이라고 발표하였지만, 휴대기기에서는 닌텐도 3DS를 발표할 만큼 적극적인 관심을 보이고 있지요. 또한 게임기 뿐만 아니라 LG,HTC,샤프 등에서 입체 3D를 지원하는 스마트폰을 출시하며 각종 게임들과 연계하고 있지요. 노트북도 지원 모델들이 본격적으로 출시되기 시작했습니다. 이토록, 입체 3D 게임은 거실뿐만아니라 모바일까지 그 영역을 확대해 나가고 있습니다.

하지만 이에 비해서 모든 게이머가 입체 3D ( 이하 Stereo 3D 혹은 S3D라 일컫겠습니다) 게임을 선호하지는 않지요. KOCCA의 보고서를 보면 29%만이 S3D 게임을 선호하고 있습니다. S3D가 전혀 필요 없어보이는 TV쇼보다 그나마 높은 수준정도밖에 되지 않지요. 

휴면 팩터

왜 그런 것일까요? 안경을 끼고 시청해야 하는 불편함도 있겠지만은 멀미나 피로감 등에 그 주된 원인이 있다 볼 수 있겠습니다. 영화는 길어봐야 2시간의 러닝타임을 가지고 있고 어느정도 그러한 피로감을 감수할만 하겠지만, 게임은 그렇지가 않지요. (원래 권장은 2시간입니다만;;) 장시간동안 피로감과 멀미 등의 휴먼 팩터에 노출되기 때문에 사용자들은 거부감이 들 수 밖에 없게 되는 것입니다. 이러한 휴먼 팩터들은 아직도 활발히 연구가 되고 있고, 게임 개발자들 또한 이를 이해하고 다루어야 할 것입니다.


동요병

 흔히 멀미라 불리우는 동요병(motion sickness)은 흔들림이나 회전에 의해 불쾌감, 구토, 식은땀 등을 동반합니다. 이 동요병은 S3D 영상의 휴먼 팩터 중 하나지요. 
 우리는 그동안 학교에서 배운 멀미의 원리는 내이과잉자극설(over stimulation theory)이라고 합니다. 전정 감각이 신체의 평형감각에 중요한데, 열차 및 자동차의 진동에 의한 가속도가 달팽이관이 있는 내이를 무리하게 자극한다는 것이죠. 


감각불일치설
.
 하지만, 가만히 앉아서 게임을 하는데도 멀미를 느끼게 됩니다. 이러한 영상 멀미는 감각불일치설(sensory conflict theory)로 설명이 되고 있습니다. 신체는 평소에 자신의 위치나 움직임 등을 다양한 감각 정보로 취득합니다. 하지만, 영상만 보면 신체정보와 눈으로 입력되는 패턴이 일치하지 않게 되지요. 이러한 정보들을 짜집기하면서 동요병이 발생을 하게 되는 것입니다. 특히 FPS 등 움직임이 급격한 게임이 감각불일치로 인한 영상 멀미가 쉽게 일어나지요. 이러한 영상 멀미가 있는 상태에서 S3D로 게임을 즐기게 되면 안정피로(asthenopia)가 더해져서 그 부작용은 더더욱 커지게 됩니다.


안정피로

지속적인 시각 작업이나 집중을 하게되면 피로해지고 눈이 침침해지며 통증, 두통, 어깨결림을 수반하게 되고 심하면 구토 증세까지 보이기도 합니다. 이러한 현상을 안정피로라고 합니다. 극도로 정신이 긴장하여 발생하는 것은 신경성 안정피로(nervous asthenopia)로 분류됩니다. 게임에 너무 몰입해도 발생할 수 있는 현상이지요. 수정체의 과부하나 초점 조절로 인하여 생기는 것은 조절성 안정피로(accommidative asthenopia)로 분류됩니다. 기본적으로 신경성 안정피로가 발생하는 게임을 S3D로 영상을 보게되면 조절성 안정피로가 더해지는 것이지요.


폭주와 초첨의 불일치

사람이 사물을 바라볼 때는 두 눈의 주시선이 무한히 평행히 뻗어나가는 것이 아니라 한 지점에서 교차를 하게 됩니다. 그 교차점이 주시의 대상이 되는 것이고, 이러한 능력을 폭주 혹은 수렴이라 부릅니다. 그리고 눈의 수정체를 조절하여 초점을 맞추는 대상이 폭주 대상과 일치하게 됩니다.
 하지만 S3D 영상을 보게되면 이 폭주 대상과 초점 대상이 어긋나게 됩니다. 사람의 물리적인 초점은 모니터 스크린에 맺히게 되지만 폭주 대상은 모니터의 위치가 아닌 입체 공간의 어딘가가 되는 것이죠. 이러한 증상을 폭주와 초점의 불일치(Vergence-accommodation mismatch)라 부르는데, 이러한 불일치를 조절하게 되면서 조절성 안정피로가 일어나게 되는 것입니다. 

영상 왜곡

이러한 영상멀미나 안정피로등은 개인차가 큽니다. FPS를 해도 어떤 사람은 멀미를 일으키지만 어떤 사람은 하루 종일 해도 멀미가 일어나지 않기도 하지요. S3D 영상은 그 개인차가 더 심하게 나타납니다. 영상 왜곡까지 더해지면 그 후폭풍은 감당하기 힘든 수준이 되지요. 이러한 휴먼 팩터들은 게임 뿐 아니라 모든 장르의 S3D 시장 발전의 저해 요소가 되고 있습니다. 그렇기때문에 앞서 말씀드렸다시피 활발한 연구가 이루어지고 있고 표준 규약 또한 만들어지고 있지요. 특히 영화나 에니메이션 등 영상 컨텐츠는 영상의 깊이감을 많은 사람들이 평균적으로 수용 가능한 값으로 설정하고 있습니다.
 하지만 게임은 이러한 점이 다소 자유롭습니다. 사용자가 영상의 깊이감을 조절을 할 수 있기 때문이지요. 사용자는 자신의 팩터에 맞게 깊이감을 조절하여 멀미나 피로를 최소화 하여 게임을 즐길 수 있습니다. 그렇기때문에 개발자는 이러한 사용자의 조절을 반드시 지원 해 주어야 할 것입니다.

이 휴먼 팩터는 영상 왜곡과 합쳐지면 더 많은 부작용을일으키게 된다고 말씀 드렸었는데요, 이번에는 그 영상 왜곡에 대하여 말씀 드리고자 합니다.

아시다시피 입체 영상은 좌안의 영상과 우안의 영상을 따로 만들어 내서 각각의 눈의 망막에 각각의 영상을 보여 주는 방법으로 구현되지요. (보여주는 방법은 이 글에서는 다루지 않겠습니다. 무안경 방식은 이 글을 참고하세요.)

이 좌안 우안을 신경쓰지 않고 만들다보면 많은 영상 왜곡(Image Distortion) 현상이 일어나기도 합니다. 이러한 왜곡은 심하게는 좌우 영상이 합쳐지지 않고 깨져보이는 지경까지도 이르게 됩니다. 이 글에서는 몇 가지의 영상 왜곡에 대해 다루어 보도록 하겠습니다. 


예측 불가능한 제시 조건에 의한 왜곡

모니터(스크린)의 크기, 시청자의 위치, 시청 각도 등 예측 할 수 없는 제시 조건에 의한 왜곡들도 발생을 합니다. 컨텐츠 제작시 예측했던 스크린의 크기나 시청 거리에서 어긋나게 되면, 상의 깊이감이 변하거나 폭이 왜곡 되는 것이죠. 
3D 영화관의 경우 극장마다 상영관마다 스크린의 크기가 다릅니다. 상영관마다 입체 영상의 폭이 다르게 느껴진다는 것이지요. 또한 같은 오브젝트라도 앞좌석에서 보는 깊이감과 뒷좌석에서 보는 깊이감이 다르게 느껴지게 됩니다.

또한, 정면이 아닌 측면에서 관람하게 되면 상이 정면을 향하는 것이 아니라 관찰자가 있는 측면을 향해 있는 것 처럼 느껴지게 됩니다. 영화 상영관 내에서도 좌석의 위치에 따라서도 보여지는 상이 왜곡 될 수 있는 것이죠. 이러한 현상을 전단왜곡(shear distortion)이라 부릅니다.

 흔히들 영화에 따른 영화관의 명당이 있다고들 하는데, 괜히 나온 말이 아니라 이러한 이유들 때문에 정말 명당이 존재하는 것이죠. 영화의 경우는 영화관의 크기 차이가 그렇게 다이나믹 하지는 않습니다. 시야 각도 허용할 만한 수준 내에서 구성이 되도록 자리가 배치되어 있지요. 
 하지만 이러한 왜곡 현상은 게임에서는 심하게 나타납니다. 게임을 즐기는 유저의 모니터 크기는 천차만별입니다. 방에서 22인치 모니터로 게임을 즐길 수 도 있고, 거실에서 55인치 대형 3DTV로 게임을 즐길 수도 있는 것이죠. 시야각 또한 마찬가지입니다. 혼자 게임을 즐긴다면 당연히 정면의 시야각으로 즐기게 되겠지만, 여러명이 모여서 게임을 하고 구경도 하고 한다면 시야각은 다양해지게 될 것입니다. 
 하지만 사실 게임을 제작하면서 이러한 유저들의 모든 시청 스펙을 예측하기란 불가능하지요. 다만, 평균적인 구성을 예측하고 그에 맞는 기본 환경 설정이 되어있어야 할 것입니다.


망막경합 (Retinal Rivalry)

앞서 말씀 드렸듯이 좌우 영상을 좌우 망막에 각각 따로 받아들이고 뇌가 이를 합성하여 입체정보로 만들어 내면서 입체영상이 만들어지게 됩니다. 그런데, 좌측 영상에는 있는 물체가 우측 영상에는 존재하지 않거나 좌측과 우측의 모습이 과도하게 다르다면, 뇌는 이 물체에 대해 제대로 지각하지 못하게 됩니다. 물체가 깜빡이게 보이거나 엉뚱한 깊이에 있게 느껴지게 되지요. 이러한 상황을 망막경합 (Retinal rivalry)  또는 양안경합 (Binocular rivalry) 이라 부릅니다. 예를 들어 아래 이미지에서는 여성과 석상이 망막경합을 일으킵니다.

이러한 현상은 소위 적청안경이라 불리우는 애너글리프 방식에서는 쉽게 일어날 수 있습니다. 애너글리프 안경의 색깔에 가까운 색으로 이루어진 오브젝트는 한 쪽의 눈에만 전달될 수 있는 것이죠. 만일 게임을 적청안경으로 시연해야 하는 상황이라면, 오브젝트의 색은 완전 적색이나 완전 청색 등은 최대한 피해야 할 것입니다.(근데 그런 시연 상황이면 그냥 입체영상으로 보여주지 말아요)


키스톤 왜곡(Keystone Distortion)

오브젝트가 카메라에 상당히 가까이 있을 시, 그 상의 좌측 영상과 우측 영상의 높이 차가 발생하기도 합니다. 이러한 경우는 두 이미지를 뇌가 하나의 상으로 합치는데 어려움이 따르게 됩니다. 이러한 상황을 키스톤 왜곡이라 부릅니다. 

 특히, FOV가 과도하게 설정 되어 있는 경우는 이러한 왜곡이 심하게 발생하게 됩니다.


윈도우 위반 (Window Violation)

좌측 영상의 카메라와 우측 영상의 카메라는 각각의 뷰 프러스텀을 가지게 됩니다. 그러다보니 좌우 카메라의 프러스텀이 공통적으로 속하지 않는 영역이 존재하게 되지요. 

 그 부분은 투영된 영상으로 치면 화면의 좌우 각각의 끝부분이 이에 해당합니다. 그래서 화면의 좌우 끝에서는 망막 경합이 일어나게 됩니다. 다음 이미지를 보면 좌측 영상에는 있는 A1 파란 점과 I1 주황색 점이 우측 영상에는 존재하지 않습니다. 

이러한 현상을  윈도우 위반(Window Violation)  또는 프레임 위반(Frame Violation)이라 부릅니다. 극장같은 큰 상영관에서는 이러한 현상이 있다 하더라도 보통은 이를 알아채지 못하고 넘어가게 됩니다. 하지만 커봤자 40인치 정도인 모니터에서 즐기게 되는 게임은 이러한 윈도우 위반이 쉽게 인지됩니다. 
 nVidia 3D Vision, iZ3D, DDD 등의 입체 영상 미들웨어들은 윈도우 위반을 해결하는 방법을 제공해주기도 합니다. 보통은 프러스템이 겹치지 않는 영상의 끝부분은 잘라내는 극악의 방법이지요. 하지만 이러한 방식은 화면 밖으로 튀어나오는 오브젝트까지 완벽히 커버하지는 못합니다. 그렇기 때문에 화면 안에 완전히 투영되지 못하는 큰 오브젝트가 화면 밖으로 튀어나오면 윈도우 바이얼레이션 문제가 발생을 합니다. 
 컷씬을 제작하다보면 입체 영상에서 극적인 장면을 연출하기 위해 오브젝트를 화면 밖으로 튀어나오게 하고싶은 경우가 있을것입니다. 그러한 경우는 오브젝트를 반드시 화면 가운데 위치시켜야 하고, 화면 영역을 벗어날 정도로 큰 오브젝트는 금지하여야 할 것입니다. 


마치며

이 글에서 설명 드린 왜곡 외에도 수 많은 입체 영상 왜곡 현상들이 존재합니다. 영화나 에니메이션은 이러한 왜곡 현상들을 발생시키지 않기 위해 많은 노력을 하면서 제작을 하고 있습니다. 항상 고정된 영상의 컨텐츠이기 때문에 왜곡 현상을 거의 없앨 수 있지요. 
 하지만 게임은 실시간으로 영상을 만들어 내는 컨텐츠이기 때문에 모든 왜곡 현상을 막는다는 것은 불가능에 가까울 것입니다. 다만, 이러한 왜곡 현상에 대해 잘 숙지하고 최대한 예방할 수 있는 방향으로 개발을 해야 할 것입니다. 
 이전 글에도 말씀드렸지만, 게임은 휴먼 팩터에 대한 영향이 크고 입체영상으로 즐기는 것에 대한 부담이 큰 컨텐츠입니다. 그러한 부담을 유저가 조금이라도 덜 느끼고 장시간 쾌적하게 즐길 수 있도록 제작을 해야 할 것입니다.
 

본 포스팅은 유니키 공식 블로그 TUESDAYS ARE FOR #UNITYTIPS를 번역한 글입니다.

1. 유니티가 플레이모드 중일때 가끔 이를 잊어버리는 경우가 있습니다. ‘Preferences’ > ‘Colors >  Playmode Tint로 기억하기 쉬운 색으로 설정하세요.

2. 쉽게 카메라를 포지셔닝할 수 있습니다. 씬뷰에서 화면 앵글을 원하는 상태로 놓고 메인 카메라를 선택합니다. 그리고 Align With View를 선택하거나 Ctrl/Cmd + Shift + F 를 누르면 씬뷰에서 바라보는 방향 및 위치로 메인 카메라가 셋팅됩니다.

3. 프로젝트 뷰에서 에셋스토어의 에셋을 검색할 수 있습니다. 프로젝트 뷰에서 검색할 단어를 입력한 뒤 Search를 Assets에서 Asset Store로 변경하세요. 그러면 에셋스토어를 열지 않고도 에셋스토어의 에셋을 미리 볼 수 있습니다.

4. 오브젝트를 회전시킬 시 Ctrl/Cmd를 누른채로 조작하면 스냅되어 회전합니다. 이는 오브젝트를 움직일 때도 마찬가지입니다. 스냅 기본값은 Edit 메뉴의 Snap Settings에서 변경할 수 있습니다.

5. 또 다른 스내핑 트릭입니다. 오브젝트를 선택하고 이동 시 V키를 누른채로 조작하면 버텍스 스내핑이 가능합니다. 이는 특히 모듈화된 지오메트리로 레벨을 구축 할 시 유용합니다.

6. 인스팩터 창의 컴포넌트에 있는 파란 물음표 책 버튼을 누르면 해당 컴포넌트의 도움말을 볼 수 있습니다.

7. 플레이모드에서 재생하고 테스트 중 컴포넌트의 완벽한 값을 발견했나요? 컴포는트에 있는 작은 톱니바퀴 모양의 아이콘을 눌러서 Copy Component를 선택하세요. 플레이모드를 빠져나온 후 그 값을 붙여넣을 수 있습니다.

8. Layers 버튼을 이용하여 특정 레이어의 오브젝트들을 보여주거나 숨길 수 있습니다.

9. 프로파일러 창에서 그래프가 너무 난잡한 경우에는 확인하고싶은 데이터(드로우콜, 스크립트, V싱크 등)의 색상이 칠해진 사각형을 끄고 킴으로써 보고싶은 데이터만 확인할 수 있습니다. 

10. 유니티 에디터의 레이아웃 배치를 편집하고 저장할 수 있습니다. Windows > Layouts > Save / Delete Layouts

RPG든 액션이든 어떠한 장르에서든 스킬 시스템이 있는 게임은 쿨타임이란 것이 존재합니다. 그리고 이러한 쿨타임은 시각적으로 보여 줄 시 다양한 형태로 표현하지만 크게두 가지 형식으로 표현합니다. 시계/반시계 방향의 부채꼴 또는 수직/수평으로 영역을 채우는 이미지로 표현하는 것입니다.

유니티의 이전 버젼에는 이러한 버튼을 표현해주는 기능이 없어서 직접 구현하거나 플러그인을 사용하여야 했습니다. 하지만 유니티 4.6부터 GUI 시스템이 대폭 개선되어 많은 기능들이 추가되었었습니다.

이 새로운 UI 시스템에서는 이미지를 다루는 기능 역시 대폭 향상되었습니다. Filled 타입 이미지가 추가되었고 이로 인해 손쉽게 쿨타임을 표현해줄 수 있게 되었습니다. 

일단 Hierarchy > Create > UI > Button 으로 버튼을 추가하면 Canvas란 것이 생기고 그 아래 Button이 생긴 것을 확인하실 수 있습니다. 이 Button의 Inspector을 확인해보면 Image와 Button 컴포넌트가 있습니다. 이 중 Image컴포넌트의 Source Image를 원하는 이미지로 바꿔줍니다. 이 때 Source Image는 Sprite 타입의 텍스쳐만 사용 가능합니다. 이미지를 설정 후 Image Type을 Filled로 바꾸면 하위 항목 중 Fill Amount 슬라이더가 생깁니다. 이 슬라이더 값을 0에서 1로 조절 시 이미지가 이에 따라 채워지는 영역이 생깁니다. 쿨타임에 맞게 이 값을 업데이트 해주면 쿨타임 버튼이 되는 것입니다.

다만, 보통은 원래 이미지의 색으로 채워지는 영역 배경에 흑백 또는 어두운 이미지가 존재합니다만 Filled image의 배경 기능은 없습니다. 따라서 같은 위치에 배경을 추가해줘야 합니다. 배경은 단순 이미지만 배치하면 되므로 Create > UI > Image로 이미지를 추가하여 Source Image를 설정해준 뒤 Color을 조절하여 어두운 이미지로 만들어줍니다. Hierarchy에서의 순서가 곧 렌더링 되는 순서이므로 이를 변경하면 됩니다. 배경으로 삼을 이미지를 버튼의 위로 배치하시면 버튼이 배경 위에 그려집니다.

이제 버튼 추가는 다 되었으므로 스크립트를 추가해줘야합니다. 스크립트에서는 쿨타임 값에 맞게 Fill Amount를 조정해주는 동작을 합니다. 또한, 쿨타임 중일 시에는 버튼이 동작하지 않도록 해주어야 합니다. 이러한 내용을 스킬 시스템이나 로직 스크립트에서 직접 컨트롤을 해주어도 되지만 쿨타임 버튼만을 담당하는 스크립트를 만들어두면 버튼을 추가할 때 마다 훨씬 개발하기 수월해질 것입니다.

Project 창에서 우클릭 > Create > C# Script로 스크립트를 하나 생성합니다. 저는 이름을 CoolTimeButton이라고 지었습니다. 스크립트의 내용을 다음과 같이 채웁니다.

버튼이 채워지는 값은  쿨타임 값을 0~1로 변환하여 Image.fillAmount로 설정해주면 됩니다. 쿨타임 동안은 버튼이 작동하지 않도록 하는 것은 Button 컴포넌트의 enable을true/false로 설정해두면 됩니다. 이러한 제어를 매 Update()마다 처리해주는 것입니다. 

스크립트를 완성 후 버튼에 스크립트를 추가해줍니다. 

그럼 이제 버튼이 눌렸을 시 CoolTimeButton 스크립트의 메소드를 호출하도록 하면 됩니다. 이를 위해서 버튼의 Button 컴포넌트 하단의 On Click() 에 있는 +버튼을 눌러서 콜백을 추가해줍니다. Realtime Only 콤보박스 하단의 오브젝트 항목에 버튼 오브젝트 스스로를 설정해주면 Realtime Only 콤보박스 옆의 No Function 콤보박스가 활성화됩니다. 그 콤보박스에서 CoolTimeButton.ResetCooltime()을 설정해줍니다. 이리함으로써 버튼이 눌리었을 시 CoolTimeButton의 ResetCooltime()이 호출되어 쿨타임이 다시 카운팅됩니다. 쿨타임중일 시에는 CoolTimeButton.Update()에 의해 비활성화 처리되므로 버튼을 눌러도 아무런 반응을 하지 않습니다. 쿨타임 자체의 처리는 이제 완료가 되었습니다. 버튼에 연결된 스킬이나 아이템의 스크립트는 마찬가지로 On Click()의 +버튼을 한번 더 눌러서 콜백을 연결해주면 됩니다(아래 예시에서는 SkillNotify). 콜백은 이토록 여러개를 설정 할 수 있어서 다양한 작업을 처리할 수 있습니다.

이처럼 유니티의 새로운 UI기능을 사용하면 UI 작업을 훨씬 수월하게 처리할 수 있습니다. 새로운 UI 시스템의 더 많은 것을 알고싶으시면 공식 튜토리얼 및 에셋스토어 예제를 참고 바랍니다. 감사합니다.

Unity New GUI 튜토리얼 : 

http://unity3d.com/learn/tutorials/modules/beginner/ui

에셋스토어 예제 : 

https://www.assetstore.unity3d.com/en/?gclid=CjwKEAiAjsunBRCy3LSlz_PJqCgSJACJY7yKSmdicbryiDMHiOPX-rMfA-bLLkmb7SBsnl0VSAkYLxoCcNTw_wcB#!/content/25468

본 포스팅은 유니티 공식 블로그의 "Working with Physically Based Shading" a practical approach"를 번역한 것입니다.

유니티5 베타를 사용중이시라면 에셋 스토어에서 바이킹 마을 데모를 다운받아서 확인해보실 수 있습니다. 이 데모에서는 유니티5에서 씬의 조명을 어떻게 구성해야 하는지에 대한 안내를 받을 수 있습니다.

데모 영상 : http://youtu.be/iV-224nMwN8

데모 다운로드 : https://www.assetstore.unity3d.com/en/#!/content/29140

견본 환경 만들기

텍스쳐링과 셰이더 설정을 알맞게 결정하기 위해서는 간단한 신을 다양한 라이팅 셋업으로 테스트해보는 것을 추천합니다. 이는 각기 다른 스카이박스와 라이팅 등 모델의 조명에 연관되는 것 들을 의미합니다. 유니티5를 열면 빈 씬이 기본적으로 절차적으로 생성 된 하늘이 포함 된 것을 확인 가능합니다. 이는 기본 환경광과 반사 셋팅을 포함하고 있습니다. 

템플릿 환경에서는 다음 사항들이 준비되어있어야합니다.

- HDR 카메라 렌더링

- 몇 개의 리플렉션 프로브

- 라이트 프로브의 그룹

- HDR 하늘텍스쳐와 재질(material)들의 셋. 이 프로젝트에 포함된 하늘은 유니티를 위해 커스텀하게 만들어진 것이 사용되었습니다.( 제작자:Dutch Skies 360)

- HDR 하늘 색과 강도가 맞춰진 미색의 방향성 광원(directional light)

스카이 텍스쳐 파라미터 조절

대부분의 하늘 텍스쳐는 이미지 자체에 태양 및 플레어를 포함하고 있습니다. 하지만 이는 다음 이유들로 인해 잠재적인 문제가 됩니다.

- 디렉셔널 라이트의 방향을 잡을 시 텍스쳐에 그려진 태양과 맞춰야만 하는 제약이 생깁니다.

- 강렬한 스페큘라 하이라이트떄문에 반사된 태양과 스페큘러 핫스팟이 겹쳐버립니다. 

- 미리 그려진 태양의 반사가 그림자 영역에서 가려지지 않습니다. 이는 어두운 영역에다 어색한 반짝임을 만들어버립니다.

때문에, 태양의 하이라이트, 플레어, 태양광 및 HDR 값은 하늘 텍스쳐 외부(주로 디렉셔널 라이트)에서 편집되어야합니다. 

물리 기반 셰이딩 재질 

유니티5의 스탠다드 셰이더는 스페큘러 컬러와 메탈릭 워크플로우 둘 다 제공하고 있습니다. 둘 모두 표면에 반사하는 색을 정의하고 있습니다. 스페큘러 워크플로우에서는 색상이 직접적으로 명시됩니다. 반면 메탈릭 워크플로우에서는, 디퓨즈 색상과 메탈릭 값의 조합으로  색상이 만들어집니다. 

에셋 스토어에서 캘리브레이션(Calibration) 씬을 받아보실 수 있습니다. 이 씬은 각종 측정용 차트를 포함하고 있습니다. 바이킹 프로젝트에서는 스페큘러 컬러 워크플로우로 만들어졌는데, 이 차트를 참고하며 진행하였습니다.

스페큘러 워크플로우에서는 반사광의 스페큘러 색상을 직접 선택 할 수 있습니다. 반면 메탈릭 워크플로우에서는 재질이 조명될 때 메탈처럼 작동할 것인지에 대한 선택을 할 수 있습니다. 두 워크플로우 모두 최종적으로는 동일한 결과를 만들어 낼 수 있습니다. 따라서 작업 진행을 스페큘러 워크플로우로 할 것인지 메탈릭 워크 플로우로 할 것인지는 순전히 작업자의 기호에 맞추어 선택하면 됩니다. 

스페큘러 값 차트:

메탈릭 값 차트:

재질 설정하기

재질을 만들 시, 테스트 용도의 깨끗한 재질을 만들어 두면 유용합니다. 이 재질에다 측정용 챠트로부터 색상 등의 값을 적용합니다. 그 후 텍스쳐를 적용한 결과와 비교해보면 재질 본래의 느낌을 확인해볼 수 있습니다.

텍스쳐 제작의 전통적인 방법

바이킹 마을 데모에 쓰인 텍스쳐들은 사진 등의 데이터로부터 스캔한 디퓨즈/알베도, 스페큘러, 노말맵 등을 사용합니다. (제공 : Quixel) 텍스쳐에 디테일을 추가할 때는 주의할 점이 있습니다. 예를 들자면, 일반적으로는 텍스쳐에 미리 AO나 그림자 등의 라이팅을 적용해서 그려넣기도 합니다. 하지만 물리 기반 렌더링에서는 엔진에서 모든 라이팅을 제공해주기때문에 텍스쳐에 미리 그려넣으면 안됩니다. 사진을 수정하는 작업은 이러한 리터칭이 많이 들어가야해서 PBS 스캐닝 된 데이터보다 부담이 큽니다만 Quixel Suite나 Allegorithmic Substance Painter를 이용하면 이러한 과줭이 한결 수월해집니다.

스캔 데이터

PBS 대응하여 스캔된 데이터는 편집하기가 좀 더 편합니다. 알베도, 스페큘러, 매끄러움 등이 이미 분리된 데이터이기때문입니다. PBS 데이터를 만들어 주는 소프트웨어가  유니티 프로필에 대응되어있다면 더욱 좋을것입니다. 

재질 예시

바이킹 마을 씬은 많은 적절한 메모리의 텍스쳐를 사용하여 많은 양의 컨텐츠를 나타내고 있습니다. 그 예로 10미터 크기의 나무 크레인 모델을 살펴보겠습니다.

예시 1: 크레인 오브젝트는 2개의 재질을 가집니다. 2개의 디퓨즈 텍스쳐, 1개의 스페큘러-매끄러움 텍스쳐, 2개의 오클루전 텍스쳐, 2개의 디테일 텍스쳐

예시 2: 방패 프랍은 1개의 재질을 가집니다. 1개의 디퓨즈맵 텍스쳐, 1개의 스페큘러(specular)-매끄러움(Smoothness) 텍스쳐, 1개의 오클루전 텍스쳐를 가집니다. 디테일 텍스쳐는 없습니다.

알베도 텍스쳐 : 스페큘러 워크플로우에서는, 알베토 텍스쳐는 표면에 반응하는 디퓨즈 라이트의 색상을 나타냅니다. 왼쪽 이미지 (크레인)에서는 너무 그렇게 높은 디테일을 필요로하지는 않습니다. 반면 오른쪽 텍스쳐 (방패)는 높은 디테일을 포함하고 있습니다.

크레인의 디퓨즈맵은 나무의 색상으로 평범하게 이루어져있습니다. 디테일도 그냥 적당한 정도로만 이루어져있습니다. 반면 오른쪽에 있는 방패의 이미지는 높은 디테일을 가지고 있습니다.

크레인 재질의 디퓨즈 색상 값

스페큘러 : 논-메탈(비전도체)는 비교적 어두운 그레이스케일의 스페큘러 색상을 가집니다. 반면 메탈은 더 밝고 고유 색상을 띄는 스페큘러를 가집니다. ( 녹슬거나 기름때나 먼지가 있는 부분은 메탈릭이 아닙니다.) 

좌측은 메탈을 표현하기 위한 크레인의 스페큘러 맵(메탈릭 셰이더를 사용하지 않음. 스페큘러 워크플로우). 우측은 방패의 스페큘러 텍스쳐

나무의 표면은 전반적으로 스페큘러가 거의 없다시피합니다. 따라서 나무의 스페큘러는 텍스쳐를 사용하는 대신 단순 생삭값으로 대체합니다.

매끄러움(Smoothness)은 PBS 재질의 핵심 속성중 하나입니다. 이는 재질의 상태, 변화, 결점, 디테일 등을 표현하고 물체가 오래되었는 지 등에 대한 시각적인 힌트를 제공해줍니다. 크레인의 경우, 거칠기가 재질 전반적으로 동일하기때문에 따로 텍스쳐로 사용되지 않고 단순한 값으로만 대체될 수 있습니다. 그 덕에 텍스쳐 메모리를 절약할 수 있습니다.

크레인에 있는 나무의 매끄러움. 텍스쳐 대신 단순 값으로 사용함.

메탈의 표현하기 위한 크레인의 매끄러움 맵(메탈릭 셰이더를 사용하지 않음. 스페큘러 워크플로우). 우측 이미지는 방패의 매끄러움 맵을 나타냄. 나무와 메탈 표면이 공존.

오클루전(Occlusion)은 얼마나 표면이 돌출되었는지에 대한 정보를 빛에 반응하여 나타냅니다. 앰비언트 오클루전(Ambient Occlusion)은 표면의 디테일과 높이를 주변광과 반사광 등으로 표현을 해줍니다. SSAO(Screen Space Ambient Occlusion)을 사용하는 것도 염두해두어야합니다. SSAO와 AO를 같이 사용하게되면 배로 어두워지는 경향이 생길 수 있습니다. AO맵으로 크랙이나 접합부 등을 강조하는데 쓰일 수도 있습니다. 게임이 SSAO나 라이트맵의 AO를 쓰는 경우엔 적합한 용도가 될 것입니다.

첫번째 이미지는 라이트맵 AO, 두번째 이미지는 오클루전 텍스쳐, 세번째 이미지는 디퓨즈의 오클루전, 네번째 이미지는 이미지 효과 SSAO를 보여주고 있습니다.

부가 텍스쳐와 해상도

부가(secondary) 텍스쳐는 디테일의 레벨을 증가시켜주거나 재질의 변화를 제공하는데 쓰일 수 있습니다. 디테일 마스크 속성을 사용하는 것으로 마스킹 될 수 있습니다.

크레인의 디퓨즈 텍스쳐는 비교적 낮은 해상도로 이루어져 있습니다. 이러한 경우 부가 텍스쳐로 표면의 디테일을 부여해줄 수 있습니다. 디테일맵은 타일링되어 표면에 전반적으로 반복되어 집니다. 때문에 낮은 해상도로도 높은 디테일을 표현해줘서 메모리를 절약 할 수 있습니다.

부가 알베도맵과 노말맵은 저해상도의 디퓨즈와 노말맵을 보완해줍니다. 아래 이미지는 크레인의 표면 비교. 왼쪽은 부가 텍스쳐 사용. 오른쪽은 사용 안함.

에셋 스토어 링크 : https://www.assetstore.unity3d.com/#!/content/29140

* 이 글은 Game Development Forever에도 동일하게 기재되었습니다. (http://gamedevforever.com/326)

* 샘플 프로젝트를 받아서 확인해보세요 : https://github.com/ozlael/PlannarShadowForUnity

그래픽을 표현하는데 있어서 그림자는 매우 중요합니다. 그림자가 존재함으로써 사물의 공간상 위치를 인지하기 쉽게 만들어주고 입체감을 더해주게됩니다. 그림자는 입체 공간을 구성하는데 있어 거의 필수적인 요소라해도 과언이 아닙니다.

이는 게임에 있어서도 마찬가지입니다. 그런 이유로 모든 3D 게임에는 어떠한 형태로든 그림자가 존재합니다. 그리고 당연히 유니티에서도 그림자 기능을 제공해줍니다. 사용법 역시 체크박스만 몇 번 해주면 되는 식으로 되어있어 손쉽게 그림자를 활성화시킬 수 있습니다. (공식 메뉴얼 : http://docs.unity3d.com/Manual/class-MeshRenderer.html)

유니티에서 제공해주는 그림자는 그림자맵(ShadowMap) 기법을 사용하고있습니다. 이 기법은 모든 굴곡에 대응하고 자기 그림자(self-shadow)가 처리되는 등 높은 퀄리티를 보여주고 있지만 문제는 성능입니다. ShadowMap 기법은 그림자의 깊이를 저장하는 버퍼를 만들고난 뒤 픽셀 셰이더(Pixel Shader)에서 깊이를 비교하는 과정을 거칩니다. 또한, 넓은 영역을 커버하기위해 여러 구역으로 나누기도하고(cascade) 계단 현상을 없애기 위해 여러번 샘플링하여 필터링을 처리하는 등 부가적인 행위들이 추가됩니다. 그러다보니 랜더링 비용 중 그림자가 많은 부분을 차지하게 됩니다. PC에서는 이러한 셰도우맵 기법을 사용하기에 충분한 성능이 나오지만 모바일 장치에서 셰도우맵을 사용하는 것은 무리입니다.

이 글에서는 유니티에서 기본적으로 제공해주는 쉐도우맵 방식을 사용하지 않고 좀 더 저렴한 방식으로 그림자를 표현하는 것에 대하여 이야기하고자 합니다.

원형(circle) 평면 그림자

성능 문제때문에 모바일 장치에서는 그림자를 동그라미로 간단하게 표현하는 것이 일반적입니다. 원형의 텍스쳐를 사용하는 평면을 만들고 그걸 케릭터 밑에 배치하는 것이지요. 형태는 너무나도 간단하긴하지만 이 마저도 없는것과 있는것의 차이는 큽니다. 

이미지 : 레이븐

구현도 간단하거니와 비용도 많이 들지 않습니다만 평면이 아니고서는 표현이 불가능하다는 단점은 있습니다. 산이나 계단같이 평면이 아닌 구역에서는 그림자가 평면인게 티나기때문에 이질감이 있는 것이지요. 하지만 요즘 대부분의 모바일 게임은 평면상에서 이루어지고, 탑뷰등 카메라가 고정되어있으므로 널리 쓰이고 있습니다.

화면상에 작게만 보이거나 그림자 영역이 티가 많이 나지 않으면 이러한 간단한 동그라미 형태만으로도 충분합니다. 하지만 케릭터가 클로즈업되는 등 그림자의 화면 비중이 커지면 다소 어색해보일수도 있습니다. 이러한 경우는 케릭터 전체 크기의 동그라미가 아닌 발 크기의 동그라미 두개를 각각의 발 위치에 붙여서 이질감을 완화시킬 수도 있긴 합니다.

그래도 아직 부족해보이긴 합니다. 엄밀히 말하자면 바닥과 발 사이의 AO를 표현해준 것이지 케릭터 전체의 그림자를 표현해준 것이 아니기 때문입니다. 완벽해보이려면 케릭터의 형태 그대로를 따라서 바닥에 그림자가 맺혀야합니다. 즉, 실시간 그림자가 필요합니다.

렌더 타겟 텍스쳐(Render Target Texture)

렌더 텍스쳐를 활용하면 손쉽게 이를 해결할 수 있습니다.렌더 텍스쳐는 카메라가 바라보는 장면을 화면에 바로 그려주는 것이 아니라 텍스쳐로 그려주는 기능을 제공해줍니다. ( 공식 메뉴얼 : http://docs.unity3d.com/Manual/class-RenderTexture.html) 그러기 위해서는 오브젝트에 정상적으로 그리는 메시 오브젝트 외에도 그림자로 그릴 용도의 메시 오브젝트를 추가해서 그림자로 그려줘야합니다.

우선 메인 카메라 외에 그림자용 카메라를 생성합니다. 그림자용 레이어를 추가해서 그림자용 메시만 그리도록 설정해놓고 Target Texture를 하나 생성하여 설정해줍니다. 그림자용으로 추가한 메시 역시 레이어를 설정해놓고 검은색으로 드리도록 매터리얼을 설정해줍니다. 그러면 Target Texture에는 다음과 같이 그림자 오브젝트가 그려집니다. 

케릭터 주변의 적절한 위치에 평면을 설치한 후, 그림자용으로 만든 Target Texture를 평면에 셋팅해주면 그림자가 완성됩니다.

Target Texture의 해상도만 높으면 텍스쳐 필터링덕에 자연스레 부드러운 그림자(soft shadow)도 가능해진다는 이점이 있습니다. 하지만 현실적으로는 메모리 문제 때문에 해상도를 높게 잡을 수가 없습니다. 그러다보니 타겟 텍스쳐의 해상도문제로 그림자에 계단 현상이 발생하게 됩니다. 또한, 케릭터가 점프하는 등 에니메이션에 따라 일부 영역을 벗어나면 그림자가 잘려나가는 등 부작용이 많으므로 완벽한 해결책이 되지는 못합니다.

메시 평면 그림자

여기서 잠깐 그림자가 무엇인지에 대해 짚고 넘어가고자 합니다. 우리가 일반적으로 생각하는 그림자라는 것은 어떤 사물에 의해서 빛이 차폐되는 현상을 뜻합니다. 즉, 빛이 사물에 닿으면 그 사물 뒤의 영역에는 빛이 닿지 않는 것이지요. 

이미지 출처 : http://news.mynavi.jp/column/graphics/020/?route=blog

그 말인 즉슨, 어떤 캐릭터의 그림자를 평면에 표현하기위해서는 케릭터의 형태를 빛의 방향으로 평면에 투영시켜서 그리면 된다는 것입니다. 이 경우 메시의 원형으로 그대로 그리는 것이 아니라 빝의 방향으로 평면에 투영시켜주는 버텍스 변형이 필요합니다. 따라서, 이 메시는 유니티에서 기본적으로 제공해주는 셰이더 말고 커스텀한 셰이더를 사용하여야 합니다. 이 그림자를 표현해주기 위한 셰이더를 만들기 위해서는 약간의 수학을 끼얹어야 합니만 복잡한 수학은 아니므로 큰 걱정은 안하셔도 됩니다. 

일단, 다음과 같이 어느 한 점 P가 있고 광원 방향이 L이라고 하였을 때, 평면에 점P가 투영되는 위치는 점P'입니다. 점P와점P'을 이으는 선을 H라 하고 점P를 평면과 수직으로 이으는 선을 O라고 합니다. 선분 H와 O의 각을 θ라고 하였을 때 cosθ는 L과 단위화된(normalized)O의 내적입니다(L은 이미 단위화 되어있음). 이미 O는 평면과 수직인 상태이므로 최종적으로 cosθ와 L.y는 동일합니다. 그러면 아래 그림과 같이 빗변을 L, 맞변을 L.y로 삼는 빨간 삼각형을 이룰 수 있습니다. 

그러면 삼각비에 의해서 L:Ly = H:O가 되고 L은 단위화되어 길이가 1이므로 H = O/L.y 입니다. 즉, P'= P + O/L.y입니다. 이를 셰이더 코드로 표현하면 다음과 같습니다.

float4 vPosWorld = mul( _Object2World, v.vertex);

float4 lightDirection = -normalize(_WorldSpaceLightPos0); 

float opposite = vPosWorld.y - _PlaneHeight;

float cosTheta = -lightDirection.y; // = lightDirection dot (0,-1,0)

float hypotenuse = opposite / cosTheta;

float3 vPos = vPosWorld.xyz + ( lightDirection * hypotenuse );

o.pos = mul (UNITY_MATRIX_VP, float4(vPos.x, _PlaneHeight, vPos.z ,1));  

이 셰이더를 적용하여 검은색으로 그리면 오브젝트의 실루엣을 따르는 그림자가 평면에 나타나게됩니다. 확실히 단순한 동그라미로만 그리는 것 보다는 자연스러운 그림자에 가깝게 보입니다. 

모델 : https://www.assetstore.unity3d.com/kr/#!/content/22840

보완

그러나 현 상태만으로는 한가지 문제가 있습니다. 그림자를 좀 더 자연스럽게 보이게 하기 위해 알파블렌딩(alpha blending)을 적용하면 다음과 같이 그림자 내부에 아티팩트가 생깁니다. 평면에 오브젝트를 블렌딩하여 그릴 때 같은 위치에 여러 면이 겹쳐져서 그려지기 때문입니다. 아래 그림에서는 몸통이나 머리 위에 팔이 덧그려지면서 실루엣 내 그림자 농도가 달라지는 현상이 생겨버립니다.

이러한 형상을 없애려면 이미 그림자가 그려진 픽셀에는 덧 그려지지 않게 하는 작업이 필요합니다. 이를 위해서는 스텐실(stencil) 버퍼를 활용하면 됩니다. 스텐실 버퍼는 일종의 마스킹(masking)의 개념입니다. 이미 그려진 픽셀은 또 그려지지 않도록 마스킹처리하는 것입니다. ( 공식 메뉴얼 : http://docs.unity3d.com/Manual/SL-Stencil.html) 그림자를 그리는 셰이더의 pass에 다음과 같이 스텐실을 사용하도록 선언해주면 중복된 픽셀에 그리지 않게 됩니다.스텐실을 적용하고나면 다음과 같이 블렌딩을 적용해도 아티팩트 없이 동일한 농도의 그림자를 그릴 수 있게됩니다.

Stencil {

Ref 0

Comp Equal

Pass IncrWrap

ZFail Keep

}

주의사항

이토록 평면이라는 전제만 존재한다면 그림자를 비교적 좋은 성능을 보장하면서도 손쉽게 표현 할 수 있는 방법들이 많습니다. 다만, 메시 그림자같은 경우는 메시를 한번 더 그리게 되므로 폴리곤이 적은 그림자용 메시를 별도로 마련하는 것이 좋을 것입니다. LOD를 사용한다면 LOD용 모델을 사용하면 되므로 추가적인 작업의 부담은 생기지 않을 것입니다. 또 다른 주의점으로는, 자기 그림자(self shadow)가 처리되지 않는다는 단점은 존재합니다만 어짜피 라이팅이 간단한 모바일에서는 대부분 자기 그림자를 원치 않을 것입니다. 

여러분들도 아시다시피 유니티는 멀티플랫폼 엔진입니다. 그러다보니 당연히 빌드 결과물 외 에디터에서도 OpenGL과 DirectX 둘 다 지원을 합니다. 하지만 유니티를 실행하면 기본적으로는 실행 OS에 맞게 기본적으로 그래픽 API를 설정해줍니다. 즉, MAC이나 Linux로 수행하면 OpenGL모드로, MS Windows에서 수행하면 DirextX모드로 실행됩니다. 

OpenGL 모드 강제 지정

사실, 미미한 차이긴 하지만 OpenGL과 DirectX의 렌더링 결과가 다르긴 합니다. (프로그래머는 몰라요. 아티스트의 매의 눈으로 봐야 알아요;;) 따라서 개발하다보면 에디터에서도 OpenGL모드로 보면서 작업하고 싶을때가 있습니다. Windows에서도 OpenGL 모드로 보여줄 수 있습니다만 유니티 메뉴의 설정 창 어디에서 이를 변환해주는 항목은 존재하지 않습니다. 유니티 수행 시 커맨드라인 실행 인자로 "-force-opengl"을 주면 OpenGL 모드로 수행됩니다. 매번 cmd로 커맨드라인 열어서 수행하실 필요는 없고 바로가기에 인자로 추가해주시면 됩니다. Unity바로가기 아이콘 우클릭하신후, 대상(T) 항목의 맨 뒤에 "-force-opengl"을 붙여주시면 됩니다. 

그러고나서 유니티를 실행하면 상단 타이틀에 OpenGL모드로 수행되는중이라는 표시가 뜹니다.

마찬가지로 DirectX 9이나 DirectX11 모드로 강제 지정이 가능합니다. (자세한 내용은 공식 메뉴얼을 참고해주세요.) 

DX11 on DX9 GPU

그런데 가끔 DirectX 모드로 수행 시 화면의 색이 원래와는 다르게 나오는 경우가 존재합니다. 특히 노말맵을 쓰는 모델이 티가 많이 나는데, 확인해보면 노말맵이 전제적으로 붉은 느낌으로 변해버린 것을 발견하실 수 있습니다.

이러한 경우는 DirectX의 버젼이 맞지 않아서 발생하는 문제입니다, PC는 DirectX 9까지만 지원하는 GPU를 장착하고 있는데, 유니티는 DirectX 11 버젼으로 수행하기때문에 문제가 발생하는 것입니다. 때문에 타이틀바 상단에 DX11 on DX9 GPU라고 표시가 뜹니다.

이는 프로젝트 셋팅에서 DX11을 사용하지 않도록 설정해주면 해결이 됩니다. File > Build Settings > PC, Mac & Linux Standardalone > Player Settings > Other Settings > Use Direct3D 11 체크를 해제해주시면 됩니다.

라이팅 작업 흐름을 비약적으로 개선시켜줄 수 있는 실시간 글로벌 일루미네이션(real-time Global illumination)은 Unity5의 새로운 그래픽 기능 중 하나입니다. 이에 초첨을 맞추어 이야기하고자합니다. 이 글은 유니티 블로그에 있는 "GLOBAL ILLUMINATION IN UNITY 5"글을 번역 및 요약한 글입니다.

글로벌 일루미네이션( Global illumination, 이하 GI)은 물리적인 현상에 기반한 빛의 이동에대한 시물레이션 결과입니다. 즉 3D 공간에서 빛이 면에 부딪혀서 어떻게 이동하는 지를 시물레이션 하는 것입니다. 이로 인해 게임의 사실성을 부각시켜 줄 수 있습니다. GI 알고리즘은 광원으로부터 직접 오는 빛 뿐만 아니라 다른 재질의 면에 반사되서 오는 간접 조명도 취합해서 계산합니다. 하지만 일반적으로는 간접 조명은 게임에서 실시간으로 연산하기에는 무리였습니다.

GI를 식으로 표현하면 다음과 같습니다. 특정 점의 라이팅은 표면 점의 원래 라이팅인 Le과 부수적인 라이팅의 합으로 이루어집니다. Li는 반구 조명을, p는 반사된 조명을 나타냅니다.

이를 처리하기 위하여 쓰이는 대표적인 알고리즘중 하나는 path tracing입니다. 이는 CGI나 영화에서 널리 쓰이고 있습니다. 하지만 화면에 있는 라이팅, 매터리얼 등의 회면 전체의 이미지를 구성하는데 필요한 모든 정보가 매번 연산되어야합니다. 그러다보니 게임같은 실시간 렝더링에서 사용하기에는 적합하지 않습니다. 이에 대한 대안으로, 이미지 전체를 갱신하지 않고 노이즈로 처리해서 성능을 높이는 방법도 존재합니다. 하지만 노이즈가 티나도록 깜빡거림이 생기는 등의 부작용이 존재합니다.

이 외에도 GI를 처리하기 위한 많은 방법들이 연구되어왔지만, 대부분은 하이엔드 데스크탑 수준의 GPU와 많은 용량의 메모리가 필요합니다. 따라서 모바일을 비롯하여 다양한 플랫폼에서 사용될 수 있는 방안이 필요합니다.

Enlighten

Enlighten(이하 인라이튼)은 이미 배틀필드4, 메달 오브 아너 워파이터 등 여러 AAA급 게임에서 사용되어 검증이된 뿐만 아니라 모바일에서까지 GI를 가능케해주는 훌륭한 솔루션입니다. 기본적인 시각적 정보들(예를 들어 위의 식에서 우항의 적분 부분)이 미리 연산되어 있으면 실시간 으로 라이팅 소스를 변경 처리하는 것이 가능해집니다.

인라이튼은 다음 사항들을 동적으로 변경하는 것을 가능케 합니다.

• 라이트 소스
• 환경 라이팅
• 머티리얼 속성

GI가 사뮬레이션되는 지오메트리는 정적이어야합니다. 하지만 동적 오브젝트는 라이트프로브에 의해서 동적으로 라이팅이 변경 될 수 있습니다. 이 라이트프로브는 실시간으로 정적인 오브젝트의 GI를 업데이트 할 수 있습니다. 이를 위해 인라이튼은 실시간으로 GI를 시뮬레이션 하기 위한 데이터를 미리 연산해놓습니다. 이 데이터는 OSX, Windows, Linus, iOS, 안드로이드, iOS 등등의 다양한 플랫폼의 런타임 모듈에서 사용됩니다.

인라이튼은 다음 사항들을 만들어냅니다.

• 실시간 라이트맵
• 실시간 라이트프로브
• 실시간 큐브맵

다음 예시 이미지들은 Enlighten을 이용하여 그려진 화면입니다. 라이팅들은 완벽한 동적 라이팅으로 셋팅되어있고 변화가 즉각적으로 이루어집니다. 

이 이미지는 밝은 낮을 나타냅니다. 태양이 더 강하고 높이 위치합니다.하늘은 더 푸르고 밝습니다.

흐린 날씨의 경우에는 환경 라이팅이 우중충하고 채도가 낮습니다. 태양의 세기는 약해졌습니다. 앰비언트 라이팅 위주입니다.

마지막으로 해질녘 노을빛의 느낌을 내는 모습입니다. 

이 테크닉을 사용함으로써 하루 동안의 시간 흐름을 표현할 수 있습니다. 이로 인해 게임이 매우 사실적이게 보여 줄 수 있습니다.

인라이튼 사전 연산 (precompute)

정적인 지오메트리는 GI 솔루션 시스템에서 효과적으로 관리됩니다. 사전 연산(precompute) 단계에서 인라이튼은 씬을 여러 시스템 태스크로 쪼갠 후 이를 방대한 병렬 파이프라인에서 나누어 연산합니다. 사전 연산 과정을 거친 후 시스템 태스크간의 지오메트리 연결 정보가 구성됩니다. 이 정보들은 실시간으로 간접광을 제어하는데 사용 될 수 있습니다. 이어한 덕에 벽의 파괴나 문이 열리는 상황 등 라이팅이 변화되는 상황이 반영 될 수 있습니다.

인라이튼 런타임 

인라이튼은 데스크탑PC나 차세대콘솔 뿐만 아니라 하이엔드 모바일 장치에서도 작동합니다. 이는 CPU 스레드에서 비동기적 연산으로 돕니다만, 모바일에선 동적 라이팅과 그림자의 GPU 연산이 이슈다보니 모바일에서는 처리 가능한 동적 라이팅의 갯수가 제한됩니다. 하지만 발광색(emissive) 변경은 자유롭습니다. 발광색의 정보는 비록 저해상도이긴 하나 인라이튼에 인코딩된 정보로 연산을 하기 때문입니다.

모바일 장치(ARM 태블릿)에서 작동하는 영상:

베이킹(Baking)

어떤 게임들은 라이팅을 미리 굽는(baking) 과정이 매우 적절한 선택이 될 수 있을 것입니다. 유니티5에서는 라이트소스, 발광 재질, 환경 라이팅 등이 baked 및 리얼타임으로 태그 될 수 있습니다. baked는 이전버젼(4.x)와 같은 방식으로 베이킹 되는 것 의미합니다. 동적 라이트는 인라이튼 런타임에서 처리합니다. baked와 real-time은 이질감 없이 합성됩니다.

유니티5의 라이트맵은 여러 컴포넌트로 나뉩니다. 직접광, 간접광, 직접광 지향성, 간접광 지향성, AO 등 5개의 라이트맵으로 나뉘어집니다. 이 라이트맵 컴포넌트들은 실시간으로 합성하게 됩니다. 또한, 이는 에디터에서 컨트롤 가능합니다. 예를 들어 간접광만 증가시키는 것이 불과 몇 초 안에 이루어질 수 있습니다.

라이팅 워크플로우(workflow)

인라이튼은 실행중인 게임안에서만 실시간 GI를 제공하는 것은 아닙니다. 에디터에서 작업하는 과정에서도 실시간 GI가 이루어집니다. 인라이튼의 주요 장점 중 하나는 아티스트에게 엄청나게 개선된 워크플로우를 제공해준다는 것입니다. 이는 라이팅 작업이빠른 이터레이션으로 이루어 질 수 있기 때문입니다. iterative모드가 추가됨으로써 명시적으로 굽는 과정 필요가 없어졌습니다. 씬의 사전 연산 정보들이 실시간으로 구워지고, 사용자가 이 과정중에 일일이 개입할 필요가 없습니다. 에디터는 지속적으로 씬의 변경 사항 확인하여 자동적으로 라이팅 정보를 반영해주는 작업을 수행합니다. 대부분의 작업은 즉각적으로 반영됩니다.

라이팅 워크 플로우 영상 :

이 글에서는 Unity에서 LOD(Level of Detail)을 사용하는 것에 대한 이야기를 해볼까 합니다 Object LOD에 촛점을 맞추고 있으며 Shader LOD와는 별개의 이야기입니다.

LOD란 무엇인가?

여러분이 게임 광고를 기획한다고 가정해보죠. 아리따운 누나가 대규모의 적들과 전투하는 켄셉을 잡고 모델을 섭외합니다. 역시 게임 광고 모델은 뭐니뭐니해도 아이유지요. 하지만 문제는 예산이네요. 예산을 최대한 절약 할 방법이 없을까 고민해봅시다.

이건 어떨까요? 기본적으로 모델을 아이유를 캐스팅하지만 하지만 굳이 클로즈업을 해도 되지 않는 장면이라면요? 아이유와 똑같이 생겼지만 아이유보다는 몸값이 저렴한 신봉선으로 대체해도 되지 않을까요? 클로즈업이 필요한 씬에서는 아이유를, 그렇지 않은 씬에서는 신봉선을 이용한다면 광고료를 아낄 수 있지 않을까요? (물론 실제로는 말도 안되는 소리입니다 ㅋ ) 이러한 전략이 바로 Level of Detail의 컨셉입니다. 

이미지 : TIG, 마영전

게임같은 Real-time Rendering에서는 최대한 렌더링 비용을 절약하는 것이 중요합니다. 화면에 작게 그려지는 모델을 그리는데 비싼 비용을 지불 할 필요가 없는 것이지요. 때문에, 카메라와 가까이 있거나 큰 오브젝트는 높을 퀄리티로 그리고, 멀리 떨어져 있거나 작은 오브젝트는 낮은 퀄리티로 표현하거나 연산처리하여 퍼포먼스를 향상시킬 수 있습니다. 이러한 기법을 Level of Detail(이하 LOD)이라 부릅니다. 말 그대로 디테일의 단계를 두어서 상황에 맞게 표현하는 것이지요.이러한 컨셉은 Material LOD, Terrain LOD, Mesh LOD, Bone LOD 등 여러 방면에서 쓰입니다. 이 중 Mesh 를 LOD 시키는 것에 대한 이야기를 할까 합니다.

https://www.assetstore.unity3d.com/kr/#!/content/8855

Unity에서의 LOD

LOD는 3D 게임 개발에 있어서 꼭 필요한 기능이고 당연히 Unity에서도 제공을 합니다. 다만 Pro Version에서만 제공이 되고 있어서 Free Version에서는 사용이 불가능합니다.(2015년 1월 기준) 사용법도 간단합니다. 오브젝트에 LOD Group 컴포넌트를 추가하고 LOD 0에는 가까이서 보일 오브젝트를 설정해주고, LOD 1에는 멀리서 보일 오브젝트를 설정해주면서 조절해주면 됩니다. 카메라 아이콘을 슬라이드해가면서 바로바로 확인하면서 편집이 가능합니다. 

자세한 설명은 공식 메뉴얼을 참고해주세요. (공식 메뉴얼 :  http://docs.unity3d.com/Manual/LevelOfDetail.html)

LOD 툴

유니티로 게임을 개발 할 때 에셋스토어를 활용하면 게임 모델을 손쉽게 구할 수 있습니다. 판타지, 레이싱, SF등 다양한 장르의 배경 및 케릭터 오브젝트들이 있어서 다운로드만 받으면 즉시 사용이 가능합니다. 유료는 물론 무료 모델들도 많이 있어서 저도 에셋스토어에서 다운로드받아 게임 제작을 하고 있습니다. 하지만 몇 가지 문제점들이 존재합니다.

첫째, 모든 리소스들이 LOD 시스템을 대응하고 있지는 않다는 것입니다. 이러한 경우는 Low quality 모델을 따로 생성해줘야 하지요. 아티스트팀이 따로 존재한다면 아티스트가 직접 Low quality 모델을 제작해줄 수도 있겠지요. 하지만 아티스트가 아예 없거나 일손이 모자란다면 자동으로 모델을 만들어주는 툴이 필요할겁니다. 

둘째, PC 및 콘솔 대응 리소스들도 많이 있습니다. 모델 하나가 만 단위가 넘는 폴리곤을 가지고 있는 경우도 허다합니다. 타겟이 PC 및 콘솔이라면 케릭터에 그정도를 투자할 수도 있을 것입니다. 하지만 모바일 타겟이라면 거의 불가능에 가까운 무거운 모델들일 것입니다. 이러한 모델들을 모바일에서 사용 할 수 있을 정도로 폴리곤을 줄여주는 툴이 필요할겁니다.

셋째, 파츠가 많이 나뉘어져 있는 모델도 존재합니다. 건물 하나가 문, 지붕 벽 등 몇 파츠로 나뉘어져 있거나, 애초아 드럼통 벽돌 등 다른 오브젝트등을 조합해서 하나의 배경 프랍으로 사용해야 하는 경우도 존재할 것입니다. 이러한 경우 메시 및 매터리얼의 갯수 등 상황에 따라 드로우콜이 늘어나게 됩니다. 드로우콜이 많아지면 성능이 느려지기 때문에 이 오브젝트들을 하나의 메시와 매터리얼로 만들어줘는 툴이 필요할겁니다. (드로우콜이 성능에 왜 영향을 미치는 지는 나중에 따로 설명하는 시간을 갖도록 하겠습니다.) 

이러한 이유들로 많은 LOD 관련 툴들이 존재합니다. 당연히 에셋스토어에도 LOD 툴들이 많이 있습니다.

Simplygon

그 중 Simplygon(심폴리곤이 아니라 심플리곤입니다 ㅋ)을 소개할까 합니다. Simplygon은 무료입니다. 몇 가지 제약이 있긴 합니다만 기본적으로는 무료입니다. 일단 에셋스토어에서 다운로드후 Import하시면 Unity 메뉴 Window에 Simplygon 항목이 생깁니다.(https://www.assetstore.unity3d.com/kr/#!/content/10144)

이제 실제로 사용하는 예를 보여드릴까 합니다. 우선 에셋스토어에서 모델을 하나 받습니다. 

https://www.assetstore.unity3d.com/kr/#!/content/10739

언니가 무섭고 이쁘긴 한데 폴리곤이 너무 많습니다. 세상에나 2만7천 폴리곤이라니 모바일에서는 전혀 써먹지를 못하겠네요.

이제 이 모델을 Simplygon으로 폴리곤을 반토막 내볼까 합니다. 모델을 선택 후 Simplygon 창을 클릭하면 다음과 같이 네개의 하위 탭이 존재합니다. (가입이 안되어있으시면 계정 등록을 하시면 됩니다. 일단 무료 계정으로 가입하셔도 충분합니다.) 반토막낼거니 Quick Start탭의 Reduction 항목에 50으로 입력사고 아래의 노란색 마크 버튼을 클릭합니다.

그러면 모델 데이터를 Simplygon서버에 보내고 받아오는 과정이 이루어지면서 Manage Jobs 탭의 톱니바퀴 아이콘이 움직입니다. Manage Jobs 탭을 열어 Download Assets Automatically를 체크해줍니다.

 그리고나서 status 상태가 100%이 되면 처리된 에셋을 자동으로 import하고 LODs 폴더에 처리된 모델이 생깁니다. 

확인해볼까요? 일단 육안으로는 큰 차이를 모르겠네요.

하지만 폴리곤 수를 보면 2만7천 폴리곤이였던 모델이 1만3천 폴리곤으로 확 줄었습니다. RPG처럼 케릭터가 많이 나오는 게임에서는 사용이 불가능하겠지만 대전격투게임처럼 케릭터가 적게 나오는 게임에서는 쓸만하겠네요.

한번 더 줄여볼까요? 이번엔 원본에서 3%로 설정해서 돌려본 결과입니다. 원본과 비교해보면 얼굴이 많이 못생겨지긴 했지만 전체적인 실루엣은 어느정도 유지해주고 있습니다.

하지만 폴리곤은 540여개로 대폭 줄었습니다.

멀리 두고 비교해보면 두 모델 간의 차이는 눈에 띄지 않을 정도입니다.

이번엔 다른 모델도 한번 살펴볼까요? 이 두 골렘은 작게 해서 보면 차이는 없어보입니다.

https://www.assetstore.unity3d.com/kr/#!/content/13631

하지만 폴리곤은 3배 이상 차이가 납니다.

이런 식으로 SImplygon같은 툴을 이용하면 LOD에 필요한 데이터를 쉽게 생성 할 수 있습니다. 더 나아가서는 PC 및 콘솔을 타겟으로 만들어진 데이터를 모바일에서 사용 할 수 있도록 폴리곤을 줄이는 용도로도 사용이 가능합니다. 물론 툴로 줄이는 것 보다는 아티스트가 이태리 장인정신으로 한땀 한땀 줄여주는 것이 가장 퀄리티는 좋습니다. 하지만 그렇지 못하는 상황이라면 툴의 도움이 정말 요긴하게 쓰일 것입니다. 

SImplygon의 추가적인 사용법은 공식 튜토리얼을 참고해주세요. (https://www.youtube.com/watch?v=qEyPVNGxGb8)

케릭터 LOD

이제 메시는 생성했으니 실제 LOD가 작동하는 케릭터를 만들어보도록 하죠. non-skinned mesh를 이용하는 오브젝트(예를 들면 건물이나 배경 프랍들)의 LOD 처리는 어려울게 없습니다. 하지만, 에니메이션 처리 되는 skinned mesh 케릭터에게 LOD 처리하는 것은 조금 귀챦습니다. 일단 Simplygon으로 생성하기 이전의 원본 mesh와 Simplygon 처리 후의 LOD 메시간의 본 에니메이션 정보는 공유되지 않습니다.

우선, Simplygon으로 생성 한 케릭터 중 Level 0 즉 가까이 있을 때 그릴 용도로 사용 할 케릭터를 씬에 올려놓습니다. 그러면 케릭터 오브젝트 바로 하위에는 본 계층구조 오브젝트와 skinned mesh 오브젝트가 있습니다. 이 메시 오브젝트를 Duplicate하여 사본을 만듭니다. 다른 오브젝트나 prefab에 있는 메시를 가져오면 안됩니다.

 그 후, 새로 만들어진 사본의 Skinned Mesh Renderer의 Mesh를 Level 1 즉 멀리 있을 때 그릴 용도로 사용 할 메시로 바꿔치기해줍니다.

이제 케릭터 오브젝트에 LOD Group 컴포넌트를 추가해주고 LOD 0, LOD 1 각각 메시를 설정해줍니다.

이제 케릭터가 하나의 에니메이터로 에니메이션하면서 거리에 따라 LOD 메시가 바뀌는 것을 확인 가능합니다.

마치며

게임 개발 시 얼마나 최적화를 시키느냐가 중요한 과제중 하나입니다. LOD 처리를 하는 것은 쉬우면서도 효과적인 최적화 방법중 하나입니다. 유니티는 이 기능을 쉽게 사용 가능하도록 제공해주고 있고 에셋스토어에는 보조장치들이 많이 존재합니다.SImplygon은 그 중 하나일 뿐이지 반드시 이것을 사용해야한다는 것은 아닙니다. 다만 LOD를 처리하는 예를 보여주기 위한 수단으로 소개해드린 것일 뿐입니다. 물론, 카메라가 고정되어있는 탑뷰(및 쿼터뷰)에서는 LOD 처리가 필요 없을 수도 있습니다. 하지만 요즘은 모바일 게임들도 탑뷰에서 탈피하는 게임도 많이 있어서 LOD의 필요성이 많아지게 될 것입니다. 

감사합니다.

* 아직 테스트 단계라 원활한 접속이 되지 않을 수 있습니다.

만일 여러분이 게임을 출시했는데 난이도가 넘 어렵다는 평이 많다고 가정해봅시다. 그래서 주인공의 공격력과 방어력을 조절해야 합니다. 근데 로직은 변한 것 하나 없고 단순히 수치만 변경했는데도 빌드를 새로하고 다시 업로드를 해야하네요. 안드로이드는 업로드하면 그나마 몇시간 후면 반영되는데 아이폰은 일주일을 꼬박 기다려야하네요. 뭐 별수 있나요 눈물을 머금고 기다려서 난이도 패치를 끝냈습니다. 그 기념으로 일시적으로 아이템 드랍률을 올려주는 이벤트를 하려고 합니다. 이번에도 로직은 바뀌는 것 없이 단순 데이터 수치만 바뀌는건데도 빌드를 다시 해야하네요. 안드로이드와 아이폰간의 빌드 반영 딜레이 뿐만 아니라 업데이트 받은 유저와 아닌 유저의 차이도 골치아프겠네요.

물론 클라이언트-서버 구조로 되어 있는 게임은 이런 고민이 필요 없습니다. 애초에 중요 로직과 데이터들이 다 서버에 있으니까요. 하지만 보통 로직 서버를 따로 두지 않는 캐쥬얼 인디 게임들이라면 이런 고민이 절실합니다. 

Unity Cloud Data(https://data.cloud.unity3d.com)

이번 글에서는 그러한 고민을 해결해 줄 수 있는 Unity Cloud Data 서비스를 소개하려고 합니다. Unity Cloud Data (이하 UCD)는 서버-클라이언트 구조가 아닌 게임도 중요 데이터들을 서버에 둘 수 있도록 해주는 서비스입니다. 데이터만 서버에서 제어하면 클라이언트에서는 그 값을 가져다 사용하기때문에 따로 추가적인 패치가 필요가 없습니다. 그렇게되면 앞서 언급한 공격력 방어력 아이템 드랍률 등의 단순 수치들을 수정해주는 문제가 아주 간결해지는 것이지요. 데이터 연동 서버도 유니티에서 제공해주고 있으므로 따로 따로 서버를 마련할 필요도 없습니다. 

실습 ㄱㄱ !

그럼 간단히 같이 실습해보면서 확인해볼까요? 유니티 튜토리얼중에 Space Shooter라는 샘플 게임이 있습니다. 우선 이 샘플을 다운로드받아주세요. (https://www.assetstore.unity3d.com/kr/#!/content/13866)

튜토리얼 영상도 있어요 : http://unity3d.com/learn/tutorials/projects/space-shooter

게임 자체는 매우 간단해요. 운석과 적 비행기가 계속 나오고 플레이어 비행기를 움직이면서 총알을 발사하는 간단한 룰입니다. WASD로 이동하고 마우스 버튼으로 발사합니다. Space Shooter 에셋을 import한 후 Assets/Done/Done_Scenes에 있는 Done_Main Scene을 열어주세요. Game Controller 오브젝트에 있는 Done_Game Controller script에서 적들이 등장하는 갯수와 주기 등등을 제어하고 있습니다. 이 값들을 서버에 연동하여 변경하는 작업을 확인해볼까 합니다.

UCD 페이지 설정

우선은 UCD 게임 프로젝트 별로 서버를 설정해줘야 합니다. UCD(https://data.cloud.unity3d.com)에 가서 로그인 후 다음과 같은 절차를 따라주세요.

1. 우선, Create New Project 버튼을 클릭해서 새 프로젝트를 생성합니다. 이 프로젝트는 게임 별로 따로 존재하여야합니다. 일단은 Test01이라고 이름 지었습니다. 
2. 프로젝트를 생성하고나면 데이터 시트를 생성해줘야 합니다. 방금 만든 Test01 프로젝트로 들어가서 페이지 상단에 있는 Create New Mesater Sheet라고 적혀있는 녹색 버튼을 눌러서 시트를 생성해줍니다. 저는 gamectrl이라고 이름을 지었습니다.
3. 그 후, Access Token을 발급해줘야합니다. Test01 프로젝트로 페이지 하단에 있는 Create New Editor Token이라고 적혀있는 녹색 버튼을  클릭해서 새 토큰을 생성해줍니다.

유니티 에디터 작업

이제 Hierarchy에서 Create > Create Empty를 수행해서 빈 오브젝트를 만듭니다. 저는 이 오브젝트 이름을 UCD로 지었습니다. 이 오브젝트에 Add Component를 수행해서 Unity Cloud Data > Cloud Data Manager 컴포넌트를 추가해줍니다. 앞서 생성했던 Organization ID, Project ID, Access Token등을 기입해주시면 됩니다. Access Token 바로 아래 있는 Create New Sheet 버튼을 수행하여 Cloud Data Sheet 컴포넌트를 생성하고 Path에는 앞서 생성한 시트의 이름을 적어줍니다. 그 후 Refresh from Unity Cloud Data를 수행하여 이상이 없는 지 확인합니다.

이제 본격적으로 수치를 연동해봅니다. Hierarchy에서 Game Controller 오브젝트를 선택합니다. Done_GameController의 Hazard Count, Spawn Wait, Wave Wait를 연동하고자 합니다. 스크립트를 열고 아래 표시한 부분을 수정 및 추가해줍니다. 코드 변경은 이게 끝입니다. MonoBehaviour대신 UCD 기능이 있는 CloudDataMonoBehaviour를 상속받도록 수정하고, 서버와 연동하고싶은 변수에 CloudDataField 태그를 붙여줍니다. sheetPath는 앞서 생성한 gamectrl로 설정해줍니다만 생략할 수도 있습니다.

그 후 Game Controller의 Inspector를 확인해보면 변수들이 Cloud Data Fields로 바뀌어 있습니다. 그 아래 있는 Save to Cloud Data Sheet를 클릭하면 Saving new fields 라는 메시지로 바뀌며 UCD 서버로 데이터가 연동됩니다. 

다시 UCD의 test01>gamectrl 페이지를 새로고침하면 데이터가 연동되어있는 것이 보입니다.

이제 모든 것이 완료되었습니다. 유니티로 돌아가서 게임을 수행시킵니다. 그 후 gamectrl페이지의 수치를 변경(hazardcount:50, spawnwait:0.01, wavewait:0.5) 후 Save Changes를 눌러 값을 저장해줍니다. 다시 유니티로 돌아가서 게임오버 후 R키를 눌러서 Scene이 re-load되면 적들의 빈도 및 밀도가 변경되는 것을 확인 가능합니다. 

마치며

앞서 언급했듯이, MMORPG 등, 중요 로직은 이미 서버에서 처리되고 있는  서버-클라이언트 구조의 게임에서는 UCD가 필요는 없습니다. 하지만 따로 서버가 없는 게임에서는 매우 유용하게 쓰일 것 같습니다.다만, 아직은 Alpha 서비스 단계라서 라이브 서비스 중인 게임에서는 사용하기에는 조심스럽습니다. 하지만, 이제 개발 착수단계인 프로젝트에서는 사용 여부를 고려해보심이 어떨까 합니다.

감사합니다.