• The concept of Material Instances
• Why and when we need them
  • Accessing and modifying materials from BP/C++
  • Workflow optimization
  • Collaboration
• May reduce the number of shaders

머티리얼 인스턴스가 존재하는 이유

보통 표현식은 머티리얼 에디터 외부에서 액세스나 교체(수정)할 수 없다. 즉 머티리얼에서 뭘 하든 일단 완료한 다음에는 변경이 불가능하다는 것이다. 물론 머티리얼을 다시 실행해서 변경할 수는 있다. 하지만 게임이나 프로젝트가 실행중일 때는(런타임) 머티리얼을 실시간으로 변경할 수 없다. 하지만 표현식을 파라미터로 바꾼다면 가능하다. 그럼 머티리얼 인스턴스 시스템에서 사용할 수 있게된다. 머티리얼 인스턴스로는 부모 마스터 머티리얼의 특정 파라미터를 교체해 다양한 머티리얼을 만들 수 있다. 이 시스템으로는 C++나 블루프린트로 런타임 중 머티리얼에 액세스해 그 외형을 바꿀 수 있다. 예컨대 오브젝트가 사용자의 상호작용에 따라 색이 바뀌게 하고 싶을 때이다.

또 용도는 이뿐만이 아니라 그 외에도 머티리얼 인스턴스 시스템은 워크플로와 협업에도 상당한 영향을 미친다. 따라서 규모가 큰 프로젝트나 팀에서는 콘텐츠 파이프라인과 전반적인 정리의 최적화에 필수적인 툴이다. 그 작업 방식은 보통 마스터 머티리얼을 만드는 식이다. 부모 머티리얼이나 마스터 머티리얼이나 다 똑같다. 두 가지 이름이 모두 등장하지만 같은 의미다. 하지만 모든 인스턴스가 상속을 받는 머티리얼이 하나 있다. 이런 인스턴스는 자손인데 마스터나 부모 머티리얼이 되는 일반 머티리얼은 하나이다. 보통 마스터 머티리얼은 다수를 생성하고 이런 생성 작업을 표면의 다음과 같이 유형별로 해주는 편이다

• Stone master
• Vegetation master
• Glass master

Switch Param 표현식

True나 False를 판정할 수 있다.

보통 프로젝트의 거의 모든 머티리얼은 사실상 머티리얼 인스턴스가 될 거고 꽤 작은 마스터 머티리얼 세트에서 영향을 받게 될 것이다. 여기서 얻는 장점으로는 프로젝트 단위의 변경이 필요할 때 머티리얼 수백 개를 일일이 실행할 필요가 없어진다는 것이다. 그냥 대강 열 몇개의 마스터 머티리얼만 실행해 거기서만 변경을 해도 나머지는 다 따라오는 것이다. 또 시간 절약도 되는 게 매번 작업을 할 때마다 새 머티리얼을 만들 필요도 없고 매번 새 기능을 만들 필요도 없기 때문이다. 매 머티리얼마다 해야하는 작업을 마스터 머티리얼에서 단번에, 혹은 짧게 끝낼 수 있기 때문이다. 그래서 새 머티리얼을 만드는 것보다 훨씬 더 쉽다.

또한 인스턴스는 셰이더 컴파일이 필요없다. 인스턴스를 사용하면 업데이트와 반복처리가 훨씬 빨라진다. 그 이유로는 예컨대 이렇게 작업을 하다가 단순 수치 변경을 해 보고 싶은 경우가 있을 것이다. 이 값을 변경하려면 수치를 바꾸고 ‘적용’을 누른 뒤 몇 초 정도 기다렸다가 결과를 확인하는 식이다. 하지만 인스턴스로는 그런 문제가 전혀 없다. 어떤 값이든 즉시 변경할 수 있으며 컴파일을 할 필요도 없다.

또한 애셋 하나를 다수로 분할하기도 한다. 머티리얼을 하나로 두지 않고 작업을 분할하는 것이다. 마스터 머티리얼이 있고 인스턴스가 있을 때, 협업 환경에서 한 사람에게 마스터 머티리얼을 맡기고 다른 한 사람에게 머티리얼 인스턴스를 맡겨도 된다는 뜻이다.

덕분에 숙련된 팀원들은 마스터 머티리얼에 집중하고 신입 팀원들은 인터페이스가 간소한 머티리얼 인스턴스만 사용하게 할 수 있다. 사용이 꽤 간편한데 그냥 목록을 따라 값만 바꿔주면 된다. 마스터 머티리얼 네트워크를 빌드하는 것보다는 훨씬 쉽다.

물론 단점도 있다. 유연성을 좀 덜한데 주어진 파라미터 활용 외에는 머티리얼 커스터마이징이 불가능하기 때문이다. 또 인스턴스가 되어야하는 요소와 새 마스터 머티리얼이 될 요소간의 균형도 맞추어야 한다. 이게 꽤 어려워서 연습이 좀 필요하다. 즉 예컨대 여기 있는 인스턴스에서 어떤 이유로든 한 섹션 하나(픽셀의 일부분) 를 이미시브로 만들어야 한다 해도 그럴 수가 없다. 마스터 머티리얼에서 이미시브 기능이 준비되지 않았기 때문이다. 반드시 주어진 요소만 활용할 수 있다는 것이다. 물론 다시 머티리얼로 돌아가서 이미시브 지원을 추가할 수도 있지만 그럼 이 마스터 머티리얼을 사용하는 단일 인스턴스가 전부 그 지원을 받게 된다. 이런 경우 조금 과할 수 있다. 속도가 저하될 수 있다.

사용자들이 머티리얼 인스턴스 시스템에서 저지르는 가장 큰 실수는 전체 프로젝트에서 마스터 머티리얼을 하나만 만드는 것이다. 그렇게 딱 하나만 만든 마스터 머티리얼은 결국 엄청나게 커진다. 모든 용례를 다 처리해야 하니 정말 엄청나게 커지는데 작업 시작 시점에서 생각보다 많이 저지르는 실수이다. 결국 지나치게 복잡해져서 아무도 건드리지 못할 정도로 혼란스러워지는 데다가 퍼포먼스에도 영향을 미치기 시작한다. 새 기능이 계속 추가되며 머티리얼 비용도 올라가기 때문이다. Switch를 엄청나게 추가한다 한들 셰이더 순열의 수는 여전히 수직상승하게 된다.