LOD 메시와 텍스처 스트리밍을 함께 최적화하는 법

왜 LOD와 텍스처 스트리밍을 함께 봐야 할까

멀리 있는 오브젝트는 화면에서 차지하는 픽셀이 적다. 그런데도 가까이 볼 때와 같은 수의 삼각형을 그리고 최고 해상도 텍스처를 유지하면 GPU 연산, 비디오 메모리, 디스크 I/O를 불필요하게 사용한다.

LOD(Level of Detail) 메시는 화면상 크기에 맞춰 기하 구조를 단순화하고 텍스처 스트리밍은 필요한 밉맵만 메모리에 올린다. 둘 중 하나만 적용하면 병목이 남는다. 메시를 줄여도 큰 텍스처가 메모리를 압박할 수 있고 텍스처만 낮춰도 작은 화면에 과도한 삼각형을 제출할 수 있다.

거리별 메시 LOD와 밉맵 해상도가 함께 낮아지는 장면

먼저 측정할 항목

최적화는 숫자에서 시작한다. 목표 플랫폼과 대표 장면에서 다음 항목을 함께 기록한다.

프레임 시간과 GPU 프레임 시간
드로우콜 수와 배치 수
삼각형 수와 버텍스 수
텍스처 메모리 사용량 및 스트리밍 풀 사용량
밉맵 요청 실패나 강제 저해상도 전환 여부
카메라 이동 중 발생하는 I/O와 프레임 급락

특히 씬 전체의 삼각형 수만 보고 판단하면 놓치는 부분이 많다. 잎사귀, 철망, 실루엣이 복잡한 건물처럼 화면을 넓게 덮는 오브젝트는 적은 개수라도 비용이 커질 수 있다. 반대로 멀리 있는 배경 오브젝트는 개별 비용이 작아도 누적되어 문제가 된다.

메시 LOD 설계

LOD 단계는 화면 크기를 기준으로 정한다

거리만으로 LOD를 나누면 FOV, 해상도, 화면 비율이 바뀔 때 품질과 비용이 흔들린다. 가능하면 카메라와 오브젝트의 거리 자체보다 화면에서 차지하는 비율 또는 화면 투영 크기를 기준으로 전환한다.

일반적인 출발점은 다음과 같다. 실제 비율은 자산의 실루엣과 목표 기기에 맞춰 조정해야 한다.

단계	권장 용도	핵심 원칙
LOD0	플레이어 가까이 보이는 주 피사체	실루엣과 변형 품질을 보존한다.
LOD1	중거리 오브젝트	보이지 않는 면과 작은 돌출부를 먼저 줄인다.
LOD2	원거리 배경	큰 형태만 남기고 재질 수를 줄인다.
LOD3 또는 임포스터	아주 먼 거리	메시 대신 단순 카드나 임포스터를 검토한다.

LOD1과 LOD2를 만들 때는 단순히 폴리곤 수만 줄이지 말아야 한다. 카메라에서 식별하기 어려운 작은 홈, 뒤쪽 구조, 미세한 모서리를 우선 제거한다. 반대로 윤곽선에 영향을 주는 꼭짓점은 멀리서도 티가 나기 쉬우므로 신중하게 남긴다.

재질 수와 드로우콜도 함께 줄인다

LOD 메시가 더 적은 삼각형을 가지더라도 여러 머티리얼 슬롯을 유지하면 CPU 제출 비용과 상태 변경이 계속 남는다. 원거리 LOD에서는 비슷한 표면을 하나의 재질로 합치거나 필요한 경우에만 텍스처 아틀라스를 사용해 재질 수를 줄인다.

아틀라스는 무조건적인 해답은 아니다. 서로 다른 오브젝트가 한 장의 큰 텍스처를 공유하면 가까이 있는 작은 부분 때문에 넓은 영역의 높은 밉맵을 유지할 수 있다. 함께 보이고 비슷한 거리에서 사용되는 자산끼리 묶는 편이 유리하다.

전환이 보이지 않게 만든다

LOD 전환 시 메시 형태나 그림자가 갑자기 바뀌면 폴리곤 절감 효과보다 시각적 문제가 더 크게 느껴진다. 다음 방법을 조합해 완화할 수 있다.

인접 LOD의 실루엣을 가능한 한 비슷하게 만든다.
엔진이 지원하면 디더링 크로스페이드나 LOD 페이드를 사용한다.
그림자용 LOD를 별도로 확인한다.
스킨드 메시라면 본 수, 가중치 수, 모프 타깃도 단계별로 줄인다.

// 의사 코드: 화면 비율 기반 LOD 선택
int SelectLod(float screenCoverage)
{
    if (screenCoverage >= 0.20f) return 0;
    if (screenCoverage >= 0.05f) return 1;
    if (screenCoverage >= 0.01f) return 2;
    return 3;
}

임계값 자체보다 중요한 것은 전환 구간을 실제 플레이 카메라에서 확인하는 일이다. 망원 카메라, 빠르게 이동하는 카메라, 컷신 카메라는 같은 자산에도 전혀 다른 전환 문제를 드러낼 수 있다.

텍스처 스트리밍의 핵심은 밉맵과 예산이다

밉맵은 원본 텍스처를 절반 크기씩 축소해 둔 단계별 이미지다. 화면에서 작게 보이는 텍스처에 낮은 밉맵을 사용하면 샘플링 비용과 메모리 사용량을 줄이고 축소 시 깜빡임도 완화할 수 있다.

스트리밍 시스템은 대체로 오브젝트의 화면 크기와 UV 사용 범위를 바탕으로 필요한 밉맵을 추정한다. 추정한 해상도가 스트리밍 풀 예산을 넘으면 우선순위가 낮은 텍스처부터 더 낮은 밉맵으로 밀려난다. 이때 풀 크기만 키우면 일시적으로 선명해질 수 있지만 플랫폼의 실제 메모리 한계를 넘기면 로딩 끊김이나 메모리 부족 문제로 이어질 수 있다.

flowchart TD
    A[카메라에서 보이는 오브젝트] --> B[화면 크기와 UV 범위 평가]
    B --> C[필요한 밉맵 계산]
    C --> D{스트리밍 예산 안인가?}
    D -- 예 --> E[필요한 밉맵 로드 또는 유지]
    D -- 아니오 --> F[우선순위가 낮은 텍스처의 밉맵 낮춤]
    F --> E

스트리밍이 잘 작동하도록 자산을 준비한다

텍스처 스트리밍은 설정만으로 완성되지 않는다. 자산 제작 방식이 예측을 어렵게 만들 수 있다.

반복 타일링 텍스처는 UV 배율을 확인한다. 작은 메시라도 UV가 매우 크게 반복되면 높은 밉맵이 필요할 수 있다.
UI, 폰트, 항상 선명해야 하는 표식은 일반 월드 텍스처와 분리해 관리한다.
알파 채널이 필요 없는 텍스처는 불필요한 채널을 저장하지 않는다.
노멀맵, 마스크맵, ORM 텍스처는 플랫폼별 압축 형식과 채널 구성을 점검한다.
원거리 전용 LOD에는 필요 이상으로 큰 고유 텍스처를 연결하지 않는다.

텍스처 스트리밍 디버그 뷰에서 밉맵 우선순위와 메모리 사용량을 확인하는 예시

Unity와 Unreal Engine에서 확인할 지점

Unity

Unity에서는 LOD Group으로 메시 LOD와 전환 비율을 설정할 수 있다. 텍스처는 임포트 설정에서 밉맵 생성 여부, 최대 크기, 플랫폼별 오버라이드를 우선 점검한다. Texture Streaming을 사용할 때는 씬 뷰와 게임 뷰에서 텍스처가 예상보다 흐려지는 구간을 확인하고 Memory Profiler와 Frame Debugger로 메모리 및 렌더링 상태를 함께 살핀다.

모든 텍스처에 스트리밍을 강제하기보다 항상 선명해야 하는 UI나 특수 용도의 텍스처는 예외로 두는 것이 관리하기 쉽다. 반대로 넓은 오픈 월드의 환경 텍스처는 밉맵과 스트리밍 설정이 누락되지 않았는지 일괄 검사하는 편이 좋다.

Unreal Engine

Unreal Engine에서는 Static Mesh의 LOD 설정과 Screen Size 임계값을 확인한다. 텍스처는 밉맵 생성 설정, LOD Bias, 그룹별 최대 해상도, Texture Streaming Pool을 함께 본다. stat streaming과 텍스처 스트리밍 관련 뷰 모드는 어떤 텍스처가 예산을 압박하는지 찾는 데 유용하다.

풀 예산이 지속적으로 부족하다면 먼저 텍스처 해상도와 그룹 설정을 조정한다. 그 뒤에도 부족할 때 목표 플랫폼의 여유 메모리를 확인한 뒤 풀 크기 변경을 검토한다. 경고를 숨기기 위해 예산만 늘리는 방식은 원인 해결이 아니다.

자주 발생하는 실패 패턴

모든 자산에 같은 LOD 비율을 적용한다

캐릭터, 나무, 건물, 작은 소품은 실루엣과 화면 점유 방식이 다르다. 동일한 폴리곤 비율로 자동 감소하면 어떤 자산은 과도하게 품질이 떨어지고 어떤 자산은 충분히 줄지 않는다. 자산 유형별 기준을 두고 핵심 자산은 수동 검수를 추가하는 편이 낫다.

텍스처 해상도만 낮춘다

원본 해상도를 절반으로 낮추는 것은 효과가 있을 수 있지만 가까이 보이는 자산까지 희생할 수 있다. 먼저 밉맵과 스트리밍이 정상 동작하는지 확인하고 실제로 높은 밉맵이 필요하지 않은 텍스처부터 최대 해상도를 낮춘다.

카메라 이동을 테스트하지 않는다

정지 화면에서는 문제가 없어 보여도 빠르게 달리거나 텔레포트할 때 필요한 밉맵이 늦게 도착하면 눈에 띄는 흐림 현상이 생긴다. 대표 이동 경로를 자동화하거나 반복 재생해 I/O 급증과 밉맵 팝인을 확인해야 한다.

실전 점검 순서

목표 해상도와 프레임 예산을 정한다.
문제 장면에서 GPU 시간, 삼각형 수, 드로우콜, 텍스처 메모리를 측정한다.
화면을 크게 차지하는 자산부터 메시 LOD와 재질 수를 조정한다.
큰 텍스처와 높은 밉맵이 오래 유지되는 원인을 찾는다.
실제 플레이 경로에서 빠른 이동과 다양한 FOV를 포함해 재검증한다.
PC뿐 아니라 목표 콘솔 또는 모바일 기기에서 메모리 예산을 확인한다.

LOD와 텍스처 스트리밍은 각각 독립된 체크박스가 아니라 화면 품질을 필요한 곳에만 배분하는 하나의 전략이다. 가까운 피사체에는 실루엣과 선명도를 남기고 멀어지는 자산에서는 메시와 밉맵을 함께 줄이면 품질 저하를 덜 드러내면서 성능과 메모리 안정성을 확보할 수 있다.