그래프에 노드 하나 더 놓기 전에 세는 두 숫자

편집 화면에는 비용이 안 적혀 있습니다

노드를 연결하는 동작은 전부 같은 무게로 보입니다. 그런데 결과물에서는 프래그먼트마다 실행되는 것과 한 번만 계산되는 것이 완전히 다른 비용입니다. 모바일에서 문제가 되는 건 대체로 프래그먼트 쪽입니다.

세는 숫자는 두 개입니다. 프래그먼트에서 텍스처를 몇 번 읽는지, 그리고 이 그래프가 몇 개의 배리언트로 컴파일되는지.

절차적 패턴은 텍스처보다 싸지 않습니다

노이즈나 반복 패턴을 노드로 만들면 텍스처를 안 쓰니 가벼워 보입니다. 실제로는 픽셀마다 계산하는 함수가 되고, 텍스처 한 번 읽는 것보다 비싸지는 경우가 흔합니다. 미리 구워서 텍스처로 넣는 쪽이 대개 이깁니다.

1. 프래그먼트 노드 중 화면 전체에 적용되는 것을 표시합니다.
2. 그중 시간에 따라 변하지 않는 것을 찾습니다.
3. 변하지 않는 것은 텍스처로 굽습니다.

키워드 하나가 두 배입니다

키워드를 추가하면 조합이 두 배가 됩니다. 두 개면 네 배, 세 개면 여덟 배입니다. 이 숫자는 빌드 용량과 첫 사용 시점의 멈춤에 그대로 나옵니다.

// 키워드를 늘리기 전에 지금 몇 개인지 봅니다
// Inspector 하단의 variant 수를 읽고, 대상 플랫폼으로 컴파일해 확인합니다
#pragma multi_compile _ _RIM_ON
#pragma multi_compile _ _DISSOLVE_ON   // 여기서 이미 4배

숫자를 읽고 나면 선택이 두 개로 줄어듭니다

배리언트 수를 알고 그 수를 감당할 이유를 말할 수 있으면 그대로 갑니다. 말할 수 없으면 키워드를 머티리얼 분리로 바꿉니다.

마지막 줄이 첫 멈춤의 정체입니다. 배리언트를 미리 데워 이 줄을 없애는 방법은 분량이 따로 필요합니다.

[Compile] target GLES3: 96 variants
[Compile] target Vulkan: 96 variants
[Warn]    first draw compiled a variant at runtime