336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

들어가기에 앞서 : 이 글은 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쇼보다 그나마 높은 수준정도밖에 되지 않지요. 

장르 별 Stereo 3D 선호도


휴면 팩터

왜 그런 것일까요? 안경을 끼고 시청해야 하는 불편함도 있겠지만은 멀미나 피로감 등에 그 주된 원인이 있다 볼 수 있겠습니다. 영화는 길어봐야 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) 이라 부릅니다. 예를 들어 아래 이미지에서는 여성과 석상이 망막경합을 일으킵니다.

이미지 출처 :  http://www.ray3dzone.com/Glimmer.html  


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


키스톤 왜곡(Keystone Distortion)

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

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


윈도우 위반 (Window Violation)

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


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


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


마치며

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


Posted by ozlael
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

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


Unity를 사용하며 얻은 유용한 팁이 있다면 #unitytips 해쉬 태그로 트위터로 트윗하거나 페이스북으로 공유해주세요. 깔끔한 에디터 워크플로우 혹은 성능 최적화를 위한 규칙 등 어떠한 것도 상관 없습니다. 꼭 새로운 기능이거나 최고급 정보일 필요는 없습니다. 무엇이든 공유할 만한 팁이 있다면 공유해주세요. 그 시작을 위해 개인적으로 베스트 10 #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


Posted by ozlael
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
2D 기능 개발은 Unity에서도 매우 중요한 이슈입니다. 따라서 최근에 2D 팀을 확장하였습니다. 많은 인력들이 팀에 참여하게 됨으로써 더 직관적이고 강력하면서도 유연한 2D 기능을 개발할 수 있게 되었습니다. 2D 팀에서는 알파 버전을 공개함으로써 여러분의 피드백을 반영하며 개발하는 프로세스를 갖기로 하였습니다. Unity Pro 사용자는 이러한 기능들을 먼저 만나보실 수 있습니다. 여러분의 피드백으로 인해 개발 기간을 단축 시킬 수 있고 정말로 여러분이 원하는 것에 더욱 집중할 수 있을 것이라 기대하고 있습니다.



Bitbucket에서는 최신 버전 릴리즈와 함께 기술 데모, 프로토타이핑 툴, 문서 초안 등을 미리 만나보실 수 있습니다. 

2D팀은 기능을 매우 멋지게 만드는 데 힘을 쏟기위해 QA와 UX에 대한 인력이 별도로 존재합니다. 여러분의 제안이나 이슈 제보 및 피드백을 리파지터리의 Issues Section에 올려주시고 2D 기능 향상에 도움을 주십시요.

현재 알파 버젼에서 미리 확인해볼 수 있는 기능들은 다음과 같습니다.
-타일 맵 에디터
-9분할 스프라이트
-스마트 스프라이트
-ETC1 압축
-마스킹
-스프라이트 패킹 개선
-기타 등등 

감사합니다!

(본 포스팅은 Unity 공식 블로그의 EARLY ACCESS TO NEW 2D TOOLS를 번역 및 요약한 글입니다.)


Posted by ozlael
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
Draw call을 줄이는 것은 최적화 시 가장 중요한 요소중 하나입니다. Unity의 새로운 UI는 이러한 Draw call을 줄이는 것이 매우 용이하게 되어있습니다. 이 글에서는 new GUI의 Draw call에 대해 다루고자합니다.

new UI는 Button, Image 등 UI 컴포넌트를 추가 시 자동으로 Canvas하위로 배치되게 되어있습니다. 
유니티 UI의 Draw call은 이 Canvas 단위로 이루어집니다. Canvas 하위의 UI 컴포넌트들에 쓰이는 이미지가 SPrite packing되어 있다면 모두 하나의 Draw call로 처리가 가능합니다. 그러므로 유니티의 UI시스템을 이용하면 Draw call을 절약할 수 있어서 성능 향상에 매우 도움이 됩니다. 하지만 유니티의 UI를 이용한다고 해서 무조건 Draw call이 하나만 발생하는 것은 아닙니다. 성능 향상을 위해서 숙지하고 있어야 할 사항을 몇 가지 이야기하고자 합니다.


Draw call

그래픽 최적화를 위해서는 Draw call을 줄이는 것이 중요합니다. 이는 UI 역시 마찬가지입니다. 유니티의 UI에서는 Canvas마다 각자의 Vertex buffer를 가지고 있기때문에 Canvas가 두개면 최소 두번의 Draw call이 일어납니다. 이는 Canvas하위에 Canvas가 존재하는 경우에도 마찬가지입니다. 만일 Canvas안에 Canvas를 추가하는 경우에도, 씬 바로 하위의 Canvas는 하나 뿐이지만, 최소 두 개의 Draw call이 발생합니다.
위에도 언급했지만 하나의 Draw call이 되기 위해서는 사용되는 이미지들이 atlas 처리가 되어있어야합니다. 즉, Sprite packing되어있는 sprite들을 사용해야합니다. 다만, atlas 페이지가 두 개 이상으로 나뉘어져있으면 경우에 따라서 두 개 이상의 Draw call이 일어날 수도 있습니다. 따라서 Packing Tag를 잘 나누는 것이 중요합니다.

다만, Canvas 별로 Draw call이 일어난다고해서 무조건 모든 UI요소들을 하나의 Canvas에 몰아넣는 것이 꼭 좋은 솔루션인것만은 아닙니다. 동적으로 반응하는 버튼이나 Fill Image등을 처리하기위해서는 매 번 갱신 비용이 발생하기 때문입니다. Runtime시에 변경되지 않는 이미지와 실시간으로 변경되는 이미지가 같은 Canvas에 존재하면 변경되는 이미지 하나를 처리하기 위해서 Canvas의 Vertex buffer를 갱신하기때문에 쓸데없는 갱신 비용이 발생합니다. 따라서, Draw call을 하나 희생하더라도 정적인 이미지들은 별도의 canvas로 빼두는 것이 효율적일 수도 있습니다. 


Text

Text는 별도의 Texture를 사용하기때문에 별도의 Draw call로 발생합니다. 이 텍스쳐는 font별로 만들어지므로 font의 종류를 줄이는 것이 Draw call을 줄이는 방법이기도 합니다.

따라서 아래의 씬에서는 UI가 차지하는 Draw call이 3입니다. 아이콘 이미지들은 패킹되어있는 상태라서 모두 합쳐서 1개의 Draw call을 차지합니다. 텍스트는 3개가 존재하지만 사용된 폰트는 2개라서 2개의 Draw call을 차지합니다. 따라서 총 3개의 Draw call이 발생합니다.


Posted by ozlael
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
많은 분들이 유니티4의 프로젝트를 유니티5로 마이그레이션 하는 것에 대하여 걱정을 하고계십니다. 하지만 업그레이드 과정은 복잡할 게 없습니다. 물론 설정을 좀 건드려줘야 하는 부분들도 생기고 귀챦은 일들도 생기긴 하지만 그리 큰 노력이 들지는 않습니다. 또한, PBS 및 실시간 GI때문에 무조건 느려지는 것이 아닌가 걱정도 하시는 분들도 계십니다. 하지만 PBS가 아닌 기존 레거시 셰이더도 이용 가능하며 실시간 GI도 사용 여부를 선택 가능하므로 성능 하락에 대한 걱정은 안하셔도 됩니다. 
어서와 유니티5는 처음이지?

그래서 제가 개인적으로 유니티 4.6으로 만들고 있던 프로젝트를 유니티5로 업그레이드하고 그 과정을 기술하고자합니다. 물론 매우 작은 프로젝트라서 큰 도움이 되실런지는 모르겠습니다. 다만 참고 자료정도로 생각해주시면 감사하겠습니다. 유니티5로 빌드한 프로젝트를 구글 플레이에 올려두었습니다. 아직 테스트 버젼이므로 게임의 완성도는 신경쓰지 마시고 작동 여부정도만 확인해보시면 될 것 같습니다 :)

우선 유니티5로 업그레이드 하기 전에 반드시 프로젝트를 백업해두시길 바랍니다. 업그레이드를 시작하면 돌이킬 수가 없으므로 혹시 모를 불상사는 항상 대비해두셔야합니다. 백업 후 유니티5를 실행하시면 유니티4와는 다르게 프로젝트를 선택하는 창이 먼저 뜹니다. 
업그레이드하려는 프로젝트를 선택하면 잠시 후 다음과 같이 업그레이드를 진행하겠다는 창이 뜹니다. upgrade버튼을 눌러서 업그레이드를 진행합니다. 

이후 유니티가 업그레이드를 알아선 진행합니다. 시간이 좀 지난 후 다음과 같은 창이 뜹니다. 유니티5로 넘어오면서 스크립트 API들이 변경 된 사항들이 있습니다. 이를 자동으로 바꿔주겠단 소리인데 Go Ahead를 선택하여 진행해줍니다. 
이 과정들이 매우 오랜 시간이 소요됩니다. 침착함을 가지고 커피한잔의 여유를 즐기세요 :)


오류 사항들

업그레이드가 완료되고나면 수 많은 에러 상황들이 발생할 것입니다. 그런것 없이 완벽하게 마이그레이션 되었다면 당장 꿈에서 깨어나세요 용사여! 꿈이 아니라면 축하드립니다. 당장 사표 한장 집어던지고 뛰쳐나가서 로또 한장 사세요 :)

맨 처음 눈에 들어오는 것은 스카이박스일것입니다. 스카이박스의 십중팔구는 이미지가 정상적으로 나오지 않을 것입니다. 유니티5에서는 스카이박스가 HDR로 그려지는데 유니티4에서 설정했던 LDR 스카이박스를 가져오면 아래와 같이 깨집니다. 이는 간단히 수정 가능합니다. 해당 스카이박스를 선택 후 inspector창에 나오는 Fix now 버튼을 누르시면 해결됩니다.

셰이더에 문제가 발생하시는 분도 계실 수 있습니다. 유니티에서 기본적으로 제공하는 셰이더만 이용한다면 문제가 발생하지 않으실겁니다. 하지만 커스텀 셰이더를 이용하는 경우는 라이팅이 정상적으로 그려지지 않을 수 있습니다. 저같은 경우는 다음과 같이 이상하게 셰이더가 망가져 보였습니다. 
이는 셰이더로 넘겨주는 normal값때문에 발생하는 문제입니다. 유니티5에서는 셰이더로 넘어오는 vertex의 normal값이 메시의 스케일링이 적용되서 넘어옵니다. 따라서 항상 길이가 1이라는 보장이 없습니다. 또한, unity_Scale.w가 작동하지 않습니다. 그렇기때문에 셰이더에서 normalize를 해주어야 합니다. 이는 binormal, tangent 모두 동일하게 적용됩니다. 또한, 기존에는 라이트의 atten 값을 두배로 뻥튀기해줘야만 했는데 이제는 그러지 않아도 됩니다. 기타 셰이더 관련 가이드를 참고하여 수정하시면 정상적으로 보입니다. ( 본 포스팅 마지막의 링크들 참고)

오브젝트의 스케일이 틀어져있는 경우도 존재합니다. 기존에는 FBX 익스포트 시 적용 된 스케일이 정상적으로 적용되지 않는 문제가 있었는데 이제는 정상 반영이 됩니다. 따라서 FBX 메시들의 스케일이 변경되는 것 들이 있습니다. FBX import 설정에서 스케일을 변경시켜주면 됩니다.
간혹 skinned mesh가 깨지는 경우도 있습니다. 서로 다른 레거시 에니메이션과 메시를 휴머노이드로 조합한 이루어진 오브젝트가 간혹 깨지는 경우가 있습니다. 아직 정확한 조건은 확인하지 못하였습니다. 이런 경우는 답이 없습니다만 매우 드문 케이스이므로 크게 걱정하지는 않으셔도 될 듯 합니다.
유니티5에서는 라이트맵 솔루션이 비스트에서 인라이튼으로 바뀌었습니다. 따라서 라이트맵 관련 설정을 다시 손봐주셔야합니다. 기존 버젼에서부터 만들던 모바일 프로젝트라면 실시간 GI를 사용하지 않는 경우가 대부분일테니 Baked GI 외 다른 옵션들은 다 꺼주시면 됩니다. 
GI 관련하여 라이팅 타입 속성이 추가되었습니다. 라이팅 오브젝트의 인스펙터창에 Baking 타입을 설정 할 수 있는 콤보 박스가 있습니다. Baked로 설정해두면 실시간 라이팅에는 반영되지 않고 라이트맵에만 반영되는 라이트가 됩니다. 제 프로젝트의 경우에는 실시간 라이팅을 전혀 사용하지 않고 IBL만 사용하므로 모든 라이트를 Baked로 설정해두었습니다.

또한, 오브젝트의 인스펙터 창에서도 속성들이 추가된 것 들이 있으니 이를 건드려줘야 합니다. Cast Shadow, Receive Shadows, Use Light Probes는 기존에도 있는 속성이였으나 기존 설정이 날라갔을 수도 있으니 한번 더 확인해줘야합니다. Reflection Probes는 새로 생긴 속성이므로 체크 해제해주어야 의미없는 성능 소모를 줄일 수 있습니다. 

유니티5 에서는 메카님이 대폭 개선되었습니다. 기존 버젼 호환이 최대한 작업이 되어있긴 하지만 트랜지션이 누락되는 경우도 가끔 존재합니다. 또한 state에 Write Defaults라는 속성이 생김으로 인해서 기존에 예측했던 동작과 다르게 보이는 경우도 존재할 수 있습니다. 그냥 메카님은 전체적으로 한번 검토해보시는 것이 좋을 듯 합니다.


기타

제 프로젝트는 이러한 수정 사항들이 있었습니다만 프로젝트마다 수정 필요 사항들이 각기 다를것입니다. 더 자세한 내용은 아래 업그레이드 가이드들을 참고 바랍니다.

공식 메뉴얼 (영문) :
한글 번역본 :

결론적으로 말씀드리자면, 작은 프로젝트 혹은 개발 초기 단계의 프로젝트들은 유니티5로 업그레이드 시 큰 무리는 없어보입니다. 유니티 직원으로서는 무조건 유니티5로 업그레이드 하라고 말씀드리고 싶지만, 현실적으로는 규모가 크거나 출시 임박인 프로젝트는 한번 검토를 해보시는 것이 좋을 듯 합니다.
뭐 어찌되었든 유니티5의 세계로 오신 것을 환영합니다!


Posted by ozlael
,