렌더링 최적화
16편
빌드 다섯 시간과 셰이더 0.5GB 는 같은 원인이다
셰이더 변형은 키워드 축의 곱으로 늘어납니다. 너무 많으면 빌드가 안 끝나고, 너무 적으면 화면이 조용히 깨집니다.
부드러움을 메모리로 살 것인가 연산으로 살 것인가
스프라이트 애니메이션은 메모리를 쓰고 스켈레탈은 CPU 를 씁니다. 캐릭터마다 다르게 고르는 게 답이고, 스켈레탈은 Burst 만 깔아도 달라집니다.
한 줄로 배터리를 절반 쓰는 방법
targetFrameRate 를 30 으로 내리면 프레임 예산이 두 배가 됩니다. 최적화 코드를 짜기 전에 이 한 줄을 먼저 재 봐야 하는 이유.
해상도를 낮춘다는 게 정확히 무엇을 낮추는 것인가
Render Scale 은 기기 해상도를 바꾸지 않습니다. 게임을 그려 넣는 캔버스의 크기를 바꿉니다. UI 는 안 따라 내려갑니다.
안 보이는 픽셀을 몇 번 칠하고 있나
2D 는 반투명이 겹겹이 쌓이는 구조라 같은 픽셀을 네다섯 번 칠합니다. 드로우 콜을 아무리 줄여도 이건 안 줄어듭니다.
2D 라이트는 배칭과 필레이트를 같이 낸다
2D 라이팅은 스프라이트를 그리기 전에 라이트 버퍼를 따로 렌더링합니다. 그래서 라이트 하나가 CPU 와 GPU 양쪽에 값을 매깁니다.
전부 올려둘 것인가 필요할 때 올릴 것인가
Late Binding, Variants, Runtime Atlas 는 전부 로딩 전략입니다. 그리고 Runtime Atlas 는 게임플레이 중에 부르면 확실히 걸립니다.
용량은 그대로인데 화질만 깎였다면
이중 압축은 원본과 아틀라스 양쪽에서 압축할 때 생깁니다. 최종 용량은 같고 품질만 두 번 깎입니다. 그리고 에러가 안 납니다.
텍스처를 합치는 것이 곧 배칭을 합치는 것
아틀라스는 메모리 최적화로 알려져 있지만 실제 효과는 배칭 쪽이 큽니다. 그리고 묶는 기준은 기능이 아니라 로딩 시점입니다.
PNG 를 넣든 PSD 를 넣든 결과는 같다
이미지 압축과 텍스처 압축은 다른 개념입니다. 그리고 모바일 빌드에 DXT 를 지정하면 런타임에 압축이 통째로 풀려서 앱이 죽습니다.
정답이 파이프라인에 따라 뒤집힌다
MaterialPropertyBlock 은 Built-in RP 의 정석이고 SRP Batcher 에서는 배치를 깹니다. 같은 코드가 한쪽에서는 답이고 한쪽에서는 문제입니다.
배칭은 다섯 가지 이유로 끊긴다
머티리얼도 텍스처도 같은데 배치가 끊깁니다. 정렬 레이어와 반투명 순서 때문입니다. 에셋을 아무리 합쳐도 이건 안 풀립니다.
합치지 않고도 빨라지는 법
SRP Batcher 는 메시를 안 합칩니다. 머티리얼 값을 GPU 에 상주시켜 두고 오프셋만 바꿉니다. 그래서 배치 조건이 머티리얼이 아니라 셰이더 변형입니다.
합치는 비용이 그리는 비용보다 클 때
다이나믹 배칭은 매 프레임 CPU 가 메시를 합칩니다. 그 부등호가 요즘 하드웨어에서 자주 뒤집혀서, URP 에서 우선순위가 내려갔습니다.
배칭이 왜 끊겼는지는 화면이 알려준다
Frame Debugger 는 배치가 끊긴 사유를 문장으로 적어 줍니다. 그 문장을 실제 원인으로 옮기는 표와, 도구마다 있는 함정 하나씩.
드로우 콜을 줄였는데 느려졌다면
드로우 콜과 SetPass Call 은 다른 것을 셉니다. 드로우 콜이 524 에서 765 로 늘었는데 오히려 빨라진 실측이 있습니다.