개발일지_009(언리얼엔진)_더 나은 3D메시 만들기3[머티리얼 개념들]

■PBR

PBR은 Physical Based Rendering 즉 물리 기반 렌더링의 약자이다.

물리 기반 렌더링이란? 빛의 실제 작용을 추적하는 것

PBR을 사용하면 물리 기반의 머티리얼이 모든 라이팅 시나리오에서 똑같이 잘 작동한다는 점이다.

머티리얼이 스튜디오 안의 밝은 빛 아래에서 보이든 바깥에서 보이든 물 속에서 보이든 우주 밖에서 보이든 상관없이 라이팅에 정확히 똑같은 방식으로 반으한다.

즉, 특정한 오브젝트가 보이는 라이팅 시나리오 별로 머티리얼 또는 텍스처를 다양한 버전으로 만들 필요가 없다는 뜻이다.

또한 머티리얼도 평소처럼 복잡해질 필요가 없다.

원래 필요했던 머티리얼 인스트럭션 수를 많이 간소화할 수 있다.

또한 사용하는 머티리얼 값은 훨씬 덜 복잡하고 상호 의존적이라 결과적으로 아티스트들이 더 직관적으로 조정할 수 있다.

물리 기반 렌더링은 단순히 극사실적인 렌더링을 돕거나 정말 사실적인 이미지에만 사용할 수 있는 것이 아닌 만화 기반 이미지에도 사용 가능하다.

사실 물리 기반 렌더링 시스템은 비실사 렌더링 스타일로 유명한 Pixar와 Disney에서도 작업 기반이 되었다.

PBR을 사용해야 하는 이유는 아트 프로덕션 파이프라인의 통일에 도움이 되기 때문이다.

 

애셋 하나만 있어도 어떤 유형의라이팅을 받든 정확히 똑같은 방식으로 라이팅에 반응을 하므로 아트 프로덕션 파이프라인의 통일의 큰 도움이 된다.

즉 PBR을 사용하면 라이팅 유형 별로 다수의 머티리얼이나 텍스처를 만들 필요가 없다.

 

■머티리얼 도메인

머티리얼 도메인은 머티리얼 어트리뷰트가 평가되는 방식이다.

블렌드 모드는 머티리얼의 색깔과 배경과 블렌딩 되는 방식을 결정하며, 셰이딩 모델은 입력이 합쳐져 머티리얼의 최종 색을 만드는 방식을 결정한다.

예를 들어 유리를 만들고 싶으면 블렌드 모드를 Transparent로, 셰이딩 모델은 Unlit 또는 Default Lit로 바꾸면 유리의 빛에 대한 반응 방식을 바꿀 수 있다.

모든 프로젝트에는 다양한 도메인, 블렌드와 셰이딩 조합을 사용하는 머티리얼이 있을 거다.

단 하나의 조합만으로 머티리얼에 따른 필요를 모두 만족시킬 수는 없다.

각각다양한 조합이 포함된 머티리얼을 다수 만들어야 할 거다.

단 하나의 머티리얼 도메인, 블렌드 그리고 셰이딩 모델의 조합만으로 프로젝트의 모든 필요를 만조시킬 수 없다는 점을 명심해라.

아마 다양한 필요를 만족시키기 위해서는 다양한 버전의 머티리얼을 만들어야 할거다.

또하나는 머티리얼 도메인, 블렌드, 셰이딩 모델은 런타임에 바꿀 수 없다는 점이다.

만약 '게임이 실행이되면 머티리얼을 유리 머티리얼로 바꿔야지'라는 생각은 불가능하다.

 

■머티리얼이란?

머티리얼이란 언리얼엔진의 오브젝트 상 텍스처의 표시 방식을 돕거나 조작하는 수단이다.

머티리얼은 HLSL 코드의 작은 블록들로 구성이 되며 HLSL은 (High Level Shader Language)고급 셰이더 언어라는 뜻이다.

머티리얼은 먼저 컴파일이 되어야 게임에서 사용되거나 표시될 수 있다.

머티리얼을 컴파일 하려면 적용 버튼을 누르거나 저장하면 컴파일이 된다.

컴파일이 되면 스태틱이 되어 프로젝트 실행 중에는 변경할 수 없다.

하지만 하나의 머티리얼로 프로젝트 전체의 온갖 다양한 머티리얼에 적용할 수 있는 기능도 있다.

 

■머티리얼 인스턴스

방금 전에 머티리얼은 실행 중에 변경할 수 없다고 했다.

즉, 머티리얼의 색상을 바꾸고 싶거나 머티리얼에 사용된 텍스처를 바꾸고 싶어도 그럴 수 없다는 뜻이다.

하지만 그건 별로 간편해보이지 않으며 특히 게임같은 역동적인 환경에서는 더더욱 그렇다.

이 때 머티리얼 인스턴스가 유용하다.

머티리얼 인스턴스는 머티리얼의 특별한 버전으로 머티리얼을 리컴파일 할 필요 없이 머티리얼에 포함된 값과 텍스처를 실행하는 중에도 바꿀 수 있게 해준다.

덕분에 머티리얼 인스턴스는 반복처리를 정말 빠르게 해주기에 변화가 거의 실시간으로 이루어지는 것을 볼 수 있다.

또한 타임라인과 블루프린트로부터 머티리얼 인스턴스와 상호작용해 정말 다양하고 멋진 애니메이션 효과를 얻을 수 있다.

머티리얼 인스턴스를 사용할 때는 성능 면에서도 아주 약간의 이점이 있다.

하지만 이것은 머티리얼과 머티리얼 인스턴스의 각각 수천 개 단위로 사용하여 비교했을 때나 체감이 된다.

머티리얼 인스턴스의 주요요소는 바로 유연성이다.

아티스트가 프로젝트에서 누릴 수 있는 유연성.

머티리얼 인스턴스의 다양하고 수많은 파라미터를 사용해 마스터 머티리얼을 구성하면 아티스트들은 굳이 복잡한 셰이더 코드를 다수 개발할 필요 없이 머티리얼을 마음대로 미세조정할 수 있다.

 

■마스터 머티리얼

마스터 머티리얼은 많은 역할을 하도록 구성할 수 있는 머티리얼이다.

위의 이미지가 마스터 머티리얼의 예인데 수많은 파라미터가 있다.

예를 들어 Base Color라는 벡터 파라미터는 머티리얼 인스턴스 안에서 색 선택 툴을 사용해서 원하는 색이 무엇이든 그 색으로 설정할 수 있다.

또 다른 파라미터 노드는 Texture Parameter는 머티리얼 인스턴스에 원하는 텍스처는 무엇이든 보충할 수 있게 해주어서 외형을 완전히 바꿀 수 있다.

또한 스칼라 파라미터는 스칼라 변수를 제어한다.

즉, 인스턴스의 파라미터 값을 바꿀 수 있게 해주어서 머티리얼 인스턴스의 특정 이펙트를 늘리거나 줄일 수 있다.

머티리얼 인스턴스를 통해 조작할 수 있는 항목을 찾는다면 머티리얼 파라미터 노드를 찾게 될 것이다.

머티리얼 파라미터 노드를 추가할 수 있는 방법은 다양하며 심지어 기존 노드를 머티리얼 파라미터 노드로 변환할 수도 있다.

 

■마스터 머티리얼로 해도 되는 것과 안되는 것

다수의 마스터 머티리얼은 사용해도 된다.

모든 오브젝트에 작용하는 단 하나의 마스터 머티리얼을 만드는 건 하면 안된다.

애초에 불가능할 뿐만 아니라 머티리얼을 부풀려서 성능 문제를 일으킬 수도 있다.

이 때는 불투명 환경 오브젝트용 마스터 머티리얼과 반투명 오브젝트용 머티리얼을 따로 두어야 한다.

또한 캐릭터용 마스터와 무기용 마스터를 따로 두어야 한다.

게임 속 모든 필요에 맞춰서 사용할 단 하나의 마스터 머티리얼을 두려고 하지마라.

그냥 가능하지 않다고 생각하자.

마지막으로 마스터 머티리얼을 만들 때는 아마 아티스트들에게 유용할 거라고 지레짐작을 하면 안된다.

직접 대화하고 그들이 가장 자주 사용할 파라미터가 무엇인지 마스터머티리얼에 두면 아티스트들은 자기가 가장 유용하게 사용할 파라미터를 미세조정 하기만 하면된다.

이런 방법을 통해 사용되지도 않고 프로젝트를 부풀릴 셰이더로직에 필요한 유지보수를 많이 줄 일 수 있다.

이러면 개발자들도 머티리얼에 무슨일이 벌어지는지 더 쉽게 이해할 수 있다.

아무도 사용하지 않는 파라미터가 무더기로 있다면 비효율적이다.

 

■마스터 머티리얼 개념

마스터 머티리얼을 만들때 머티리얼의 좋은 퍼포먼스 뿐만 아니라 자신이 목표로 한 모든 플랫폼에서 작동을 확실히 보장하기 위해서 할 몇 가지가 있다.

 

머티리얼 함수

머티리얼 그래프의 일부를 공유하고 재사용할 수 있습니다.

머티리얼 그래프의 일부를 공유하고 재활용할 수 있게 해준다. 언리얼 엔진은 실제로 수많은 내장 머티리얼 함수가 있어서 오브젝트의 월드 위치를 결정하는 것부터 화면상 마우스의 좌표 위치 파악까지 알아낸다.

내장 머티리얼 함수 중에는 자신도 미처 모르는 사이에 이미 사용하고 있는 것이 엄청나게 많다.

만약 특정한 코드를 만들거나 재활용 할 때 예를 들어 텍스처를 x와 y 위치 모두 타일링하고 있을 경우 실제로 그 코드를 가져다가 머티리얼 함수에 넣는 게 편할수도 있다.

그 다음 머티리얼 라이브러리로 코드를 공유할 수 있어서 언제든지 타일링에 조정이 필요하다면 머티리얼을 하나하나 모두 조정하는 대신 머티리얼 함수 하나만 열고 거기서 타일링을 조정하면 된다.

 머티리얼 함수는 머티리얼 코드를 공유할 수 있게 하여 대규모의 전반적인 변화를 가해야 할 때 유지보수의 간소화에 도움을 준다.

 

RGB Mask Packing(RGB 마스크 패킹

텍스처의 R, G, B 채널에 다양한 텍스처를 저장합니다.

마스터 머티리얼을 만들 때는 텍스처의 사용 방식을 지정할 수 있다.

저번에도 말했지만 아티스트가 텍스처의 빨강, 초록, 파랑 그리고 알파채널은 따로 텍스처를 저장하게 두는 것은 메모리의 텍스처 양을 확실히 줄일 수 있는 훌륭한 방법이다.

하지만 이것을 구성할 때에는 R, G 그리고 B 채널에 실제로 저장된 것을 확실하게 숙지하고 프로젝트가 진행되는 내내 그 점을 지켜야 한다는 것이다.

 

 

Static Switches(스태틱 스위치)

머티리얼에서 전체 코드 경로를 활성화 또는 비활성화할 수 있습니다.

머티리얼의 전체 경로를 활성화 또는 비활성화 할 수 있게 해준다.

예를 들어 패럴랙스 오클루전 노멀 매핑을 켜고 끄는 스태틱 스위치를 만들면 노멀 맵에 굉장히 비용이 높고 사실적으로 보이는 디테일을 구현할 수 있다.

하지만 이건 굉장히 비용이 높아서 씬의 머티리얼 다수에 사용하고 싶지는 않을거다.

스태틱 스위치에 이런 기능을 만들면 어떤 머티리얼에 이것을 켜고 끌지 제어할 수 있어서 아티스트들은 그냥 이게 정말, 정말 필요한 메시에 해당 기능을 켜기만 하면 된다.

 

피처 레벨 스위치

 

모든 장치에서 실행되는 하나의 재료를 만들 수 있습니다.

어떤 기기에서든 머티리얼이 실행될 수 있게 해준다.

다양한 플랫폼에 사용할 서로 다른 복잡도 수준에 따라 서로 다른 버전의 머티리얼을 연결하는 것이다.

예를들어 셰이더 모델5(SM5)를 사용해 거의 무한한 디테일과 아름다움을 얻고 싶다면 SM5는 높은 디테일의 셰이더가 될 것이다.

반면 ES2에서 실행되는 것은 Android 또는 모바일 프리뷰어가 될텐데 그저 실행만 될 뿐이지 뭔가 굉장한 부가기능을 많이 제공해주지는 않는다.

ES2에는 SM4에 비해 훨씬 덜 복잡한 머티리얼을 넣는다.

이를 통해 프로젝트가 목표로 하는 모든 플랫폼에서 작동할 단 하나의 머티리얼을 만들 수 있다는 것이다.