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

이 글은 유니티 자습서Best Practices 문서 중 Resources Folder를 번역/의역한 것입니다.


Resources 폴더

이 글은 “유니티5의 에셋과 리소스 관리” 시리즈의 3번째 글입니다.


이 챕터는 Resources 시스템에 대하여 다룹니다. 이 시스템은 개발자가 여러 에셋들을 Resources 폴더에 두고 런타임동안 Resources API를 통해서 에셋을 로드/언로드할 수 있도록 해줍니다.


2.1 Resources 시스템을 위한 실용 가이드


사용하지 마세요.


다음과 같은 이유들로 사용하지 않기를 강력하게 권고합니다

  • Resources 폴더를 사용하는 것은 메모리 관리를 더욱 복잡하게 만듭니다.

  • Resources 폴더를 부적절하게 사용하면 어플리케이션 시작 시간과 빌드 시간을 늘리게 됩니다.

  • Resources 폴더들이 많아지면 그 안에 있는 에셋들의 관리가 힘듭니다.

  • Resources 시스템은 사용자 정의 컨텐츠를 특정 플랫폼으로 옮기는 것이 까다로워집니다. 컨텐츠를 업그레이드하는 경우도 마찬가지입니다.

  • 디바이스에 맞는 컨텐츠를을 조정하는데 적합한 주요 기능은 에셋번들입니다.


2.2 Resources 시스템의 적절한 사용

다음과 같은 두 가지의 경우에는 개발 시 Resources 시스템을 사용하기에 적합한 경우입니다.

  1. 빠른 프로토타이핑이나 검증이 필요한 경우에는 Resources를 사용하기에 좋습니다. 간단하고 사용하기 쉽기 때문입니다. 하지만, 프로젝트가 프로덕션 단계에 가게 되면 Resources 폴더 사용을 중단해야 합니다.

  2. Resources 폴더는 다음 모든 경우를 만족하는 상황에서는 유용한 시스템입니다.

    • Resources 폴더에 들어있는 컨텐츠들은 메모리에 민감한 것 들이 아닐 경우

    • 컨텐츠가 어플리케이션의 수행 시간 동안 계속 필요한 경우

    • 컨텐츠가 패치될 일이 거의 없는 경우

    • 컨텐츠가 플랫폼이나 디바이스별로 달라지지 않는 경우

이 중 두 번째 케이스에 해당하는 예시는 전역으로 사용되는 싱클턴 모노비헤이비어나 페이스북 앱 ID등의 서드파티 데이터를 다루는 에셋등이 될 것입니다.


2.3 Resources의 시리얼라이제이션

프로젝트 빌드 시 “Resources” 폴더 내 모든 에셋과 오브젝트들은 하나의 시리얼라이즈된 파일에 정보가 담깁니다. 이 파일은 에셋번들처럼 메타데이터와 인덱싱 정보를 포함합니다. “에셋번들 의 근본”챕터의 “에셋번들이란 무엇인가?” 섹션에서 설명된 바와 같이, 이 인덱싱 정보는 시리얼라이즈된 룩업  트리를 포함합니다. 여기에는 주어진 오브젝트 이름을 파일 GUID와 로컬 ID와 매칭시키는데 쓰이는 정보들을 포함합니다. 오브젝트를 시리얼라이즈된 파일의 몇 바이트째 위치시키느냐등의 정보도 포함합니다.


룩업 데이터 구조가 균형잡힌 탐색 트리라서 구축 시간 비용은 O(N log(N)) 비율로 증가합니다.(대부분의 플랫폼에서는 C++ Standard Template Library의 std::multimap를 사용합니다.) 여기서 N은 트리에 들어가는 오브젝트 갯수를 의미합니다. 이러한 증가치는 인덱스의 로딩 타임에 많은 비용이 들게합니다. 따라서 Resources 폴더 안의 오브젝트들이 많을수록 성능에 좋지 않습니다.   


이 동작은 건너뛸 수 없기때문에 어플리케이션의 초기 시작 시간을 늘리게 되서 인터렉션이 불가능한 스플레시 화면이 떠 있는 시간이 길어지는 요인이 됩니다. 특히 저사양 기기일 수록 Resources 시스템에 많은 오젝트가 포함되있으면 어플리케이션 시작 시간이 매우 길어지게 됩니다. 특히, Resources 폴더의 대부분의 오브젝트들이 첫 씬에서 보여질 필요가 없는 경우에는 효율적이지 못한 상황이 되는 것입니다.




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


게임 그래픽에서 반사의 표현은 매우 중요한 시각적 요소 중 하나입니다. 주변 환경의 반사를 표현함으로써 금속 재질을 처리할 수 있기 때문입니다. 판타지물의 투구라든가 SiFi물의 로보트 등 금속 재질에서의 반사 표현 여부는 그래픽 퀄리티에 큰 영향을 미칩니다.

유니티5에서 라이팅 관련 기능이 강화되면서 리플렉션 프로브(Reflection Probe) 기능이 추가되었습니다. 이름에서 유추할 수 있듯이, 라이트 프로브(Light Probe)처럼 특정 지점들의 리플렉션을 미리 연산해서 프로브에 저장해놓는 것입니다. 

라이트 프로브 및 라이트맵(Lightmap)이 정적(static)인 오브젝트와 Baked 또는 mixed로 설정 된 라이트만 반영하는 것과 마찬가지로, 리플렉션 프로브 역시 정적인 오브젝트들만 반영한다는 등의 제약점들이 있긴 합니다. 하지만 부분 부분 마다의 반사를 제대로 반영할 수 있다는 점은 크나큰 매력이 될 것입니다. 자세한 사용법은 메뉴얼 및 블로그 글을 참고하세요. (PHYSICALLY BASED SHADING IN UNITY 5: A PRIMER, 리플렉션 프로브, 리플렉션 프로브 개요리플렉션 프로브 사용하기, 물리 기반 쉐이딩으로 작업하기) 메뉴얼의 글은 조만간 한글로 업데이트 될 예정입니다.

사실, 반사의 표현은 유니티5에서부터만 쓰게된 것은 아닙니다. 전통적으로 큐브맵(Cubemap)을 사용하여 쉐이더에서 반사를 표현해왔습니다. 유니티에 내장(Built-in)된 기존 쉐이더(Legacy Shader)에서도 이러한 큐브맵 반사들을 지원해왔습니다. (메뉴얼 : 반사 쉐이더 Family

하지만 기존의 쉐이더들은 특정 큐브맵을 명시적으로 지정해줘야만 하고 위치마다 다른 환경을 반영하는 리플렉션 프로브를 적용하지는 않습니다. 때문에, 내장 쉐이더에서 리플렉션 프로브를 사용하기 위해서 스탠다드 쉐이더(Standard Shadder)를 이용하여야합니다. 하지만, 저가의 보급형 모바일 기기에서는 스탠다드 쉐이더를 사용하기에는 성능의 부담이 존재합니다.

따라서, 모바일에서 리플렉션 프로브를 사용하기 위해서는 내장되어있는 기존 쉐이더나 스탠다드 쉐이더 대신, 쉐이더를 직접 작성한 커스텀 쉐이더를 사용하여야 합니다. 사실, 리플렉션 프로브도 근본적인 형태는 큐브맵입니다. 큐브맵을 미리 프로브별로 미리 구워놓고 가지고 있는 것이지요. 오브젝트의 위치에 따라서 적절한 큐브맵을 리플렉션 프로브로부터 가져오게 되는 것입니다. 

여차 저차 서론이 길어졌습니다만 결론만 말씀드리면 큐브맵을 인스펙터 창에서 지정해서 받아오는 대신 유니티에서 사전 정의해놓은 uniform sampler를 사용하여 큐브맵을 읽어들이면 된다는 것입니니다.

유니티가 리플렉션 프로브로 들어오는 큐브맵을 unity_SpecCube0로 사전 정의해놓았습니다. 이를 사전 정의된 UNITY_SAMPLE_TEXCUBE()로 읽어들입니다. 사실, UNITY_SAMPLE_TEXCUBE()는 texCUBE()를 디파인 한 것 뿐이지만 모바일 외 다른 플랫폼에서도 정상 작동을 하기 위해서는 UNITY_SAMPLE_TEXCUBE()로 사용하는 것이 좋습니다. 어찌되었든 리플렉션 프로브의 큐브맵으로부터 읽어들인 값에다가 리플렉션 프로브의 HDR 계수인 unity_SpecCube0_HDR의 r속성을 곱해주어서 반사 이미지의 최종 결과물을 얻습니다. 서피스 쉐이더를 작성하는 경우에는 surface 아웃풋의 Emission으로 이 값을 설정해두면 됩니다.

o.Emission = UNITY_SAMPLE_TEXCUBE(unity_SpecCube0, rv).rgb * unity_SpecCube0_HDR.r;

이름이 unity_SpecCube가 아니라 뒤에 0가 붙었다는 것을 보면 unity_SpecCube1도 존재한다는 것을 유추하실 수 있을 것입니다. unity_SpecCube0_HDR도 마찬가지로 unity_SpecCube1_HDR이 존재합니다. 이를 설명하기 위해서 오브젝트의 Mesh Renderer 인스펙터를 살펴보겠습니다. Reflection Probes 드롭다운을 내려보면 항목 중 Blend Probes라는 항목이 있는 것을 확인 가능합니다. 말 그대로 리플렉션 프로브를 블렌딩 해준다는 의미입니다. 오브젝트가 각기 다른 리플렉션 프로브 영역으로 이동 할 시 리플렉션 이미지가 갑자기 틱 하고 바뀌는 것을 방지하기 위하여 블렌딩을 해주는 것입니다. 

그러기 위해서는 쉐이더에서 큐브맵 두 개를 읽어야한다는 의미가 됩니다. unity_SpecCube1을 unity_SpecCube0와 같이 읽어들인 다음 unity_SpecCube0_BoxMin.w값으로 보간해주면 됩니다. 원래는 이런 블렌딩 기능을 UNITY_SPECCUBE_BLENDING 디파인으로 묶어놓아야 합니다. 하지만 모바일 타겟에서는 UNITY_SPECCUBE_BLENDING 디파인이 꺼져있기 때문에 해당 디파인에 종속적이지는 않게 두었습니다. 사실, 모바일에서 성능을 생각한다면 블렌딩 기능은 사용하지 않는 것이 좋습니다. 다만, 금속 느낌이 강한 재질이여서 이미지가 툭툭 바뀌는 모습이 크게 거슬린다면 블렌딩 연산을 사용할 수 밖에 없을 것입니다.

fixed3 blendTarget = UNITY_SAMPLE_TEXCUBE(unity_SpecCube1, rv).rgb * unity_SpecCube1_HDR.r;

o.Emission = lerp(blendTarget, o.Emission, unity_SpecCube0_BoxMin.w);

그러고 나면 리플렉션 프로브가 자연스럽게 반영되는 모습을 확인 할 수 있습니다. 다음 영상은 리플렉션 프로브를 사용하는 커스텀 쉐이더를 적용한 드론의 모습을 보여주고 있습니다. 

모두 유료 에셋을 사용한 관계로 프로젝트를 공유해드리지 못하는 점 양해 바랍니다. 다만 제작한 쉐이더의 전체 코드는 다음과 같습니다.

Shader "Example/WorldRefl Normalmap Refl" {

Properties{

_MainTex("Texture", 2D) = "white" {}

_BumpMap("Bumpmap", 2D) = "bump" {}

_Metalic("Metalic", Range(0,1)) = 0.5

_MetalicMap("Metalicmap", 2D) = "white" {}

}

SubShader{

Tags{ "RenderType" = "Opaque" }

CGPROGRAM

#pragma surface surf FakeMetal noshadow nolightmap 

struct Input {

float2 uv_MainTex;

float2 uv_BumpMap;

float3 worldRefl;

INTERNAL_DATA

};


struct SurfaceOutputCustom

{

fixed3 Albedo;  // diffuse color

fixed3 Normal;  // tangent space normal, if written

fixed Alpha;    // alpha for transparencies

fixed3 Emission;

fixed3 Metalic;

};


sampler2D _MainTex;

sampler2D _BumpMap;

sampler2D _MetalicMap;

fixed _Metalic;


half4 LightingFakeMetal(SurfaceOutputCustom s, half3 lightDir, half3 viewDir, half atten) {

half NdotL = saturate(dot(s.Normal, lightDir));

half diff = NdotL * 0.5 + 0.5; // Half-Lambert

half4 c;

c.rgb = s.Albedo *_LightColor0.rgb * (diff * atten);

c.a = s.Alpha;

c.rgb *= 1 - s.Metalic;

return c;

}


void surf(Input IN, inout SurfaceOutputCustom o) {

o.Albedo = tex2D(_MainTex, IN.uv_MainTex).rgb;

o.Normal = UnpackNormal(tex2D(_BumpMap, IN.uv_BumpMap));

float3 rv = WorldReflectionVector(IN, o.Normal).xyz;

o.Emission = UNITY_SAMPLE_TEXCUBE(unity_SpecCube0, rv).rgb * unity_SpecCube0_HDR.r;

//#if UNITY_SPECCUBE_BLENDING

fixed3 blendTarget = UNITY_SAMPLE_TEXCUBE(unity_SpecCube1, rv).rgb * unity_SpecCube1_HDR.r;

o.Emission = lerp(blendTarget, o.Emission, unity_SpecCube0_BoxMin.w);

//#endif

o.Metalic = tex2D(_MetalicMap, IN.uv_MainTex).rgb * _Metalic;

o.Emission.rgb *= o.Metalic.rgb;

}

ENDCG

}

Fallback "Diffuse"

}

이는 메탈 느낌에 초점을 맞춘 유사 PBS라고 볼 수 있겠습니다. 물론 PBS는 전혀 아니지만 모바일에서 저렴한 비용으로 PBS의 느낌적인 느낌을 내기에는 적당하지 않나 싶습니다 :)


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

Unity5에서 라이트맵 빌드시 많은 시간이 소요된다는 불편을 호소하시는 분들이 많이들 계십니다. 유니티 또한 이를 인지하고 있으며 라이트맵 빌드를 개선시키기 위해 다방면으로 노력을 하는 중입니다. 이 일례로 현재 작업중인 라이트맵 LAN 분산 빌드(Distributed LAN lighting build)와 점진적 빌드(Progressive Lightmap Baking) 기능을 알려드리고자 합니다. 


라이트맵 LAN 분산 빌드(Distributed LAN Lightmap Build) 

이트맵을 빌드하는 과정은 많은 시간이 소요됩니다. 품질 설정에 따라 빌드 시간이 다르긴 하지만 고품질의 결과를 얻고자 할 수록 더 많은 시간이 필요할 수 밖에 없습니다. 품질을 낮추지 않으면서 빌드 시간을 단축 시키는 유일한 방법은 더욱 고성능의 PC를 사용하는 것입니다. 라고 말씀드린다면 너무 무책임한 말이 되겠지요 :) 아마 대부분은 이미 충분히 고성능의 컴퓨터에서 작업을 하고 계실 것이기때문에 유니티에서는 분산 빌드 시스템 도입을 작업중입니다. 백지장도 맞들면 낫다는 말이 있듯이, 라이트맵을 하나의 컴퓨터로만 빌드하는 것이 아니라 여러 PC에서 함께 연산하는 것입니다. 에이전트 컴퓨터에서 라이트맵을 빌드할 시, LAN으로 연결되어 있는 다른 컴퓨터에 작업 단위를 나누어서 할당해줍니다. 그 후 컴퓨터들은 각자 작업을 거친 후 다시 작업물을 에이전트 컴퓨터로 모아서 최종 마무리를 거치면 라이트맵이 완성 되는 것입니다. 이리하면 컴퓨터가 많을 수록 라이트맵 빌드 시간이 획기적으로 단축 될 수 있게 됩니다. (아래 이미지는 여러 컴퓨터와 연결 된 에이전트 컴퓨터의 빌드 화면을 보여주고 있습니다.)

참고 영상 링크 : https://www.youtube.com/watch?v=W7aaM9M0YWo&feature=youtu.be


점진적 빌드(Progressive Lightmap Baking)

앞서 말씀드렸다시피 현재 라이트맵을 빌드하면 그 결과를 보기 전까지는 긴 시간이 소요됩니다. 씬을 수정 하 긴 시간 라이트맵을 빌드하고 다시 씬을 수정하는 반복 과정을 거치면서 작업하는 것은 매우 고통스러운 시간이 될 것입니다. 이를 보완하기위해 라이팅 인스펙터에서 자동(Auto) 빌드 기능을 제공해주고 있습니다. 하지만, 라이트맵 빌드 자체가 오래걸리기 때문에 완벽한 해결책이 되지는 못합니다. 따라서, 유니티에서는 라이트맵이 저해상도에서 고해상도로 빌드 되는 과정을 미리 보여주며 빌드하는 기능을 작업 중입니다. 마치 GIF 이미지를 열었을 때 저해상도의 이미지로 보여줬다가 로딩됨에따라 원본 해상도의 이미지로 보여주는 과정을 생각하시면 될 것 갑습니다. 이렇게 함으로써 씬 변경 후 대략적인 라이트맵 결과를 빨리 확인하고 다시 씬 구성을 바꾸는 등 씬 작업 이터레이션을 효율을 획기적으로 개선시킬 수 있게 됩니다. (아래 이미지는 빌드 버튼을 누른 후 시간이 지남에 따라 보여지는 모습을 나타냅니다.)

참고 영상 링크 : https://drive.google.com/a/unity3d.com/file/d/0B11iL4IgOgWLUTJWU1ZXOXFheTA/view


계획

다만 앞서 말씀드렸다시피 이 기능들은 아직 작업중입니다. 기본적인 기능은 완료 된 상태이긴 하지만 실제 릴리즈까지 가기 위해서는 아직 손 봐야 할 부분이 많습니다. 따라서 구체적인 스케쥴이나 기능 탑재 버전등의 세부 계획에 대해서는 말씀드리기가 힘듭니다. 다만, 개발자 여러분들의 불편사항을 없애기위해 최선을 다하고 있으며 라이트맵 빌드 또한 개선중에 있다는 것을 말씀드리고자 합니다. 감사합니다.


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

"모바일 기기의 Tile Based Rendering(타일 기반 렌더링)과 유니티에서의 주의 사항 #1 : TBR의 이해"에서 이어지는 글입니다. 


앞선 글에서 설명드린 바와 같이 모바일에서는 타일 단위로 쪼개서 렌더링하는 방식을 사합니다. 그러다보니 전통적인 렌더링 방식에서와는 조금 다른 주의 사항이 몇 가지 존재합니다. 


알파블렌딩(Alpha Blending) VS 알파테스트(Alpha Test)

전통적으로 데스크톱 게임의 리소스에는 알파블렌딩보다 알파테스트의 사용이 권장되어왔습니다. 불투명한 철망이라든가 찢어진 옷감같은 경우는 불투명하기때문에 비싼 블렌딩 연산을 사용하기보다는 알파테스트를 사용함으로써 픽셀 연산도 절약하자는 의도였습니다. 하지만 모바일의 TBR(Tile Based Rendering, 타일 기반 렌더링)에서는 정반대로 알파테스트보다는 알파블렌딩의 사용이 권장됩니다. 

알파테스트처리를 하기 위해서는 픽셀쉐이더에서 동적분기(if문)가 사용됩니다. 데스크톱에서는 쉐이더의 동적 분기가 고속으로 처리되지만, 모바일에서는 동적 분기 성능이 취약합니다. 때문에 알파테스트는 쉐이더의 성능윽 하락시키는 원인이 됩니다.

게다가, TBDR(Tile Based Deferred Rendering, 타일 기반 지연 렌더링)에서는 픽셀 차폐의 고속 처리를 깨트립니다. 앞서 언급했다시피 TBDR에서는 여러 드로우콜의 버텍스 쉐이더 결과를 모아두었다가 은면 제거(Hidden Surface Removal)를 거친 뒤 실제 보이는 픽셀만 처리합니다. 하지만 이는 알파테스트를 사용하지 않는 완전한 불투명메시일 경우에만 해당됩니다. 알파테스트를 사용하면 버텍스 처리 단계에서는 해당 폴리곤이 차폐 되는지의 여부를 판단할 수 없기때문에 Deferred 처리를 깨트릴 수 밖에 없게됩니다.

유니티에서는 이를 방지하기위해서 완전 불투명 오브젝트들을 모두 렌더링처리한 후에 알파테스트 오브젝트들을 렌더링합니다. 따라서 알파 테스트를 제한적으로만 사용한다면 그렇게 치명적이지는 않습니다. 하지만 애초에 TBDR 칩셋의 구조가 알파테스트 처리에 적합하지 않기 때문에 알파테스트를 사용하지 않는 것이 좋습니다. 그런 이유로, 유니티의 내장 쉐이더 중 Mobile 카테고리에는 알파 테스트 쉐이더가 존재하지 않습니다.

반면에, 알파블렌딩은 데스크톱에 비해서 고속으로 처리가됩니다. 알파블렌딩과정은 출력 내부적으로 대상 버퍼의 읽기/쓰기가 발생합니다. 데스크톱에서는 DRAM에 존재하는 프레임버퍼 전체에 접근해야하기때문에 높은 대역폭을 잡아먹게됩니다. 하지만 TBR에서는 이 처리가 타일 단위로 이루어지고 칩 내부에 존재하는 메모리에서 이루어지므로 고속으로 처리됩니다.


오버드로우

다만 명심해야 할 것은 알파 블렌딩 처리 자체가 빠르다는 것일 뿐이지 오버드로우에서 자유로와진다는 것은 아닙니다. 예를 들어서 넓은 영역의 파티클을 높은 밀도로 뿌리는 것은 여전히 오버드로우 문제를 일으켜서 성능 저하로 직결됩니다. 모바일은 쉐이더 성능이 기종에 따라 천차만별이므로 오버드로우로 인해서 쉐이더 싸이클이 낭비되는 것은 치명적인 문제가 됩니다. 웬만하면 불투명 오브젝트 위주로 리소스를 만들기를 권장합니다. 알파 블렌딩 오브젝트 또는 파티클은 오버드로우를 최대한 피해서 사용하시기를 권장합니다.


로우 폴리곤

너무나 당연한 이야기라 뜬금없어 보일수도 있겠지만 많은 폴리곤을 처리하면 성능이 하락합니다. 게다가, TBDR에서는 많은 폴리곤 처리의 부담이 더욱 큽니다. 앞서 설명드린 버텍스 쉐이더의 결과물들을 담아두는 파라미터 버퍼(Parameter Buffer)의 크기는 당연하게도 무한하지 않습니다. 따라서 이 버퍼가 넘쳐버리면 더 이상의 버텍스 쉐이더 결과물을 받아들이지 못하고 버퍼를 비워줘야합니다. 이 버퍼를 비워주기 위해서는 타일의 픽셀 처리 후 프레임버퍼로 출력하는 사이클을 거쳐야합니다. 때문에, 이론상으로는 TBDR에서는 픽셀의 오버드로우가 발생하지 않아야하지만, 현실적으로는 폴리곤이 많을수록 오버드로우가 발생하게 발생하게 됩니다. 그러므로 오브젝트의 렌더링 퀄리티를 높여야한다면 버텍스를 늘리는 것 보다는 픽셀쪽 연산을 늘리는 것이 오히려 이득일 수도 있습니다.


렌더 텍스쳐(Render Texture)

렌더 텍스쳐를 사용하면 유니티 내부적으로 렌더 타겟(Render Target)을 변경하는 행위를 거치게됩니다. 이러한 렌더타겟을 변경하는 행위는 데스크톱에서도 성능을 잡아먹는 행위가 됩니다. 렌더 타겟을 바꾸기위해서는 CPU가 GPU를 대기하는 과정을 거치게되면서 CPU와 GPU의 병렬 관계가 잠기 깨지는 현상이 발생하기 때문입니다. 

게다가, TBDR에서는 더욱 치명적인 행위가 됩니다. 렌더 타겟을 변경할 시에는 현재 파라미터 버퍼에 쌓여있는 데이터들을 모두 처리해주고 프레임버퍼에 출력합니다. 그 후 다음 렌더 타겟을 위해서 파라미터 버퍼를 비워줍니다. 이런식으로 렌더 타겟을 바꿀 시 deferred 사이클을 추가적으로 처리해줘야 합니다. 때문에 유니티의 카메라에서 타겟 텍스쳐(Target Texture)로 렌더 텍스쳐를 사용하는 경우에는 TBDR의 효율이 떨어지게 됩니다.

이미지 후처리 효과(Image post process Effect)

최근 디바이스들은 컬러 그레이딩이나 블룸 효과 등 이미지 후처리들을 사용할 수 있을 만큼 성능이 좋아졌습니다. 하지만 이러한 이미지 후처리들을 너무 남발해서 사용하면 안되고 필요한 것만 선택적으로 사용해야 합니다. 

우선, 이미지 후처리들은 내부적으로 렌더 타겟을 변경하는 행위를 합니다. 하지만, 더 큰 문제는 대역폭입니다.  물론 픽셀 처리 능력도 관건이지만 대역폭이 더욱 큰 문제가 됩니다. 이미지 후처리들은 현재 렌더링 한 결과를 담고있는 렌더 타겟을 픽셀쉐이더의 입력 텍스쳐로 가져옵니다. 이 때 입력받는 텍스쳐는 칩 내부에 있는 타일이 아니라 공용 메모리에 있는 렌더 타겟을 가져오기때문에 엄청난 대역폭을 잡아먹게 됩니다. (예 : 1080p) 그러므로 이미지 후처리는 신중하게 사용해야 합니다.


카메라 클리어(Clear)

예전의 데스크톱 그래픽카드에서는 한 프레임의 렌더링을 시작하기 전 일부러 화면을 클리어해주지 않고 렌더링을 시작하는 경우도 있었습니다. 하지만 현대의 데스크톱 그래픽카드에서는 반드시 클리어를 해주어야만 하드웨어의 고속 처리를 지원받을 수 있습니다. 이는 모바일 기기의 TBR에서도 마찬가지입니다. 클리어를 수행하여 칩 내부의 버퍼들을 비워줘야만 이후 렌더링 과정을 고속으로 처리할 수 있습니다. 따라서, 유니티의 카메라에서 Clear Flag를 Don’t clear로 두는 것은 데스크톱에서나 모바일에서나 웬만해서는 권장되지 않습니다. 


MSAA

데스크톱에서는 MSAA가 매우 큰 부담이 됩니다. 역시 마찬가지로 대역폭이 가장 큰 원인입니다. 예를 들어 1080p해상도의 화면을 MSAA 2X로 처리하려면 2160p만큼의 대역폭이 필요해집니다. DRAM으로부터 그만큼의 대역폭을 요구한 다는 것은 매우 큰 부담이 되는것입니다. 하지만 TBR에서는 이 역시 칩 내부의 타일에서 이루어집니다. 16x16 혹은 32x32정도에 불과한 타일로 MSAA처리해주는 것은 그리 부담이 되지 않습니다. 

유니티에서 MSAA를 사용하기위해서는 퀄리티 셋팅에서 Anti Aliasing을 2 혹은 4로 선택해주면 됩니다. 다만 개인적으로는, 매우 높은 DPI를 자랑하는 대부분의 모바일 기기에서 안티 앨리어싱이 굳이 필요할 지는 모르겠습니다 :)


프로파일링

유니티5부터 프레임 디버거(Frame Debugger)가 추가되어서 프레임 별 렌더링 과정을 디버깅해볼 수 있게 되었습니다. 이를 통해서 오브젝트의 렌더링 과정이나 배칭 현황을 손쉽게 확인 해 볼 수 있게 되었습니다.  

이미지 출처 : http://docs.unity3d.com/Manual/FrameDebugger.html

하지만 애석하게도 유니티의 프레임 디버거만으로는 드로우콜 별 GPU 퍼포먼스나 세부 상태를 확인하기는 힘듭니다. 다행히도, 칩셋 벤더마다 렌더링 과정을 세부적으로 프로파일링을 해볼 수 있는 툴을 제공해주고 있습니다. 아드레노 칩셋은 아드레노 프로파일러를 통해서, 말리 칩셋은 말리 프로파일러나 DS-5를 통해서, 아이폰은 XCODE를 통해서 프로파일링을 해볼 수 있습니다.

이미지 출처 : http://www.slideshare.net/ozlael/graphics-opt-ndc

다만 문제가 하나 있습니다. TBR 방식을 사용하는 칩셋은 콜 별 설능을 확인하는데 어려움이 없습니다. 하지만 TBDR 방식을 사용하는 칩셋은 콜 별 성능을 직관적으로 확인하는게 사실상 불가능하다는 것입니다. TBDR은 앞서 언급했다시피, 드로우콜 발생 시 픽셀 쉐이더를 즉시 처리하는 것이 아니라 파라미터 버퍼에 결과를 담아둡니다. 그 후 모든 드로우콜을 마치고 나면 그때서야 실제 렌더링을 수행하기 때문에 콜 별 성능을 실질적으로 확인해 볼 수가 없는 것입니다. 따라서 X-code에서 아이폰의 렌더링을 프로파일링 해보면 성능 관련 숫자가 0으로 나오게 됩니다. 0이 아닌 숫자가 나오는 경우도 있지만 이 역시 신뢰할 수 없는 숫자입니다. 대신 프레임 전체에 걸린 성능을 확인해보거나 콜 당시의 사용 텍스쳐 등 주변 정보로 유추해보는 수 밖에 없습니다. 이처럼 아이폰의 프로파일링은 좀 까다로운 편입니다.

이미지 출처 : http://www.slideshare.net/ozlael/graphics-opt-ndc


화면 변화율

TBR에서는 렌더링을 칩 내부의 타일에다 하는 과정은 대역폭을 먹지 않지만, DRAM 영역에 존재하는 프레임 버퍼에 타일을 출력하는 과정에서는 어느 정도는 대역폭이 필요할 수 밖에 없게됩니다. 이러한 대역폭을 조금이나마 절약하기 위해서 말리에서는 트랜잭션 엘리미네이션(Transaction Elimination)이라는 기술을 사용합니다. 타일 별로, 이전 프레임과 화면 결과가 달라지지 않은 타일의 영역은 프레임버퍼를 갱신하지 않고 이전 프레임의 결과를 재활용 하는 것입니다. 그렇게 하면 칩 내부 메모리에서 시스템 메모리로 복사하는 양이 줄어드는 효과를 갖게됩니다. 아래 예시 이미지의 파란 글자 타일이 바로 그 부분에 해당합니다. 

이미지 출처 : http://community.arm.com/

따라서, 고정 카메라를 사용한다면 스카이박스 등의 배경에는 최대한 변화를 피하는 것도 좋은 방법이 될 수도 있습니다. 현실적으로는 3D 게임에는 이러한 조건에 해당하는 경우가 많지는 않을 것입니다. 하지만 2D 게임에는 적합하는 부분이 많은 것입니다.


마치며

TBR에 관한 내용이랑 TBDR에 관한 내용을 같이 언급하긴 하였습니다. 하지만 대부분은 아이폰이나 안드로이드폰만 타겟으로 설정하고 개발할 것이고, 플랫폼마다 데이터를 별도로 제작하지는 않을 것이라 예상합니다. 따라서 현실적으로는 TBR, TBDR 모두 고려대상으로 삼고 이러한 사항들을 인지하면서 개발하여야 할 것이라 생각합니다.

감사합니다.


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

개요

기술이 발전하고 시간이 지남에 따라 그래픽카드 성능 역시 계속 발전해왔습니다. 그 덕에 더욱 놀랍고 사실적인 그래픽을 표현할 수 있게 되어왔습니다. 그 결과 현대의 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 대응 리소스 제작시 주의점



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

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)


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



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
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

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

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

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




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


견본 환경 만들기

텍스쳐링과 셰이더 설정을 알맞게 결정하기 위해서는 간단한 신을 다양한 라이팅 셋업으로 테스트해보는 것을 추천합니다. 이는 각기 다른 스카이박스와 라이팅 등 모델의 조명에 연관되는 것 들을 의미합니다. 유니티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




Posted by ozlael
,