포스트 프로세스 머티리얼

포스트 프로세스 머티리얼은 포스트 프로세스에서 사용할 수 있는 머티리얼 셋업을 통해 대미지, 광역 효과용 비주얼 스크린 이펙트를 만들거나, 포스트 프로세스 머티리얼을 통해서만 가능한 게임 전반적인 분위기를 낼 수도 있습니다.

여기서는 포스트 프로세스 머티리얼 셋업 방법, 거기서 사용할 수 있는 세팅과 아울러 다양한 버퍼, 여러 포스트 프로세스 머티리얼의 블렌딩 등의 셋업 예제도 함께 살펴보도록 하겠습니다.

포스트 프로세싱 그래프

엔진에는 이미 포스트 프로세싱 노드 그래프를 기반으로 한 복잡한 포스트 프로세싱 기능이 있습니다. 포스트 프로세싱 머티리얼 을 특정 위치에 추가적으로 삽입시키는 것이 가능합니다. 전체 그래프에 대한 개념은 r.CompositionGraphDebug FAQ 를 참고하세요. 그래프는 포스트 프로세싱 뿐만 아니라 라이팅도 일부 처리해 줍니다.

대부분의 경우 그래프는 중간 렌더 타깃을 자동으로 생성합니다. 즉 이전의 색과 블렌딩하려는 경우 셰이더에서 (PostProcessInput0 의 입력을 사용하여) 블렌딩을 해 줘야 한다는 뜻입니다.

포스트 프로세스 머티리얼은 주의해서 꼭 필요할 때만 사용해야 합니다. 가급적이면 색 보정이나 조정, 블룸, 뎁스 오브 필드, 기타 여러가지 이펙트에 대해서는 최적화도 잘 되어 있고 더욱 효율적인 포스트 프로세스 볼륨 에 상속된 세팅을 사용하는 것이 좋습니다.

포스트 프로세스 머티리얼 사용하기

(보통 포스트 프로세스 볼륨이나 카메라 세팅으로 정의되는) 포스트 프로세스 세팅을 통해 (소위) 블렌딩 가능 애셋을 블렌딩할 수 있습니다. 현재 블렌딩 가능 애셋이란 머티리얼 과 머티리얼 인스턴스 뿐입니다. 엔진에서 약간의 포스트 프로세스 머티리얼을 제공해 주고 있으나, 이 기능을 통해 프로그래머의 도움 없이 독특한 커스텀 포스트 프로세싱 을 만들 수 있습니다.

그저 Blendables 섹션의 포스트 프로세스 볼륨에 하나 이상의 포스트 프로세스 머티리얼을 할당해 주면 됩니다. 먼저 + 를 눌러 슬롯을 추가하고 콘텐츠 브라우저에서 머티리얼을 선택한 다음 왼쪽 화살표를 눌러 할당합니다. 여기서 순서는 중요치 않으며, 미사용 슬롯은 그냥 무시됩니다.

간단한 포스트 프로세스 머티리얼 만들기

간단한 포스트 프로세스 머티리얼을 처음부터 만드는 법에 대한 개요는, 포스트 프로세스 머티리얼 문서를 참고하세요..

(w:640)

포스트 프로세스 머티리얼의 중요 세팅

포스트 프로세싱 머티리얼은 머티리얼 영역 포스트 프로세스 를 지정해 줘야 합니다:

머티리얼은 새로운 컬러 출력을 위해서는 EmissiveColor 만 사용해야 합니다. 추가적으로 포스트 프로세스 도중 어디에 이 패스를 적용시킬지, 여러 곤데 있다면 어떤 순서로 처리시킬지(우선권)를 정의할 수 있습니다:

전형적인 포스트프로세스 입력은 그 전의 패스에서 옵니다. 그 컬러는 PostProcessInput0 사용시 SceneTexture 머티리얼 표현식을 통해 접근할 수 있습니다. SceneColor 를 사용하면 올바른 결과를 얻을 수 있을 것입니다.

여러가지 머티리얼 인스턴스 블렌딩

포스트 프로세스 머티리얼 사용하기

포스트 프로세스 볼륨을 가지고 여러 포스트 프로세스 머티리얼 사이의 부드러운 전환 구성을 쉽게 할 수 있습니다. 여기서는 언바운드 마킹된 볼륨 하나, 더욱 큰 블렌딩 반경 (약 1000 정도)의 볼륨 하나를 사용합니다:

각 볼륨에서는 같은 머티리얼의 다양한 머티리얼 인스턴스를 지정합니다. 컬러는 머티리얼 파라미터로 지정하여 두 머티리얼 인스턴스에 대해 다른 세팅을 가질 수 있도록 했습니다.

카메라 위치에 따라 Blend Radius (블렌드 반경) 거리 내 있을 때 한 볼륨의 세팅을 사용하여 블렌딩합니다:

카메라 이동을 통해 두 이펙트 세팅을 부드럽게 순서대로 전환시킬 수 있습니다.

다음은 두 개의 볼륨을 갖는 레벨을 내려보기로 본 모습입니다. 큰 언바운드 볼륨에는 빨강 머티리얼 인스턴스가, 작은 볼륨에는 초록 머티리얼 인스턴스가 블렌더블로 지정되어 있습니다. 작은 볼륨은 우선권이 높습니다. 머티리얼 파라미터는 카메라 위치에 따라 블렌딩되고 있습니다. 희미한 경계 부분은 Blend Radius 프로퍼티로 정의되는데, 볼륨에서 지정되며 볼륨 모양을 확장시킵니다.

올바른 구성으로 모든 블렌딩이 예상대로 일어나고 있습니다.

두 구성간의 차이점은 머티리얼 (스칼라 또는 벡터) 파라미터에 정의된 기본값입니다. 좋은 구성은 패스에 아무런 효과도 없는 것처럼 보이게 만드는 값을 가졌습니다 (예: 흰색으로 곱하거나 0 으로 선형보간합니다).

양쪽 구성에서 보이는 부분: 카메라가 어느 한 쪽 볼륨의 영향범위 밖에 있을 때, 포스트프로세스 패스는 렌더링되지 않습니다 (회색 그리드로 시각화). 볼륨 안에 완전히 들어가 있으면, 올바른 블렌딩이 보이기도 합니다.

나쁜 구성: 카메라가 영향 범위에 들어서면 딱딱한 전환이 일어나는데, 잘못 지정된 기본 파라미터를 사용하기 때문입니다.

좋은 구성: 들어서는 카메라의 전환에 영향 반경이 잘 숨겨져 있어서 볼륨 색으로의 부드러운 전환이 보입니다.

모든 머티리얼 인스턴스 프로퍼티는 그 체크박스가 체크되었든 되지않았든 상관없이 (체크되지 않은 경우에는 부모의 프로퍼티와) 블렌딩됩니다. 포스트 프로세스 세팅과는, 체크되지 않은 프로퍼티는 아무런 효과가 없다는 점에서 다릅니다. 즉 머티리얼 인스턴스를 블렌딩하면 모든 프로퍼티가 블렌딩된다는 뜻입니다.

머티리얼 표현식 "SceneTexture"

SceneTexture 머티리얼 표현식을 머티리얼에 추가시키고, 표현식 프로퍼티에서 가리키고자 하는 텍스처를 선택할 수 있습니다:

노드에는 옵션 입력과 여러 출력이 있습니다:

UV 입력을 통해서는 (Color 출력에만 사용되는) 텍스처 룩업을 어디서 할 지를 지정할 수 있습니다. 컬러 출력은 4 채널 출력(으로 씬 텍스처 id 에 따라 실제 채널 할당이 이루어지는 것)입니다. Size 는 텍스처의 폭과 높이로 이루어진 2 성분 벡터입니다. InvSize 출력에서 그 역수(1/폭, 1/높이)가 가능합니다. 아래와 같은 예제에서 인접한 샘플을 가리킬 때 편리하게 쓸 수 있습니다:

머티리얼 표현식은 현재 픽셀과 인접 픽셀과의 깊이차를 계산합니다 (즉 In = 0,1 으로 픽셀 아래로의 경과치를 반환합니다).

GBuffer 프로퍼티 사용하기

GBuffer 는 (서브서피스/스페큘러 컬러, 러프니스 등의) 머티리얼과 (노멀, 뎁스 등의) 오브젝트 특성을 저장하는 텍스처 다수로 구성되어 있습니다. 셰이딩 (빛과 머티리얼의 상호작용) 계산을 위한 라이팅 없이요. 디퍼드 렌더러에서는 먼저 GBuffer 를 렌더링한 다음 모든 라이팅을 GBuffer 특성과 함께 (deffered, 나중에 몰아서) 계산합니다. Unreal Engine 가 (DirectX 11 또는 고사양 OpenGL) 디퍼드 셰이딩 패스를 사용한다면 포스트 프로세싱 도중 해당 버퍼들에 접근할 수 있습니다.

안티-에일리어싱의 경우 이 작업이 약간 더 어려워 지는데, GBuffer 픽셀/텍셀과 출력 픽셀이 더이상 1:1 상관 관계에 있지 않기 때문입니다 (아래 섹션 참고).

커스텀 뎁스

이 별도의 기능으로 특정 오브젝트들을 (커스텀 뎁스 버퍼라는) 다른 뎁스 버퍼에 렌더링하여 마스킹 가능합니다. 드로 콜은 추가되겠지만 머티리얼이 들지는 않습니다. 뎁스만 출력하기에 렌더링 비용은 꽤나 쌉니다. 이 기능은 메시상에서 활성화 가능합니다 (예: Static Mesh Properties / Render Custom Depth):

이 씬에서는 이 기능으로 투명하게 남아있는 콘텐츠를 시각화시키는 포스트 프로세싱 패스 없이 두 개의 오브젝트에 활성화시킨 모습입니다:

여기서는 커스텀 뎁스를 시각화시켜 본 모습입니다:

그 시각화에 사용된 머티리얼입니다:

커스텀 뎁스 스텐실

Custom Depth Stencil (커스텀 뎁스 스텐실)은 렌더링된 오브젝트의 스텐실, 다른 말로 컷아웃(해당 부분만 오려 잘라낸 부분)을 사용할 수 있는 커스텀 뎁스의 확장으로, 가려진 오브젝트를 보이게 만들거나, 오브젝트 윤곽선을 그리거나, 특정 각도에서만 보이도록 하는 등 시각적으로 재미난 작업을 할 수 있습니다. 씬의 액터 스텐실에 접근할 수 있는 경우 많은 것을 할 수 있습니다. 스텐실 값 활성화 및 할당을 위한 세팅은 다음과 같습니다.

이 씬에서, 세 오브젝트에 커스텀 뎁스를 활성화시키고 각각에 대해 Custom Depth Stencil Value 를 설정했지만, 콘텐츠 시각화를 위한 포스트 프로세싱 패스(pass)가 없으면 이 부분은 보이지 않는 상태로 남아있습니다.

포스트 프로세스 머티리얼 셋업을 하고나면 커스텀 뎁스 스텐실을 보여줄 방법을 결정할 수 있습니다. 가려진 오브젝트를 사용된 Custom Depth Stencil Value 에 따라 무작위 할당된 색으로 렌더링합니다.

위 시각화에 사용한 머티리얼 셋업은 이렇습니다:

이미지를 클릭하면 원본을 확인합니다.

이것이 커스텀 뎁스 스텐실을 사용하는 유일한 방식은 절대 아닙니다. 이 머티리얼 셋업에서는 스텐실이 1 에서 255 사이 값을 사용하도록 나누었으며, 그 사이 값에 대해서는 마스크를 사용하고 있고, 그 값에 대해 무작위 색을 생성하여 커스텀 뎁스 스텐실 값 변화와 함께 색도 바꾸고 있으며, 마지막으로 생성된 마스크를 사용하여 오브젝트가 가려졌을 때만 스텐실 색을 입히도록 하고 있습니다.

템포럴 안티-에일리어싱 또는 GBuffer 지터링 이유

템포럴 안티-에일리어싱은 매우 적합한 수준의 퍼포먼스 비용으로 이미지 퀄리티를 크게 향상시켜 주는 Unreal Engine 고유 기능입니다.

기본적으로 포스트 프로세스 머티리얼은 포스트 프로세싱 그래프 끝( 톤 매퍼 이후)에 삽입됩니다. 즉 톤 매핑과 컬러 그레이딩 이후, 템포럴 안티에일리어싱이 적용된 이후 최종 LDR 컬러를 얻게 된다는 뜻입니다. 간단한 포스트 프로세싱 이펙트 다수에 대해서는 성능상으로나 사용 편의성으로나 최적의 지점입니다.

여기서는 커스텀 뎁스 입력을 사용하여 특정 오브젝트 주변의 실루엣을 그리는 방법을 볼 수 있습니다:

앞의 이미지에는 실루엣에 안티-에일리어싱이 없으나 모션중에는 실루엣에 약 1 픽셀 정도 지터링이 보이기도 합니다. 그 이유는 템포럴 안티-에일리어싱이 전체 씬의 렌더링을 매 프레임마다 서브 픽셀만큼 움직이기 때문입니다. 최종 안티-에일리어싱 적용 이미지를 위해 여러 프레임을 합치고 있습니다. 그러나 이 문제는 머티리얼 위치를 포스트 프로세싱 그래프에서 보다 앞으로 이동하여 수정 가능합니다.

결과는 이렇습니다:

안정적인 안티-에일리어싱 적용 이미지가 나옵니다. 모션중에는 템포럴 안티-에일리어싱 관련 부작용이 조금 보일 수 있습니다. 이 기능은 뎁스 버퍼를 사용하여 이전 이미지를 재투영시킵니다. 테두리를 오브젝트 안에 그리는 것으로 잘 작동하겠지만, 오브젝트 밖으로도 뎁스 버퍼를 조정해 줘야 할 것입니다 (아직 미완성, 퍼포먼스 비용 추가). 하지만 이상적으로는 그렇지 않을 것입니다.

UV 및 ScreenPos

포스트프로세스 머티리얼로 화면 정렬된 버퍼속을 룩업해 볼 수 있지만, 올바른 UV 를 알아야 합니다. ScreenPosition 머티리얼 표현식으로 원하는 UV 를 출력할 수 있습니다 (뷰포트 좌상단은 0,0 이고 우하단은 1,1). texture coordinate 머티리얼 표현식을 사용하면 다른 결과를 얻을 수도 있습니다. 왜냐면 실제 텍스처가 (좀 더 정확히는 렌더 타깃이) 뷰포트보다 클 수 있기 때문입니다. 에디터에서 커질 수 있는 이유는, 이 텍스처를 여러 뷰포트에 공유하고, 가장 큰 것이 모든 뷰포트에 사용되기 때문입니다. 심지어 게임에서도 더욱 커지는 경우가 있습니다 (예로 스크린 캡처 액터의 뷰포트가 작을 수도 있고, 마티네 블랙 보더나 분할화면, VR 등입니다). texture coordinate 머티리얼 표현식은 이 커다란 텍스처에 대한 UV 를 줍니다. 상대 오프셋만 필요한 경우 (예로 픽셀 크기의 에지 디텍션) 올바른 크기의 스케일 적용이 필요합니다. SceneTexture 머티리얼 표현식에는 크기와 크기 반전에 대한 출력이 있습니다 (픽셀 오프셋에 효율적이고 유용합니다). 전부 테스트하기 위해서는, r.ViewPortTest 콘솔 변수를 사용하여 다양한 뷰포트 환경설정을 테스트할 수 있습니다.

필터링된 텍스처 룩업

SceneTexture 머티리얼 표현식에는 [바이리니어] 필터링이 적용된 룩업을 구하는 체크박스가 있습니다. 이 옵션을 사용하면 렌더링이 느려질 수 있으므로, 꼭 필요한 경우에만 사용해야 합니다. 스크린 스페이스 텍스처 다수는 (GBuffer 등의) 필터링을 지원하지 않습니다. 이 프로퍼티를 노출하지 않으면 필요한 경우 엔진이 데이터를 압축하도록 할 수 있습니다 (패킹으로 필터링이 방지됩니다).

톤매퍼 대체하기

"Replacing the Tonemapper" 블렌더블 위치를 사용하여 엔진 내장 톤매퍼를 다른 것으로 덮어쓰는 것이 가능합니다. 개발중인 기능으로, 변경의 여지가 있고 모든 기능이 구비되어 있지 않을 수 있습니다.

톤매퍼에 몇 가지 포스트프로세스 세팅 파라미터를 노출시키기 시작했지만, 이 부분은 꽤나 변경의 소지가 있습니다. 값은 머티리얼 파라미터로 노출되어 있으며, 이름이 정확해야 합니다.

벡터 파라미터: Engine.FilmWhitePoint 스칼라 파라미터: Engine.FilmSaturation Engine.FilmContrast

파라미터를 구하기 위해서는 포스트프로세스 머티리얼에서 머티리얼 인스턴스를 만들어야 합니다.

여전히 별도의 파라미터를 사용하여 다른 포스트프로세스 머티리얼 세팅처럼 블렌딩시킬 수 있습니다.

알려진 문제점

수정해야할 문제점은 다음과 같습니다:

• 머티리얼 표현식 SceneTexture
  • SeparateTranslucency 미작동
  • 특정 패스에서 특정 룩업 미작동 (퍼포먼스 비용이 너무 심해 고치지 않을 수도 있음)
  • MaterialFunction 에서 오류가 나긴 하지만 여전히 PostProcess 영역을 가진 Material 에서 사용 가능
• 머티리얼
  • PostProcesMaterial 내 UV 가 (에디터에서 뷰포트 크기를 줄이거나 할 때) 0..1 범위에 있지 않을 수 있음. 룩업에 정렬되기는 하나 비녜트 이펙트같은 것을 구현하기가 어려워짐
  • 포스트 프로세스 머티리얼의 애셋 썸네일이 옳지 않음
  • 알파 출력 미지원 (Opacity 를 통해야 함)
  • 머티리얼 에디터의 프리뷰 머티리얼이 옳지 않음
  • 머티리얼을 바꿔도 포스트 프로세스가 바뀌지 않는 경우가 있음. 우회책: 에디터 재시작
  • 콘텐츠 브라우저에서 포스트 프로세스 머티리얼 필터링 적용을 쉽게 할 수 있어야
• 블렌딩
  • 블렌딩 반경을 가진 두 개의 포스트 프로세스 볼륨을 블렌딩할 때, 부드럽지 못한 전환이 보일 수 있음. 이런 현상은 기본값을 나타내는 머티리얼 인스턴스 세팅을 가진 언바운드 볼륨을 사용하여 예방 가능.

FAQ

• "라이팅만 모드" 텍스처를 입력으로 쓸 수 있나요?

  아뇨. 중간 과정이기에 이런 데이터는 가능하지 않습니다. 이 뷰 모드에 대해서는 머티리얼 컬러를 무시하여 생성합니다. 이것을 빠르게 만들기 위해서는 렌더링 코드 많은 부분의 재구성이 필요할 것입니다.

• SceneColor 룩업에 띠 현상이 보이는데 using PostProcessInput0 을 사용하면 보이지 않는거죠?

  SceneColor 가 사용되면 현재 쓰기 대상이 되는 텍스처로의 룩업을 허용하기 위해 씬의 저해상도 사본을 만듭니다 (일반적인 경우라면 이것이 가능하지 않은 곳에는 아무 메시나 렌더링합니다). 그래서 PostProcessing 에서는 PostProcessInput0 를 사용해야 합니다.

• 포스트 프로세스에 드는 메모리가 얼마나 되죠?

  메모리 비용은 화면 해상도에 따라 다릅니다. 톤매핑 전에는 HDR (픽셀당 8 바이트), 후에는 LDR (픽셀당 4 바이트) 을 사용합니다.

• 포스트 프로세싱 렌더링 비용을 어떻게 낮출 수 있을까요?

  타깃 플랫폼에 대해 염두에 두고, 텍스처 룩업 수를 낮게 유지하며, 수학 연산을 자제하고, 의존 텍스처 룩업 수를 줄이고, 랜덤화된 텍스처 룩업을 피합니다 (텍스처 캐시가 빗나가면 느려질 수 있습니다).

• 사용할 수 있는 패스 갯수는 얼마나 됩니까?

  추가되는 패스마다 퍼포먼스 비용이 발생합니다. 패스는 가급적 합치되 꼭 필요한 패스만 활성화시킵니다. 일반적인 게임 기능, 노이즈 같은 것은 퍼포먼스 향상을 위해 엔진 패스에 추가시킬 수도 있습니다.

• 포스트 프로세스나 블렌딩마다 드는 CPU 퍼포먼스 비용은 얼마나 되나요?

  머티리얼 블렌딩은 매우 쌉니다. 머티리얼 인스턴스 프로퍼티 전부 블렌딩되어 하나의 포스트프로세스 머티리얼 패스에서만 그러한 세팅으로 렌더링됩니다.

• 올바른 TemporalAA 를 위해서는 "Before Tonemapper" 를 사용해야 합니다. 어느 한 색을 사용하면 톤매핑이 적용되어 달라 보이는 것을 어떻게 방지할까요?

  쉬운 해법은 없습니다. (비싼) 톤매핑 반전 연산을 해야 할 수도 있겠구요. 시각 순응에 따라서 색이 달라 보일 수도 있습니다. EyeAdaptation 레벨을 SceneTextures 에 노출시켜 보정시켜 줄 수도 있겠습니다.

• 포스트 프로세싱 그래프 전체 덤프는 어떻게 구하나요?

  r.CompositionGraphDebug 를 통해 그래프를 콘솔에 출력시킬 수 있습니다. 예:

  FRenderingCompositePassContext:Debug 'PostProcessing' --------- Node#1 'SceneColor' ePId_Output0 (2D 1136x768 PF_FloatRGBA RT) SceneColor Dep: 2 Node#4 'Velocity' ePId_Output0 (2D 1136x768 PF_G16R16 RT) Velocity Dep: 1 Node#2 'SceneDepthZ' ePId_Output0 (2D 1136x768 PF_DepthStencil) SceneDepthZ Dep: 1 Node#5 'MotionBlurSetup0MotionBlurSetup1' ePId_Input0: Node#4 @ ePId_Output0 'Velocity' ePId_Input1: Node#1 @ ePId_Output0 'SceneColor' ePId_Input2: Node#2 @ ePId_Output0 'SceneDepthZ' ePId_Output0 (2D 568x384 PF_FloatRGBA RT) MotionBlurSetup0 Dep: 2 ePId_Output1 (2D 568x384 PF_FloatRGBA RT) MotionBlurSetup1 Dep: 1 Node#6 'QuarterResVelocity' ePId_Input0: Node#5 @ ePId_Output0 'MotionBlurSetup0MotionBlurSetup1' ePId_Input1: ePId_Output0 (2D 284x192 PF_FloatRGBA RT) QuarterResVelocity Dep: 1 Node#7 'VelocityBlurX' ePId_Input0: Node#6 @ ePId_Output0 'QuarterResVelocity' ePId_Input1: ePId_Output0 (2D 284x192 PF_FloatRGBA RT) VelocityBlurX Dep: 1 ...