오즈라엘

들어가며

유니티에서 안드로이드 타겟으로 개발하면 텍스쳐 압축을 ETC로 사용하게 됩니다. 기존에는 텍스쳐의 기본 압축 포맷이 ETC1이였는데, 최근 5.2.0부터는 RGBA 텍스쳐의 압축 포맷이 ETC2.0으로 바뀌게 되었습니다. 텍스쳐 포맷을 compressed로 두면 내부적으로는 ETC2를 사용하도록 되는 것입니다. 그래서 그런지 ETC 포맷에 관한 문의가 빈번하게 들어오고 있습니다. 그래서, 잘 오해할 수 있는 부분을 정리해드리고자 합니다.

Open GL ES 버전 & ECT 포맷 버전

ETC2 압축 포맷은 ETC1가 확장 및 개선된 포맷입니다. 때문에, 가능하다면 ETC1보다는 ETC2를 사용하는 것이 당연히 좋습니다. (참고로, DXT1, DTX3, DXT5는 이야기가 다릅니다. 서로 품질과 크기의 조율 선택 사항입니다.) 다만 문제는 ETC2는 Open GL ES 3.0 이상에서만 지원됩니다. 갤럭시 S3 이하 등의 구형 기종에서는 Open GL ES 2.0으로 돌아가기 때문에 ETC2를 사용하는 것이 불가능합니다.

Open GL ES 2.0 기기에서의 ETC2 사용

하지만 막상 유니티에서 텍스쳐 포맷을 ETC2로 두고 Open GS ES 2.0 기기에서 구동을 해봐도 텍스쳐가 정상적으로 그려집니다. ETC2가 Open GL ES 2.0에서는 지원이 되지 않기때문에 텍스쳐가 그려지지 않아야 될 것으로 생각되서 혼란스러우실 수도 있겟습니다. 

이미지 출처 : http://chulin28ho.tistory.com/

사실, 기기에서 지원되지 않는 텍스쳐 압축을 사용하는 경우, 텍스처는 비압축 RGBA 32 형식으로 압축된 텍스처와 함께 메모리에 저장됩니다. 따라서 이러한 경우에는 텍스처 압축을 푸는 만큼 불필요한 계산 시간이 발생하게 되며 메모리 공간도 두 배로 필요해집니다. 이것 또한 렌더링 성능에 심각한 악영향을 미칩니다.

설명이 좀 애매하긴 한데 예를 들자면, OpenGL ES 2.0 기기에 ETC2 포맷을 사용하면 작동하는데에는 문제가 없지만 성능상 효율이 떨어지게 됩니다. 왜냐하면 ES 2.0 기기는 ETC2를 지원하지 않기 때문에 32비트x폭x높이 + 원래의 ETC2 사이즈 만큼의 메모리가 늘어나서 압축 지원도 못받으면서 메모리만 늘어나게 되기 때문입니다. 또한 로딩 타임에 텍스쳐를 소프트웨어적으로 압축을 푸는 시간도 추가됩니다.

ETC2의 ETC1 하위 호환성

ETC2는 ETC1의 하위 호환성을 보유하고 있습니다. 때문에 Open GL ES 2.0에서도 ETC2를 읽을 수 있는 것으로 알고 계시는 분도 간혹 계십니다. 충분히 오해할만 하지만, ETC2가 ETC1 하위 호환을 포함한다는 것은 기기에서 ETC1을 ETC2처럼 취급할 수 있다는 것일 뿐입니다. 앞서 말씀드린대로 유니티에서는 ETC2를 ES2.0 기기에서 올리면 23bit RGBA로 사용됩니다. 

알파 유무의 차이

안드로이드 텍스쳐 압축의 기본 값이 ETC2 로 바뀌었습니다만 모든 텍스쳐가 ETC2로 기본 설정 되는 것은 아닙니다. ETC2가 기본이 되는 것은 RGBA 텍스쳐(즉, 알파를 포함하는)입니다. ETC2는 ETC1과는 달리 알파 채널을 포함할 수 있기 때문입니다. RGB만 존재하는(즉, 알파채널이 없는) 텍스쳐의 기본 압축 포맷은 여전히 ETC1입니다. RGB 텍스쳐를 ETC로 사용하기를 원하시면 Texture Type을 Advanced 로 변경 후 Format 설정을 바꿔주셔야 합니다. 

릴리즈 노트에서 언급한 포맷 기본값이 바뀌었다는 내용은 RGBA 텍스쳐에 해당하는 내용입니다. 기존에는 16bit RGBA였는데 이 것이 ETC2로 바뀌었다는 것입니다. 릴리즈 노트가 부실해서 충분히 오해의 소지가 있을 것 같습니다. (아직 매뉴얼 페이지에는 이 내용이 갱신되지 않은 것 같습니다. 사람 사는데가 다 똑같죠 뭐 헤헤 양해좀 굽신굽신)

Open GL ES 2.0에서의 RGBA 텍스쳐

하지만 그렇다고 Open GL ES 2.0에서 RGBA 텍스쳐를 사용하려면 RGBA 16비트 혹은 RGBA32비트만 사용하여야 하는 것은 아닙니다. Compress using ETC1(split alpha channel)을 선택하면 원본의 RGBA가 유니티 내부적으로 두 개의 ETC1으로 갈라서 하나는 RGB, 다른 하나는 알파 채널 정보를 담는게됩니다. 그럼으로써 ETC2를 사용하지 않고도 알파 채널을 사용할 수 있는 꼼수를 부립니다.

다만, 이렇게 되면 실제로는 2 개의 텍스쳐 슬롯이므로 쉐이더에서도 텍스쳐 레지스터를 두 개를 차지하게 됩니다. 예를 들자면 내장(bult-in)쉐이더 중 Sprite-Diffuse.shader를 살펴보면 다음과 같이 메인 텍스쳐를 읽은 뒤 _AlphaSplitEnabled 조건이라면 알파 채널을 별도로 한번 더 읽는 것을 확인 가능합니다.

단, 이 기능은 현재 릴리즈된 버전에는 스프라이트에 쓰이는 경우에만 작동하고 있으며 차츰 사용처를 확대해나가는 작업이 진행 중입니다.

ETC1이냐 ETC2냐 그것이 문제로다

“어쩌라는거야 그럼 ETC1 쓰라는거야 ETC2 쓰라는거야?” 이쯤 되면 이러한 질문이 나오시게 될 것입니다 :) 저도 사실 여기에 대한 명쾌한 답변을 드릴 수는 없습니다. ES 3.0지원 기기의 점유율이 증가하고 있는 추세긴 하지만 아직까지는 ES 2.0 지원 기기들의 점유율이 더 높은 상태기 때문입니다. (RGB 텍스쳐의 압축 기본 포맷은 ETC1으로 유지하는 이유이기도 합니다.) 이는 유니티 하드웨어 스탯 사이트에서 확인 가능합니다. 

다만, ETC2를 사용하면 그 만큼 더 메모리를 절약하고 더 높은 퀄리티를 낼 수 있는 것은 자명한 일입니다. 때문에 제 개인적인 생각으로는 주 타켓 기기를 무엇으로 삼냐에 따라 선택을 달리해야 할 것 같습니다. 물론, 보급형 기기를 타겟으로 하는 가벼운 게임이라면 ETC1을 포기해서는 안될 것입니다. 하지만, 고퀄리티 고성능 기기 게임이라면 ETC2를 사용하고 ES 2.0 기종에서는 낭비되는 메모리만큼 다른 부분에서의 품질을 과감히 포기하는 방향도 그리 나쁜 선택만은 아닐 것입니다. 참고로, SystemInfo.graphicsDeviceVersion를 통해 ES 버전을 확인 가능하고 QualitySettings.SetQualityLevel를 통해서 퀄리티 변경이 가능합니다.

더 많은 내용은 "유니티 그래픽스 최적화 스타트업"을 참고하세요

들어가며

물리기반렌더링( Physically based rendering, PBR, Physically based shading, PBS, 이하 PBR, PBS)이라는 키워드가 떠오른 것은 꽤 오래 되었고 이미 PC나 콘솔에서는 널리 적용되었습니다. 최근 출시한 메탈기어솔리드5는 그 정점을 보여주고 있습니다.

하지만, 모바일이 주력 시장인 국내 게임 시장에서는 관심 밖이였지요. 하지만 최근들어 국내에서도 PBR에 대한 관심이 많아지고 있습니다. 이러한 관심의 가장 큰 이유는 모바일 하드웨어의 성능 발전일 것입니다. PBR이 기본적으로 소모하는 비용을 충분히 감당한 만큼의 성능을 내는 기기들이 보편화 되고 있는 것입니다. 비단 최신 기종이 아니더라도 캐릭터에게만 PBS를 사용하는 등 부분적으로만 사용하여 성능을 절약할 수도 있습니다. 하지만, PBS 쉐이더를 사용하지 않고도 PBS 느낌을 낼 수 있다면 더욱 많은 성능을 절약할 수 있을것입니다. 물론, 초실사 렌더링을 지향하는 게임이라면 100% PBS로 렌더링을 해야겠지요. 하지만 대부분의 모바일 게임들은 그렇지가 않습니다. 근래의 모바일 게임에서 PBS사용하고자 함은 좀 더 멋진 그래픽을 표현하고자 함이 주 목적일일 뿐이지 꼭 물리적으로 정확한 그래픽을 표현하고자 함이 주 목적은 아니라고 생각합니다. 특히, 그 초점은 금속 재질 표현에 맞춰져 있습니다. 비 금속 재질보다는 금속 재질에 촛점을 맞춰서 금속 부분과 금속이 아닌 부분을 함께 표현하고자 함이 목적인 것으로 생각됩니다. 

이러한 관점을 기준으로 느낌을 내는 쉐이더를 만져보보았습니다. 그 결과물인 PBR 대응 머티리얼 텍스쳐들을 그대로 사용하는 가벼운 쉐이더를 소개해드릴까 합니다. MatCap 쉐이더에 Metallic factor를 적용해서 PBS같은 느낌을 내는 방식입니다. 다음 스크린샷 이미지에서 렌더링 되고 있는 케릭터와 발판은 PBR 대응으로 만들어진 텍스쳐들을 그대로 사용하고 있으며 실시간 라이팅이 아닌 MatCap 텍스쳐 기반으로 처리되어있습니다. 데모를 구글 플레이스토어에 올려놓았으므로 기기에 설치하여 확인해보실 수 있습니다. 

다운로드 링크 : https://play.google.com/store/apps/details?id=com.ozproject.demo1

MatCap 쉐이더

우선, MatCap 쉐이더를 기반으로 하고 있으므로 MatCap 쉐이더에 대해 간략하게 설명을 드리도록 하겠습니다. MatCap 쉐이더는 모바일에서 유용하게 사용할 수 있는 이미지 기반 라이팅 중 하나입니다. MatCap은 Material Capture의 약자인데, Material Capture는 현실 세계의 라이팅을 수집해서 캡쳐하기 위한 구체를 의미합니다. 보통 CG 영상이나 이미지에서 실사 렌더링을 위한 라이팅 참고 자료로 사용하기 위한 용도로 만들어집니다.

MatCap 쉐이더는 이러한 Material Capture를 그대로 텍스쳐(이를 MatCap 텍스쳐라 부릅니다)로 만들어서 라이팅 결과로 활용하는 것입니다. 이를 이용하면 재질에 따른 라이팅을 미리 텍스쳐로 만들어놓기 때문에 실시간으로 라이팅 연산을 않고도 실사적인 라이팅을 처리할 수 있습니다. 

출처 : https://shaderforge.userecho.com/topic/416166-it_matrix/

MatCap 쉐이더는 유니티에 내장된 쉐이더는 아니지만 구글링이나 유니티 에셋스토어에서 쉽게 구할 수 있습니다. 이 글에서 소개하고자 하는 쉐이더는 에셋스토어에 있는 MatCap 쉐이더를 기반으로 작업하였습니다. 쉐이더 링크 : https://www.assetstore.unity3d.com/en/#!/content/8221

Metallic

PBS에서의 특징중 하나는 금속과 비금속을 수치로 표현하는 것입니다. 빛이 사물에 닿으면 일부는 흡수되었다가 방출되고 나머지는 바로 반사되 튕겨나갑니다. 이 중 흡수되었다가 방출출되는 빛이 일반적으로 말하는 디퓨즈 영역이고 바로 튕겨나가는 빛이 일반적으로 말하는 스페큘라 영역이 되는 것입니다.

금속은 빛이 닿으면 이러한 디퓨즈 영역이 없이 완전 반사가 일어납니다. 즉, 표면이 금속에 가까울수록 반사의 비중이 높고 금속이 아닌 비전도체에 가까울 수록 디퓨즈의 비중이 높아집니다. 

이미지 출처 : http://docs.unity3d.com/kr/current/Manual/StandardShaderMaterialCharts.html

PBS 머리티얼에서는 이를 반영하여 얼마나 금속에 가까운지의 정도를 나타내는 Metallic 텍스쳐를 사용합니다.

기존의 MatCap 쉐이더는 MatCap 텍스쳐를 한 장만 사용합니다. 이를 Metallic 텍스쳐를 사용하기 위해서 MatCap 텍스쳐를 두 장을 사용하도록 변경해줍니다. 금속성이 0인 경우의 MatCap 텍스쳐와 완전 금속인 경우의 MatCap 두 개의 MatCap을 사용하여 Metallic에 따라 비중을 반영해주면 되는 것입니다. 

파라미터

또한, AO맵 역시 반영해주어야합니다. AO는 빛이 차폐되는 정도를 나타내주는 것이므로 라이팅 연산 최종 단계에서 곱해주는 것으로 간단히 처리 해주면 됩니다. Emissive는 발광하는 부분이므로 라이팅 연산 최종 단계에서 더해주는 것으로 간단히 처리 해주면 됩니다. 최종적인 파라미터들은 다음과 같습니다.

코드

쉐이더 코드는 다음과 같습니다. 데모에 쓰인 리소스는 에셋스토어에서 유료로 판매되고 있는 리소스이므로 프로젝트를 공유드리지 못하는 점 양해 바랍니다. 

한계

간단한 쉐이더다보니 많은 한계점을 가지고있습니다. 보시다시피 이는 정확한 PBS는 아닙니다. 많은 부분들이 생략되어 있고 라이팅 재질 느낌은 전적으로 MatCap 텍스쳐에 의지하고 있습니다. 때문에, MatCap 텍스쳐를 어떤 것으로 사용하느냐에 따라 품질이 크게 좌우됩니다. 또한, 씬 별로 라이팅이 다르다면 씬 별로 MatCap 텍스쳐를 만들어 줘야 합니다. MatCap 텍스쳐를 어떻게 만드냐에 따라 결과가 달라질 것입니다. 

MatCap 방식은 한 쪽에서 바라보는 라이팅만 표현이 가능하기 때문에 카메라 각도가 고정되어 있는 경우에만 유효하다는 제약이 있습니다.그러나, 대부분의 모바일 게임들은 탑 뷰(Top View), 쿼터 뷰(Quarter View), 백 뷰(Back View) 등 카메라의 방향이 고정된 채로 게임이 진행되는 경우가 대부분이므로 모바일서는 큰 제약 사항이 되지는 않을 것입니다.

Unity 5.3 릴리즈는 WebGL를 지원하는 네번째 버전입니다. 5.0에서부터 WebGL을 프리뷰(Preview)로 처음 탑재하고 난 이후에 수 많은 사항들이 개선되어 왔습니다. 몇 가지 사항들을 공유드리고자 합니다. 이 글은 유니티 공식 블로그의 UNITY 5.3 WEBGL UPDATES를 번역 및 요약한 글입니다. 정확한 내용을 원하신다면 원문을 읽어보시길 바랍니다.

5.3에서의 바뀐 점

• WebGL에서 스탠다드쉐이더가 데스크탑 퀄리티의 리플렉션을 사용합니다. 기존에는 유니티 WebGL은 OpenGL 2.0을 사용하는 모바일용으로 간략화된 버전의 스탠다드 쉐이더를 사용했었습니다. 이제는 데스크톱과 동일한 리플렉션을 사용하여 고품질의 재질 결과를 표현해줍니다.
• 부드러운 그림자(Soft Shadow)를 지원합니다.
• 귀하의 서버가 설정이 되어 있지 않더라도 유니티 WebGL은 압축을 지원합니다.기존에는 WebGL은 gzip 압축된 파일을 제공하기 위해서는 서버에 셋팅이 필요했습니다. 그렇지 않으면 압축되지 않은 데이터를 사용하여 긴 시간의 다운로드가 필요했습니다. 하지만 이제는 유니티의 WebGL은 자동적으로 gzip 압축된 데이터를 제공합니다. 이는 클라이언트단의 자바스크립트에서 압축 해제를 수행합니다. 이로 인해 압축 처리 딜레이가 조금 발생하긴 하지만 거대한 다운로드 시간을 피할 수 있습니다. 배포 사이즈에 대한 자세한 내용은 이 문서를 참고 바랍니다.
• 데이터 파일이 LZ4 압축 상태로 메모리에 존재합니다. 유니티 5.3에서는 에셋 데이터가 메모리에 LZ4 압축된 상태로 메모리에 올라갑니다. 에셋이 로드 될 때에만 압축이 해제됩니다. 이는 에셋 데이터가 적은 메모리를 차지해서 메모리 낭비될 일이 적어짐을 의미합니다.
• WebGL 빌드 파일을 다른 url로 이전하는 것이 쉬워졌습니다. 빌드 프로세스 과정에서 생성되는 파일들은 index.html에 의해 참조됩니다. 이로인해 빌드 데이터를 외부 호스팅 솔루션으로 배치하는 것이 쉬워졌습니다. 빌드 아웃풋 파일 이전의 자세한 내용은 이 문서를 참고 바랍니다.
• 웹캠을 지원합니다. 5.3에 WebCamTexture 클래스가 추가되었습니다. 이는 getUserMedia API를 지원하는 브라우저에서 사용 가능합니다. 
• WebGL이 유니티 클라우드 빌드가 가능합니다.
• 문서들을 개선하였습니다. 5.3을 위해서 WebGL 문서가 대폭 개선되어 많은 정보들이 추가되었습니다.
• 수 많은 버그들이 수정되었습니다. 5.3에서는 5.2에 비해 28개의 WebGL 버그가 수정되었습니다. 외에도 WebGL에서 간접적으로 영향을 주는 수 많은 버그들이 수정되었습니다. 또한, 5.2.x 패치 릴리즈 사이클 동안 수정된 WebGL 버그 수정 사항들이 포함되어 있습니다.

WebGL이 공식 지원 타겟이 되었습니다.

WebGL은 공식 지원하지 않는 프리뷰(Preview) 상태였습니다. 5.3부터는 WebGL에서 프리뷰 레이블을 제거하고 공식 지원 대상이 되었습니다. 따라서, 프리미엄 서포트 및 엔터프라이즈 서포트는 WebGL을 커버합니다.

5.0에서 WebGL이 탑재되고나서 5.3까지 오면서 시간이 꽤 지났고 시간이 지날 수록 브라우저 기술도 발전해왔습니다. 예를 들어 마이크로소프트는 새로운 브라우저인 엣지를 윈도우즈10에 탑재하고, 이 브라우저는 asm.js를 지원함으로써 익스플로러 11에서는 불가능했던 컨텐츠들을 지원할 수 있게 되었습니다. 

그간 WebGL이 많은 개선이 되었긴 했지만 갑자기 모든 기능들이 WebGL에서 잘 동작한다는 의미는 아닙니다. 또한, 네이티브 빌드만큼의 성능이 나온다거나 모든 브라우저에서 아무 문제 없이 동작한다는 것은 아닙니다. 시간이 지남에 따라 개선은 계속 이루어 질 것이며 지금 시점에서는 공식 지원을 시작하기 적절한 시기인 것으로 판단한 것입니다. 현재의 작업 상태와 제한 상황을 문서에 명시하였으므로 이를 참고 바랍니다.

브라우저 제조사들과의 작업

유니티의 WebGL은 브라우저가 제공하는 웹 기술에 의존적일 수 밖에 없습니다. 주요 브라우저 제조사들과 긴밀하게 작업을 하고 있으며, 이들은 빠른 속도로 기술을 발전시키고 있습니다. 모질라의 파이어폭스, 마이크로 소프트의 엣지, 구글의 크롬 등의 주요 브라우저들과 유니티의 호환 작업이 지속적으로 이루어지고 있어서 빠른 속도로 개선이 되고 있습니다.

시도해보세요!

WebGL로의 익스포트는 웹 게이밍의 미래라고 믿고 있습니다. 귀하의 게임을 유니티의 WebGL로 배포해보십시요. Heroes Of Paragon, Spider Box, Big Buck Hunter 등 이미 몇 개의 사례들이 있습니다. (역주 : 씨발 애석하게도 이 예시들의 게임은 망할 게등위(게임산업진흥에관한법률)때문에 국내에서는 플레이가 불가능합니다.) 시작하기 위해서는 다음 절차를 따르십시요. 

• 5.3 설치
• WebGL 문서를 참고
• WebGL 포럼에서 질문과 피드백

쉐이더를 작성하다보면 텍스쳐를 많이 사용하는 기능을 만들 때도 있습니다. 대표적인게 바로 지형 스플래팅이죠. (유니티의 터레인은 아무도 쓰지 않는다는 슬픈 전설이...) 스플래팅의 개념을 모르시는 분든을 위해서 간략히 설명 드리자면, 스플래팅은 여러 텍스쳐를 서로 블렌딩해서 표현해주는 방식을 뜻합니다. 이렇게 하게 되면 작은 크기의 텍스쳐들을 가지고도 넓은 지역을 표현해줄 수가 있어서 텍스쳐 메모리를 상당히 절약할 수 있게 됩니다. 

이미지 출처 : http://blog.naver.com/sorkelf/40151055590

예전에 GPU의 쉐이더 성능이 좋지 않은 시절에는 이러한 스플래팅을 처리하기위해 여러번 덧그리는 멀티 패스로 구현해야만 했습니다. 하지만 요즘은 쉐이더에서 여러장의 텍스쳐를 한번에 읽어서 싱글 패스로 처리할 수가 있습니다. 하지만 문제는 쉐이더에서 한번에 읽을 수 있는 텍스쳐의 갯수가 제한 되어 있다는 것입니다. 만일 쉐이더에서 너무 많은 쉐이더를 샘플링 하면 원하는대로 작동하지 않게 됩니다. 근데, 이 현상이 인지하기 쉽지도 않습니다. 쉐이더 컴파일 오류가 나는 것 도 아니고 오브젝트가 보라색으로 칠해지는 것 도 아니도 그냥 몇 개의 텍스쳐가 읽히지 않고 무시되어 버립니다. 이러한 현상은 OpenGL에서 제한하는 텍스쳐 수가 다르기 때문입니다. OpenGL 공식 스펙에 이러한 숫자가 정해져 있긴 하지만 디바이스마다도 또한 차이가 발생합니다. 때문에컴파일 단계에서 이러한 제한을 탐지할 방법이 없습니다. 그러다보니 실제 렌더링 과정에서 텍스쳐 샘플링 갯수 제한을 넘게 되면 더 이상의 텍스쳐 샘플링은 무시가 되고 렌더링이 되는 것입니다.

OpenGL에서 쉐이더에서 한번에 샘플링 할 수 있는 텍스쳐 갯수는 MAX_TEXTURE_IMAGE_UNITS로 정의 되어 있습니다. (유니티에서 확인해볼 수 있는 수치는 아닙니다.)이를 문서에서 확인해보면 ES2는 8, ES3에서는 16으로 나옵니다. 즉, OpenGL ES2에서는 쉐이더에서 한번에 최대 8개의 텍스쳐를 사용할 수 있고, OpenGL ES3에서는 쉐이더에서 한번에 최대 16개의 텍스쳐를 샘플링 할 수 있다는 말이 됩니다. (물론 이 값은 특정 디바이스에서는 다른 값일 수도 있습니다.)

이미지 출처 : iOS 개발자 라이브러리

그렇다고 쉐이더이 인스펙터에 텍스쳐 슬롯을 8개 만들면 정상적으로 쓸 수 있다는 말은 또 아닙니다. 유니티는 서피스 쉐이더로 작성하고나면 유니티는 자동적으로 추가적인 정보들을 처리해줍니다. 그러는 과정에서 유니티에서 사용하는 텍스쳐가 추가적으로 쓰일 수 있습니다. 이는 쉐이더의 variant에 따라서 다르므로 완성된 코드를 확인하여야 합니다. 쉐이터를 선택 후 인스펙터에서 Compile and show code를 선택합니다. 

게임 그래픽에서 반사의 표현은 매우 중요한 시각적 요소 중 하나입니다. 주변 환경의 반사를 표현함으로써 금속 재질을 처리할 수 있기 때문입니다. 판타지물의 투구라든가 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의 느낌적인 느낌을 내기에는 적당하지 않나 싶습니다 :)