05. 언리얼 머터리얼 설명과 쉐이더의 특징

01. 머터리얼 통계와 복잡도에 대해

앞으로 많이 체크해야할 화면

 

최적화를 할 때 많이 확인해야할 것이다.

여기에 기재되어 있는 숫자는 낮으면 낮을 수록 좋다.  높으면 무조건 안좋은 것이라는 것은 아닌데 조건이 있다.

 

많은 물체가 크게 나오는 경우에 쉐이더까지 인스트럭션이 높으면 좋지 않다.

물체가 많냐 적냐 / 크냐 적냐 / 쉐이더 인스트덕션이 많냐 적냐 등 여러가지를 보면서 파악해야만 한다.

 

-

 

같은 퀄리티일때는  base pass shader 계산수가 낮은게 좋다.

안정권은 게임장르나 방식에 따라 달라진다. 하여튼 가능한 낮출 수 있으면 좋다.

 

샘플러는 텍스쳐 갯수랑 일치하지 않는다. (이전에 설명했음)

 

Texture LookUps 는 쉐이더가 참조하고 있는 것을 보여주는 것

예시) VS(1), PS(11)은 버텍스 쉐이더에서 1개 픽셀 쉐이더에서 11개를 참조하고있다는 뜻

 

-

 

엄밀히 따지면 샘플러의 숫자가 높다면 컴파일 오류가 나서 만들어지지 않기에 그런 의미에서 확인을 해야하는 것이고

실제로 텍스쳐가 무거운 부분은 룩업을 봐야한다.

 

샘플러를 줄인다고 해도 룩업이 줄어들진 않는다. 룩업은 참조하는 텍스쳐 자체를 줄여야지 줄어든다

 

-

 

버텍스 쉐이더에서 픽셀 쉐이더로 정보를 넘길 때

일부 정보를 픽셀쉐이더에서 계산할 걸 버텍스 쉐이더에서 미리 계산에서 넘기는 방식으로 최적화를 할 수 있다.

 

버텍스 쉐이더에서 계산해서 넘겨주면 계산 자체도 줄고, 대상 계산의 정밀도가 높아진다

 

-

 

복잡도에 대해서

기본적으로 녹색일수록 가볍고

빨간색 -> 흰색일수록 무겁다

 

반투명 아니고서야 그렇게 무거워지기가 어렵다.

 

색만 보고 판단하지 말고 여러가지를 보고 파악하자.

 

이 창은 쿼드 오버드로우라는 복잡도인데

 

이건 매쉬의 드로잉 영역의 겹침을 보여주는 것이다

이건 FOD을 강하게 하면 훨씬 더 많은 오브젝트들이 보일것이고

그럼 훨씬 더 적은영역에 많은 오브젝트들이 겹쳐 보일 것이다.

 

겹치는 폴리곤은 계산단계에서 낭비가 되는 것이고 그걸 보여주는 뷰라고 생각하면 된다.

 

이 문제는 쉐이더에서 해결할 수 있는건 아니고 

보통 LOD을 사용함으로써 해결하고 있다.

 

 

02. 드로우콜 이해하기

드로우 콜은 화면을 그리기 위해 얼마나 많이 호출을 하는가? (cpu가 gpu 에게) 이고

이 콜을 자주하게 되면 당연히 무거워진다고 생각하면 된다.

 

드로우 콜이 많다는 것은 둘중 하나가 병목현상이 일어난다면

한쪽이 일을 안하고 기다리는 현상이 일어날 수 있다는 얘기다.

 

보통 CPU는 GPU보다 먼저 계산을 하고  GPU한테 보낸 다음에 또 다음걸 계산하고 보내주는 방식이다.

1번 이미지 같은 경우는 매우 잘 정리된 상태고 잘 없는 상태이다

 

2번 이미지 같은 경우는 GPU가 작업을 다 끝냈는데 CPU가 작업을 다 못끝낸 상태를 보여주는 것인데

그러면 그 시간동안 GPU는 쉬고 있다. 이게 반복이 되면 병목현상이 심하다 라고 얘기하는 것.

 

이걸 처리하는건 보통 하드웨어나 그래픽 API쪽이라 우리가 직접적으로 관여할 수가 없다.

 

가장 큰 부분을 차지하는건 캐시 메모리.

이번에 보낼 콜의 내용을 저장하는 것도 캐시라고 볼 수 있는데 이것이 크냐 작냐에 따라서 통신상태가 달라질 수도 있다.

 

이런 것들에 따라서 상황이 바뀔 수 없다.

 

우리가 일반적으로 드로우 콜이 높다, 그래픽 문제라고 생각하는 것들이 사실은 CPU문제일수도 있다.

무거운 연산들이 많을 수록 드로우콜 발생률이 많아 질수도 있다는 뜻

 

반대로 드로우 콜이 낮고 프레임이 안나오면 GPU문제, 그러니까 그려야할 픽셀 수가 많을 수도 있다.

해상도가 높아지면 그만큼 그려야 할게 많아지는 둥 말이다.

 

아무튼 실시간이면 전부 발생할 수 있다.

콜이 낮으면 리스크가 줄어드는건 사실이라 낮으면 좋긴하다.

 

 

03. 기본 텍스쳐의 머터리얼 등록

 

 

그냥 원시적으로 틴트 멀티플라이 해서 만들지는 않는다.

노말은 샘플러 타입을 노말로 바꿔줘야한다 (데이터 텍스쳐이기에 감마보정은 계산에 방해가 됨)

마스크 맵은(그 외에 라이너 컬러를 쓰는 모든 것은) sRGB를 항상 꺼주자

 

기본적으로 RGBA는 무겁다.

마스크를 6장을 써야한다면 RGBA 하나, RG 하나를 쓰는 것보다

RGB, RGB 쓰는게 더 가볍긴 하다.

 

아무리 좋은 포맷이라도 해도 RGBA에는 네이티브 압축이 되기 때문에 말이다.

 

-

 

보통 러프니스는 G채널에 할당하는데

러프니스가 영향을 좀더 많이 미치기 때문이다! (R:5bit G:6bit: B:5bit)

 

러프니스는 대충 수식 2개 정도의 연산이 들어가고

그 외 메탈릭같은 녀석은 1개밖에 안준다.

 

기본적으로는 메탈릭은 마스크 형태로 나가는 경우가 많다

러프니스도 그래야하긴 한데 조금 더 디테일하게 잡는 경우도 조금 있다

그렇기에 조금 더 할당해주는 것이라고 생각하면 된다.

 

그 외에 보다 정밀하게 넣고자 하는 것은 G채널에 할당해주면 좋을 것이다.

-

 

AO 텍스쳐 같은 경우는 관념적으로 사용하기 쉬운 텍스쳐인데

아주 많은 영향을 주는 텍스쳐이다.

 

AO는 간접광을 얼마나 받겠느냐를 얘기하는 것과 같다.

이걸 사용하는 이유는 빛 부분에서 조금 더 유연하게 사용하기 위해 쓰기 위해서이다.

 

이걸 sRGB로 받냐 Linear로 받냐에 대해서는 의견이 분분한데

일단 우리는 Linear으로 받는다고 생각하고 있자

 

간접광을 더 많이 받을 순 없고, 덜 받겠다만 된다고 생각하면 되겠다.

 

언리얼에서는 Skylight 영향을 받는데 스테이시에선 AO 적용이 되는데

무버블에선 적용이 안된다 (ㅠㅠ)

 

 

 

 

04. HLSL코드와 노드의 다른점에 대해서

 

언리얼은 코드기반 쉐이더를 만들 수는 있긴한데 편하게 세팅되어 있진 않다.

유니티와 언리얼은 언어는 똑같은데 적용하는 방식이 조금 다르다.

 

언리얼에서 커스텀 노드로 만들어서 노드 갯수를 줄이면 인스트럭션이 줄어들까? 

답은 아니다.