Understanding Charts – 번역
Understanding Charts
– 원문 링크 –
Understanding Charts – 번역
확인 완료한 버전: 5.5 – 난이도: 중급
유니티의 미리 계산된 실시간 GI(Precomputed Realtime GI)에서, 챠트(Chart)는 라이트맵 텍스쳐의 특정 영역이며, 라이트맵 텍스쳐를 해당 씬 오브젝트의 라이트맵 UV에 매핑합니다. 이것에 대해서, 해당 오브젝트에 영향을 미치는 라이팅의 이미지를 포함하는 작은 타일로 생각해 볼 수 있습니다. 챠트는 두가지로 구성됩니다: 조도 (라이팅) 와 방향성 (메인 라이트의 방향을 부호화).
미리 계산된 실시간 GI가 생성되면, 챠트에 포함되는 모든 텍셀에 대한 라이팅이 계산됩니다. 씬에 챠트의 수가 많으면, 라이팅을 미리 계산하는 시간에 영향을 주는 주요 원인이 됩니다. 따라서 라이팅 계산 시간을 최적화하기 위해서, 챠트가 동작하는 방식과 챠트를 관리하는 방법에 대해서 이해하는 것이 매우 중요합니다.
최소 4×4 텍셀 크기의 UV챠트를 보여주는 그림. 라이트맵 UV는, 텍스쳐 필터링에 의해서 발생하는 bleed를 방지하지 위해서, 항상 챠트 외부의 텍셀 크기의 반으로 고정됩니다.
기본으로, 각 챠트는 최소 4×4 텍셀입니다. 따라서 특정 챠트는 월드에 존재하는 오브젝트의 크기또는 해당하는 UV Shell의 크기에 관계없이 최소 16×16 텍셀의 크기를 필요로 합니다. 따라서, 예를 들어, 오브젝트의 크기가 1×1 미터이고, 챠트를 1개 가지며, 간접광의 해상도가 1인 경우, 이 오브젝트에 대해서 16 텍셀이 필요합니다. 이 최소 크기는 메쉬의 경계에 걸쳐서 seamless 라이팅을 위해서, 유니티가 여러 챠트를 한데 엮는 것을 가능하게 합니다. 유니티는 각 챠트가 적합한 짝을 찾고 이 짝과 묶기 전까지 이를 구별하기 위해서, 챠트 엣지(Chart Edge)에 따라 최소 4 텍셀을 필요로 합니다.
유니티는 메쉬 임포트 파이프라인의 패킹 단계 동안에 라이트맵 UV의 가장자리를 챠트 내의 텍셀 크기의 반으로 고정시키기 때문에, 실시간 GI에 대해서 패딩(padding)값이 필요하지 않습니다.
이 글의 위에서 언급했던 1×1미터 크기의 오브젝트가 50개의 챠트를 갖는다고 가정해 보겠습니다. 유니티는 이 오브젝트가 상당히 작은 크기임에도, 이 오브젝트에 대해서 800 텍셀을 생성합니다. 이는 다수의 챠트를 갖는 경우, 텍셀의 수가 빠르게 증가할 수 있다는 예를 보여줍니다. 텍셀의 수가 증가하면 라이팅 계산량도 증가합니다. 또한 처리, 압축, 저장이 필요한 데이터의 양이 더 많다는 것을 의미합니다. 이 모든 것이 복잡한 씬에 더해져, 라이팅 계산 시간이 길어지고 런타임 시에 성능을 낮추는 결과를 낳을 수 있습니다.
챠트가 부적절하게 설정되면 라이팅 계산 과정이 완료되지 않거나 계산되는 시간이 오래 걸리게 하는 주요 원인이 됩니다. 이에 따라, 라이팅을 미리 계산하는 시간을 줄이는데 사용되는 전략의 다수는, 씬의 챠트 수를 줄이는데 중점을 둡니다.
내용 끝까지 읽어주셔서 감사합니다.
배너 클릭은 저에게 많은 힘이 됩니다.
감사합니다 🙂
