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 크기의 광고 코드만 넣을 수 있습니다.


유니티 5.2가 배포 된 이후 애로 사항을 겪는 분들이 계시는 것으로 알고 있습니다. 

5.2;;;

조만간 이를 보완하기 위한 패치가 릴리즈 될 것이며 공식 버전 또한 지속적으로 배포될 것입니다. 유니티의 로드맵이 공개되었습니다. 더불어, 주간 패치와 월간 공식 릴리즈에 대한 유지 보수 엔지니어링 팀의 계획을 공유하고자 합니다. (원문 : UNITY PATCH RELEASE PLAN)


5.1 패치 릴리즈

유니티 5.1.4는 5.1.x.의 마지막 공식 릴리즈가 될 것입니다. 이는 지난 5.1.3p1, 5.1.3p2, 5.1.3p3 패치를 모두 포함하는 것입니다. 9월 8일 5.2.0이 릴리즈됨과 동시에 패치 개발 주기는 5.2 버전에 맞춰지게 되었습니다. 따라서, 다음 패치는 5.2.0p1이 될 것입니다. 패치 5.2.0p1이 5.1.3p3의 모든 수정 사항들을 포함하는 반면, 5.2.0은 5.1.2까지의 수정 사항만을 반영합니다. 그말인 즉슨, 5.2.1 공식 릴리즈는 5.1.4까지의 모든 사항을 반영하게 된다는 것입니다. 5.2.0p1에는 5.2.0에 포함되지 않았던 많은 버그 수정 내역이 포함되어 있으며, 5.2.0p1 패치 이후 빠른 시일내로 5.2.1 정식 릴리즈를 배포할 것입니다.


5.2+ 패치 릴리즈

5.2.1 공식 릴리즈는 5.2.0p1의 수정 내용 모두를 반영할 계획입니다. 또한 필요에따라서 수정 사항들이 추가적으로 반영 될 수도 있습니다. 5.3.0이 출시되기 전 까지는 5.2.x 패치가 매 주 수요일마다 나오게 될 것입니다. 또한, 매 4주간의 패치 릴리즈 후 정식 릴리즈를 배포함으로써 매 달 마다 공식 릴리즈를 배포할 계획입니다. 이는 5.3.0이 배포된 후 5.3 패치 싸이클에도 마찬가지가 될 것입니다.


4.6 패치 릴리즈

최종적으로, 2015년 12월을 끝으로 4.6에 대한 패치 혹은 공식 릴리즈를 종료할 것입니다. 유니티의 개발력을 유니티5에 집중하기 위한 어쩔 수 없는 선택임을 양해 바랍니다. 이미 4.6 패치 주기가 2주 단위로 줄어든 상태입니다. 격 주 단위로 금요일에 4.6x 패치 릴리즈가 배포될 것이며 공식 릴리즈는 2달 주기로 나오게 됩니다. 2015년 12월 아후로는 더 이상 릴리즈 되지 않을것입니다.


유지 보수 엔지니어링 팀

유니티의 재빨리 버그를 수정하고 전반적인 품질을 높이는데 집중하기 위해서 저희 유지 보수 엔지니어링 팀에 더 많은 엔지니어가 참여하게 되었습니다. 또한, 저희는 포럼을 항상 주시하고 있으며 새로운 릴리즈가 배포될 때 마다의 피드백과 반응을 살피고 있습니다. 저희는 더 많은 작업 계획을 가지고 있으며, 계획이 진행됨에 따라 블로그 포스팅을 올리도록 하겠습니다. 감사합니다.


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

원문 : http://blogs.unity3d.com/2015/09/10/unity-services-are-just-a-few-clicks-away/


유니티 5.2에서 서비스 윈도우가 추가되었습니다. 이를 통해서 에디터상에서  유니티애즈(Unity Ads), 유니티애널리틱스(Unity Analytics), 유니티클라우드빌드(Unity Cloud Build), 유니티멀티플레이어(Unity Multiplayer)를 제어할 수 있습니다. 또한 더 이상 SDK를 별도로 통합하는 과정을 거치지 않아도 됩니다.

우선, Window 메뉴를 통하거나 에디터 우측 상단의 구름 모양의 아이콘을 클릭하여 서비스 윈도우를 열 수 있습니다.

그 후, 프로젝트 ID가 생성됩니다. 이 프로젝트 ID는 프로젝트의 고유 식별 번호가 됩니다. 서비스 윈도우에는 서비스(Services), 멤버(Members), 연령제한(Age Designation), 설정(Settings) 총 4개의 탭이 존재합니다. 


서비스(Services)

프로젝트에서 Unity Ads와 Unity Analytics를 활성화 시키는 것은 매우 간단합니다. 위해서는 스위치를 "On"으로 켜주기만 하면 됩니다. Unity Cloud Build를 위해서는 약관에 동의하기만 하면 됩니다. Unity Multiplayer는 환경 설정을 함으로써 시작할 수 있습니다. 


멤버(Members)

프로젝트(Project)를 공유할 시에는 사람들의 접근 권한을 적용해주는 것이 중요합니다. Members 탭에서 프로젝트의 추가적인 멤버를 초대할 수 있습니다. 또한, 프로젝트의 온라인 대시보드에서 권한을 관리할 수 있습니다. 프로젝트(Project)는 조직(Organization)에 포함될 수 있으며, 조직(Organization)은 여러 프로젝트(Project)를 포함할 수 있습니다.


연령제한(Age Designation)

미국에서는 13세 이하의 어린이가 앱을 사용하도록 허용하기 위해서는 COPPA(the Children’s Online Privacy and Protection Act)를 준수해야합니다. 게임이 이 카테고리에 부합한다면 연련 제한을 “under 13”로 설정하십시요. 유니티애즈와 유니티애널리틱스에서 수집하는 데이터의 제약이 생기긴 하지만 그래도 동작은 이상 없이 합니다.


설정(Settings)

설정(Settings)탭을 이용하면 프로젝트명을 바꿀 수 있습니다. 프로젝트 ID는 아닙니다. 현재의 프로젝트를 다른 프로젝트로 확장하는 용도 등으로 새로운 프로젝트 ID를 생성하기 위해서는 "Unlink"를 누르기만 하면 됩니다. 서비스를 언제든지 다시 시작할 수 있습니다.


대시보드(Dashboard)

유니티 서비스를 활설화하고나면 온라인 대시보드에서 환경을 설정할 수 있습니다. 유니티애즈(Unity Ads), 유니티애널리틱스(Unity Analytics), 유니티클라우드빌드(Unity Cloud Build), 유니티멀티플레이어(Unity Multiplayer)의매뉴얼 문서도 확인하실 수 있습니다.

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

원문 : http://blogs.unity3d.com/2015/09/08/unity-5-2-easy-access-to-unity-services/


Unity 5.2가 출시되었습니다. 다운로드 받으세요.

최신 릴리즈에서 빅 뉴스중 하나는 서비스 윈도우가 추가되었다는 것입니다. 유니티 애즈, 유니티 애널리틱스, 유니티 클라우드 빌드, 유니티 멀티플레이어가 이 서비스 윈도우에 통합되었습니다. 더 이상 각각의 별도의 SDK가 필요하지 않게 되었습니다.


수익을 극대화 시켜주는 유니티 애즈

유니티 애즈는 급속도로 성장중이며, 세계에서 가장 널리 쓰이는 광고 네트워크가 되가고 있습니다. Best Fiends에서 리텐션 감소 없이 어떻게 수익을 250% 극대화시켰는지를 확인해보시면, 왜 더 많은 스튜디오들이 유니티 애즈를 채용하고있는지를 알 수 있을 것입니다.


앱을 자동으로 빌드, 설치, 테스트

유니티 클라우드 빌드는 자동으로 여러 플랫폼을 한번에 빌드하고 쉽게 다운로드하고 공유할 수 있게 해줍으로써서 게임 개발 파이프라인을 최적화시켜줍니다. 이로 인해서 게임 개발 자체에 집중할 수 있도록 도와줍니다. Synapse Games는 "유니티 클라우드 빌드는 빌드 당 45분씩 낭비되던 시간을 0로 바꿔주었습니다"라고 하였습니다. 셋업도 쉽습니다. 지금 사용해보세요.


게임의 성과를 개선

런칭한 게임에서 유니티 애널리틱스를 사용하지 않고있다면 사용해보세요. 사용해보기 전에는 그 효과를 모릅니다. Ultrateam은 그들의 게임 디자인을 결정하기 위해 유니티 애널리틱스를 사용하고나서는 "결과는 놀라웠습니다. 이 간단한 적용이 큰 효과를 가져왔습니다."라며 감탄했습니다.


멀티플랫폼 멀티플레이어 네트워킹

유니티 멀티플레이어를 사용해서 네트워크 게임 제작의 고통을 없애세요. 만드는 게임이 모바일이든 데스크톱이든 콘솔이든 기반 엔지니어링 프레임워크는 동일합니다. 유니티 멀티플레이어 릴레이와 매치메이커 서버 서비스를 무료로 이용해보세요.


강화된 VR

5.2에서 프로젝트 모피어스의 빌드 옵션이 추가되었습니다. 이제 오큘러스 리프트, 기어 VR, 프로젝트 모피어스를 기본으로 탑재하여 고도로 최적화된 VR/AR 파이프라인을 갖추게 되었습니다.


강화된 멀티플랫폼

유니티 5.2는 윈도우즈 10과 유니버셜 윈도우즈 플랫폼(UWP) 빌드 옵션을 추가하였습니다. UWP 앱은 핸드폰뽄 아니라 엑스박스 및 PC등 모든 윈도우 기반 기기에서 수행됩니다.


비주얼 스튜디오 통합

유니티 5.2에서 비주얼 스튜디오가 통합되어 윈도우 머신에서의 코딩과 디버깅이 비약적으로 향상되었습니다. 유니티를 위한 비주얼 스튜디오 커뮤니티 2015 툴이 유니티 인스톨러에서 기본적으로 제공됩니다. 


더 많은 정보

유니티 5.2 릴리즈 노트를 확인하여 더 어떤 뉴스들이 있는 지 알아보십시요. 다중 씬 라이트맵 베이킹, 3DS 맥스 바이패드 리깅, 오클루전 컬링 개선 등 많은 변경 사항들이 있습니다.



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

올해 3월, WebGL의 프리뷰(preview) 버전이 Unity 5.0에 포함되어 릴리즈되었습니다. 그 후, 구글은 크롬 브라우저에서의 NPAPI 지원을 중단하였습니다. (기본값) 이는 더 이상 크롬 브라우저에서 Unity Web Player를 실행할 수 없다는 것을 의미합니다. 때문에, 그 대안으로 WebGL을 사용해야만 합니다. 이미 일부 개발자들이 WebGL로 게임을 배포하였습니다만, 기존 Web Player 게임을 WebGL로 포팅하는 데 애로 사항을 겪고 있는 것으로 알고 있습니다. 이는 Web Player와 WebGL은 완전히 다른 플랫폼이기 때문입니다. 웹 브라우저에서 게임을 돌린다는 궁극적인 목적은 동일하지만, 기반 기술은 완전이 다른 플랫폼입니다. 또한 WebGL은 매우 빠르게 성장하고 있기 때문에 시간이 지날 수록 지원 기능들과 상황이 시시각각 다를 것으로 생각합니다.

이러한 이유로, WebGL에 대한 우리의 계획에 대한 이야기를 할 까 합니다. 이 글은 유니티 공식 포럼의 WebGL 로드맵 글을 번역 및 요약한 글입니다.

주의 : 이 글의 모든 정보는 현재의 WebGL 생태계와 계획에 의존하고 있습니다. 이 모든 것들이 미래에는 어떻게 바뀔 지 장담하지는 못합니다. 기능들에 대한 구체적인 릴리즈 날짜를 보장하지는 못합니다. 또한, 일부는 진행하지 않기로 결정 할 가능성도 있습니다. 따라서, 이 글에서 버전이 언급되는 것은 현재의 계획일 뿐이며 미래를 보장하는 것은 아닙니다. (적고보니 보험광고같은 느낌이;;;)


Unity 5.1의 WebGL

5.1에서의 가장 큰 이슈중 하나는 5.0에서 발견 된 버그들을 수정하는 것입니다. 게다가, IL2CPP팀은 지난 몇 개월 간 IL2CPP의 무수히 많은 문제점들을 고치느라 매우 바쁜 시간을 보냈습니다. WebGL은 스크립트 런타임으로 IL2CPP를 사용하다보니 이로 인해 WebGL 플랫폼의 품질도 좋아지게 되었습니다.

또한, Unity 5.1에서의 WebGL 사용자들에게 중요한 이슈 중 하나는 텍스쳐 압축입니다. 텍스쳐 압축을 통해서 전송량 및 용량을 절약하고, 런타임중에 압축을 풀어 GPU 친화적인 DXTn 텍스쳐로 사용합니다. 일반적으로 텍스쳐가 사이즈를 차지하는 주 된 에셋이기 때문에 이를 통해서 WebGL 컨텐츠의 배포 용량을 획기적으로 줄일 수 있게 됩니다.


"프리뷰(Preview)" 레이블

요즘, 프리뷰(preview) 레이블을 언제 제거할 것인가에 대한 질문을 많이 받습니다. 하지만 이에 대해서는 확답을 드릴 수가 없는 상황입니다. 우리는 플랫폼이 안정화 되었다고 판단되어야만 프리뷰 레이블을 제거할 것입니다. 이는 유니티에서의 기술적인 문제 뿐만 아니라 WebGL의 기술 생태계 역시 충분히 준비된 시점을 의미합니다. 그러기 위해서는 브라우저의 개발사들이 우리가 원하는 기능을 구현해주어야만 합니다. 때문에 우리가 기능을 다 구현했다고 프리뷰 레이블을 제거하는 것은 말이 안되는 행위입니다. 우리는 주요 웹 브라우저 업체와 이야기중이고, 우리가 원하는 기능을 위해 최선을 다하고 있다고 믿고 있습니다.


메모리 이슈

현재의 Unity WebGL에서의 가장 큰 이슈중 하나가 메모리 이슈입니다. 특히 크롬 브라우저에서 Unity WebGL을 돌릴 경우 메모리가 낭비되는 현상이 있습니다. 

- 유니티의 WebGL 콘텐츠를 위해서는 연속된 공간의 메모리 블럭이 필요합니다. 이 사이즈는 WebGL Player 셋팅에서 설정할 수 있습니다. 이 사이즈는 리소스를 로드하면서 필요한 메모리 공간 만큼 충분히 확보되어야 합니다. 메모리 프로파일러를 통해서 공간이 어떻게 쓰이고 있는 지 디버깅 가능합니다. 이는 웹브라우저의 힙(heap) 메모리에 연속적인 공간이 필요합니다. 브라우저의 메모리가 낮게 잡혀있거나 힙이 파편화(fragmented)되어 있는 경우 메모리 할당이 실패해버립니다.

- 브라우저는 자바스크립트(JavaScript)를 파싱하는 과정에서 많은 메모리를 사용합니다. Unity WebGL Player로부터 파생된 자바스크립트 코드는 다른 것에 비해 매우 큰 메모리 공간을 소모합니다. 그리고, 자바스크립트 VM은 이러한 코드들을 분석하는 과정에서 매우 많은 양의 메모리를 필요로합니다. 득히, 크롬 V8은 때때로 이러한 이슈때문에 크래시가 일어나곤 합니다. 반면 파이어폭스는 asm.js로 AOT 컴파일을 수행하기 때문에 비교적 적은 메모리를 사용합니다.

이러한 이유들로 메모리 문제는 가장 큰 이슈이긴 합니다만 고치는 것이 쉽지가 않습니다. 현 시점에서는 우리가 할 수 있는 것은 결과 코드 사이즈를 줄이는 것 뿐입니다. 우리는 사내 워크샵에서 이러한 문제를 고민하였으며, 배포 사이즈를 1.2M까지 줄이는 데 성공하였습니다. 코드 스트리핑을 강화하고 컴파일러 설정을 개선하고 불필요한 코드를 제거 하는 등의 작업을 하였으며 이는 계속 개선해 나갈 것입니다. 이러한 개선 사항들은 5.2에 적용될 것으로 예상합니다. 또한 빌드에 포함된 코드 모듈을 시각적으로 확일 할 수 있는 툴을 만들고 있습니다. 얼마나 많은 코드들이 어떤 것에 의해 생성이 되었는 지 등을 확인할 수 있게 됩니다. 이 툴은 빨라야 5.3은 되어야 적용 될 것입니다. 이를 통해서 빌드 결과 사이즈를 줄일 수 있을 것입니다. 결과물의 코드 사이즈가 줄어들면 코드 파싱 시간이 줄어드는 만큼 구동 시간이 빨라지게 될 것입니다.

궁극적으로는, 브라우저의 기술 발전이 메모리 이슈를 훨씬 더 많이 해결할 수 있을 것으로 기대하고 있습니다. 모든 브라우저들이 64비트로 만들어지고 있으며 더 큰 메모리 공간을 사용할 수 있게 됩니다. 또한, 더 중요한 것은, 모질라, 구글, 마이크로소프트가 웹어셈블리(WebAssembly)라 불리우는 신기술을 만들고 있다는 것입니다. 이는 asm.js를 바이트코드(ByteCode) 포맷으로 패킹함으로써 매우 효과적으로 네이티브 코드로 컴파일 될 수 있게 합니다. 이를 통해서 로드 시간과 메모리 오버헤드와 배포 사이즈를 획기적으로 개선시킬 수 있습니다.


데이터 압축

앞서서 메모리 이슈를 언급했 던 것 처럼, 배포 사이즈도 Unity WebGL에서 중요한 이슈입니다. 배포 사이즈는 다운로스 시간과 메모리 사용량에 영향을 미칩니다. 사용할만한 다운로드 속도가 나오려면 데이터를 압축한 상태로 전송해주어야 합니다. 현재로써는 http 프로토콜이 지원하는 gzip 압축에 의존하고 있습니다. 하지만, 이는 종종 서버 사이드의 작업이 필요로하기때문에 불편함이 따릅니다. 게다가, gzip은 현대의 압축 알고리즘에 비해 효율성이 떨어집니다.

미래에는(스케쥴상으로는 Unity 5.3), Unity 자체적으로 에셋 데이터 파일 압축을 모든 플랫폼에서 지원할 것입니다. http 압축에 의존해있던 것을 제거하고 자체적인 압축을 코드상으로 구현할 것입니다. 이로써 WebGL 콘텐츠를 더 빨리 받아볼 수 있게되고, 데이터가 메모리상에 압축된 상태로 머무르는 것이 가능해집니다. 이로 인해서 에셋 로딩 속도도 빨라지고 메모리 대역폭도 줄어들게 됩니다.


성능(Performance)

작년에 작성 한 WebGl 벤치마크 포스팅에서 브라우저와 네이티브 런타임의 성능 비교를 하였습니다. 어떤 영역에서는 괜챦은 성능을 보였었고, 어떤 영역에서는 훨씬 큰 성능 차이를 보여주었습니다. 우리는 이러한 성능 차이를 줄이고자합니다. 큰 성능 차이는 SIMD 및 멀티-스레딩(multi-threading)을 활용함으로써 줄일 수 있습니다. 애석하게도 현재 시점의 WebGL에서는 이들을 사용하는 것이 불가능하지만 다음과 같이 개선 될 예정입니다.

- SIMD : SIMD.js를 통해서 자바스크립트에서 SIMD를 지원할 수 있습니다. 모질라, 구글, 마이크로소프트 모두 이를 지원할 계획을 가지고 있습니다. 현재 다른 플랫폼들이 SIMD를 이용해서 퍼포먼스를 향상시키듯이 WebGL도 SIMD를 활용하면 퍼포먼스가 향상될 것입니다.

- 공유 배열 버퍼(Shared Array Buffers) : 공유 배열 버퍼(Shared Array Buffers)는 WebWorker(자바스크립트에서의 멀티스레드와 같은 역할)가 메모리를 공유할 수 있게 합니다. 이로 인해 기존 멀티스레드 코드를 자바스크립트로 컴파일하는 것이 가능해집니다. 모질라에서는 이미 Unity WebGL 콘텐츠를 멀티스레딩으로 돌리는 것에 성공하였고, 구글 역시 공유 배열 버퍼를 지원할 계획이라고 발표하였습니다.


모바일 지원

모바일에서 WebGL을 지원할 것이냐는 질문도 많이 받고 있습니다. 현재 우리는 모바일에서 구동하는데 방해가 되는 작업을 따로 하고 있지는 않지만, 모바일 최적화를 위한 작업도 따로 하고 있지는 않습니다. 때문에, 고성능의 최신 안드로이드 기기에서는 잘 돌아가겠지만 대부분의 보급형 기기에서는 그렇지가 않을 것입니다. 앞서 언급한 성능 향상 작업들이 모바일에서도 효과를 발휘한다고는 기대하지 않고 있습니다. 때문에, 모바일 지원에 대한 일정에 대해서는 말씀 드릴 것이 없는 상황입니다.


빌드 시간

또 다른 이슈로는 WebGL 빌드가 오래 걸린 다는 것이 있습니다. 모질라는 현재 엠스크립튼(Emscripten) 컴파일러 툴체인을 네이티브 코드로 옮기는 작업을 진행중입니다. 이를 통해서 빌드 시간이 상당히 개선될 것으로 기대하고 있습니다. 이미 Unity 5.1에서는 자바스크립트 최적화가 네이티브로 옮겨진 버젼의 엠스크립튼(Emscripten)이 탑재되서어 5.0에 비해 빌드 속도가 개선되었습니다.


오디오

다른 플랫폼들은 오디오 시스템을 FMOD를 이용하는 반면, 현재의 Unity WebGL은 Web Audio를 기반으로 자체적인 오디오 시스템을 구현하였습니다. 때문에, 현재로써는 기본적인 플레이백(playback)이나 볼륨 및 피치(pitch) 조절 등이 지원 될 뿐 그 이상의 고급 기능은 지원되지 않습니다. 이러한 상황은 Unity WebGL의 스레드 지원이 가능하기 전 까지는 변치 않을 것입니다. 스레드가 지원되면 FMOD 라이브러리를 WebGL로 컴파일 할 수 있게되고 원하는 모습에 가까워 질 수 있습니다. 하지만, Web Audio(“Audio Workers”)의 스펙인 오디오 데이터 워커 API 또한 필요합니다. 하지만 이 기능이 구현 된 브러우저는 아직 존재하지 않습니다. 따라서, 완전한 오디오 기능이 지원되려면 오랜 시간이 걸릴 것으로 예상합니다.


그래픽

WebGL은 OpenGL ES 2.0에 기반을 두고 있는 자바스크립트 API입니다. OpenGL ES 2.0은 많은 제약 사항이 있기 때문에 다른 플랫폼에 비해 제한된 그래픽 기능을 가지고 있음을 의미합니다. 또한, 유니티는 현재 어떤 그래픽 API에서 어떤 그래픽 기능을 사용하는 지에 대해 결정하는 부분이 하드코딩으로 되어있습니다. 이 과정 중에서 OpenGL ES 2.0은 모바일에서 돌아간다고 가정하고 있습니다. 하지만 WebGL은 고성능 데스크톱 GPU에서 구동될 수가 있으므로 이러한 가정은 더 이상 유효하지가 않습니다. 이로 인해 원래 가능한 것 보다는 시각적인 퀄리티가 떨어지는 결과를 초래합니다. 특히 스탠다드 쉐이더와 그림자등이 대표적인 예가 될 것입니다. 우리는 이러한 하드코딩을 걷어내고 쉐이더 품질 등을 프로젝트 별 설정할 수 있는 기능을 만들고 있습니다.

또한, GDC 2015에서 우리는 WebGL 2.0(OpenGL ES 3.0 기반)에서 돌아가는 Unity5의 프로토타입을 시연한 바 있습니다. 이는 WebGL의 그래픽 성능을 한 단계 끌어올린 것입니다. Unity 5.2에서는 WebGL 2.0 지원이 실험적으로 적용될 것입니다. 다만, 브라우저들이 실제적으로 이 API를 올해 안에는 릴리즈 버전에 포함하지는 않을 것으로 생각합니다.


브라우저 지원

현재로써는, Unity WebGL은 크롬, 파이어폭스, 사파리를 지원합니다. 주요 브라우저 중 마이크로소프트의 브라우저는 제외 된 상태입니다. 인터넷 익스플로러의 현재 버젼이 WebGL을 지원하긴 하지만 Web Audio에 대한 지원이 빠져있습니다. 또한, 성능도 썩 좋지 않다보니 우리의 공식 지원 대상에서 제외되었습니다.

마이크로소트의 새로운 브라우저인 Edge에서는 이러한 점이 개선됩니다. Edge는 IE를 대체하여 Windows10에 기본 브라우저로 탑재됩니다. Edge에서는 Web Audio가 탑재되고 asm.js가 지원되어서 높은 성능으로 Unity 콘텐츠를 구동시킬 수 있습니다.


비디오

Unity의 MovieTexture 클래스는 현재 WebGL에서 지원되지 않습니다. MovieTexture는 현재 WebGL의 오디오 솔루션에서 오디오 플레이백이 불가능한 관계로 현재로써는 이에 대한 계획이 없는 상태입니다. 게다가, 브라우저의 html5 비디오 기능을 이용하면 완벽한 비디오 텍스쳐 솔루션을 Unity WebGL에서 손쉽게 이용 가능합니다.


네트워킹

현재 System.IO.Sockets.*과 UnityEngine.Network.*는 WebGL에서 동작하지 않으며 앞으로도 마찬가지 일 것입니다. 이는 플랫폼에서 보안상의 문제로 IP 소켓에 직접 접근하는것이 불가능하기 때문입니다. 대신, WWW는 이용 가능합니다. 또한, 자바스크립트를 이용하여 Web Socket이나 WebRTC를 통합하는 방법도 있습니다. 아니면, Unity 5.1부터 내장되어있는 멀티플레이어 기능을 활용할 수도 있고, 포톤(Photon)이나 스마트폭스서버(SmartFoxServer)같은 서드 파티 라이브러리를 활용하는 방법도 있습니다. 이들 모두 WebGL에서 WebSocket을 이용합니다.


쓰레드

앞서 성능 섹션에서도 언급하였듯이, 브라우저가 공유배열버퍼(Shared Array Buffer)기능을 지원하게되면 우리는 내부 엔진 코드에 멀티 스레딩을 적용할 예정입니다. 또한, 최종적으로는 사용자 System.Threading.*등을 이용하여 사용자 코드에서 멀티스레딩을 활용할 수 있도록 하는 것이 우리의 목표입니다. 하지만, 공유배열버퍼(Shared Array Buffer)는 GC가 필요한 일부 기능들을 제공하지 않는 등 꽤 까다로운 문제들이 있습니다. 우리는 이 문제를 풀기위한 고민을 계속 하고 있으며 언젠가는 기능이 구현 될 것입니다. 다만, 엔진 내부에 멀티스레딩이 적용 된 이후에나 될 것입니다.



Posted by ozlael
,