
UE5 텍스처 스트리밍 풀 예산 초과 비주얼 가이드: 진단 및 수정
원인을 숨기지 않고 텍스처 스트리밍 풀이 예산을 초과하는 문제를 해결하세요
동일한 지도와 카메라 경로에 경고를 재현하고, 통계 스트리밍을 캡처하며, 과도한 MIPS, Never Stream 자산, NonStreaming Mips, 또는 대상 하드웨어 예산이 초과 발생을 일으켰는지 식별하세요. r.Streaming.PoolSize를 측정된 테스트 변수로 간주하세요; 큰 수치는 대상 GPU가 감당할 수 없는 한 지속 가능한 해결책이 아닙니다.
- 캡처 풀 크기, 필요한 풀, 가시 MIPS, 비스트리밍 MIPS, 해상도, 확장성, RHI.
- 예산을 올리기 전에 텍스처 해상도, MIP 가용성, 스트리밍 플래그, 재질 사용을 먼저 고치세요.
- 에디터, 독립 실행, 그리고 타겟클래스 하드웨어에서 패키지 빌드를 반복하세요.
직접적인 답변: 원인을 숨기지 않고 "텍스처 스트리밍 풀 초과" 문제를 해결하세요
"텍스처 스트리밍 풀 예산 초과"는 언리얼 텍스처 스트리머가 현재 풀이 장면과 뷰에 허용하는 것보다 더 많은 텍스처 메모리를 원한다는 의미입니다. STAT STREAMING로 시작하여 같은 카메라 경로에서 경고를 재현하고, 초과 데이터가 과도한 텍스처 밉스, 누락되거나 사용 불가능한 밙스, Never Stream 자산, 예상치 못한 비스트리밍 할당, 또는 대상 하드웨어에 비해 너무 작은 풀 예산에서 오는지 식별하세요. r.Streaming.PoolSize는 측정된 테스트 변수로만 사용하십시오. 경고가 사라질 때까지 하나의 유니버설 메가바이트 값을 선택하거나 풀을 올리지 마십시오.
내구성 있는 수정은 콘텐츠와 플랫폼 간의 결정입니다: 각 대상 클래스에 텍스처-메모리 예산을 설정하고, 비싼 텍스처를 스트리밍 가능하게 만들며, 시각적 결과가 남아 있는 부분에서만 해상도를 낮추고, 필요한 MIP 체인과 압축을 보존한 후, 동일한 대표 경로를 에디터, PIE, 독립 실행형, 패키지 빌드에서 검증하는 것입니다. 가상 텍스처링은 특정 대용량 또는 레이어드 워크로드에 도움이 될 수 있지만, 기존 텍스처 스트리밍 진단을 자동으로 대체할 수는 없습니다.
빠른 분류 체크리스트
- 명명된 지도, 카메라 경로, 해상도, 확장성 수준, 목표 RHI에서 경고를 재현하세요.
STAT STREAMING를 실행하여 풀, 필요한 풀, 가시 밉스, 숨겨진 밉스, 강제 밉스, 비스트리밍 값들을 캡처하세요.- 프로젝트 전체 설정을 변경하기 전에 가장 큰 기여 텍스처를 점검하세요.
- 한 번에 한 가지 변경만 테스트하세요: 텍스처 치수, MIP 가용성, LOD 바이어스 또는 텍스처 그룹, 압축,
Never Stream, 재료 사용, 또는 풀 크기. - 같은 카메라 경로를 다시 실행하고 메모리, 이미지 품질, 팝인, 프레임 페이싱을 비교하세요.
- 대표적인 저메모리, 중간, 고메모리 기기에서 독립 실행형 또는 패키지형 빌드로 결과를 확인해 보세요.
경고가 실제로 측정하는 바
언리얼의 텍스처 스트리머는 메모리 풀을 존중하면서 현재 뷰에 어떤 MIP이 상주할지 선택합니다. 풀은 단순히 '모든 보이는 색상 텍스처'가 아닙니다. Epic의 텍스처 스트리밍 구성에는 r.Streaming.PoolSize가 메가바이트 단위로 표현되며, 텍스처 풀에는 UI 텍스처, NeverStream 텍스처, 큐브맵, 그리고 일부 플랫폼에서는 텍스처가 아닌 GPU 자원도 포함될 수 있다고 명시되어 있습니다. 그래서 카메라 가까이에 있는 텍스처가 평범해 보여도 경고가 계속 표시될 수 있습니다.
경고는 예산 신호이지 특정 부정 자산의 증거가 아닙니다. 장면이 예산을 초과할 수 있는 이유는 여러 개별적으로 합리적인 텍스처 세트가 함께 상주하게 되거나, 시네마틱 카메라가 많은 고디테일 밧값을 선호하게 만들거나, 자산에 사용 가능한 밧 체인이 없거나, 비스트리밍 할당이 헤드룸을 소모하기 때문입니다. 반대로, 기존 풀이 출하 하드웨어에서 측정된 예산보다 낮을 때 더 큰 풀이 맞는 경우도 있습니다. 결정은 플랫폼 프로필과 재현 가능한 작업 부하에 연동되어야 합니다.
이 경고를 일반적인 GPU 메모리 초과 충돌과 혼동하지 마세요. 스트리머는 프로세스가 계속 실행되는 동안 요청한 풀을 초과할 수 있습니다. 스트리머는 원하는 MIP을 포기하여 흐릿한 텍스처, 늦은 디테일 변경, 불안정한 상영 상태 또는 반복적인 풀 경고를 유발할 수 있습니다. 크래시, 장치 제거 또는 더 넓은 렌더링 메모리 고갈은 더 광범위한 GPU 메모리 조사가 필요합니다.
통계 스트리밍으로 경고를 진단하세요
영향을 받은 지도를 열고, 카메라를 실패하는 경로에 설치한 뒤, 로딩이 안정될 때까지 기다린 후 실행:

STAT STREAMINGEpic의 텍스처 스트리밍 지표는 텍스처 스트리밍 성능과 메모리 카운터의 주요 뷰로 STAT STREAMING를 문서화합니다. 콜드 로드 후와 대표 트래버설 후에 캡처하세요; 단일 유휴 편집기 스크린샷은 피크를 놓칠 수 있습니다. 엔진 버전, 화면 해상도, 확장성 수준, 에디터 뷰포트 모드, RHI를 캡처와 함께 유지하여 다른 개발자가 반복할 수 있도록 하세요.
그룹들을 한 번의 빨간 숫자만 쫓기보다는 원인 지도로 읽어보세요:
- 필요한 또는 원하는 MIP이 스트리밍 풀을 초과합니다: 현재 뷰는 예산이 허용하는 것보다 더 많은 스트림 디테일을 요구합니다. 큰 텍스처를 정렬하고, 원하는 치수를 검사하며, 텍스처-그룹 정책을 비교하세요.
- 강제 미프가 높음: 자산, 컴포넌트, 시네마틱 또는 코드가 강제 거주 시 허용될 수 있습니다. 강제 상주 설정을 찾아 촬영이나 게임 플레이에 필요함을 증명하세요.
- NonStreaming Mip이 높음: 일반 스트리밍 가능 거주 외의 메모리가 헤드룸을 소모하고 있습니다.
Never Stream, UI, 큐브맵, 렌더링 타겟 및 기타 할당을 점검한 후 풀을 올리세요. - 눈에 보이는 mips는 특정 경로에서만 올라가:카메라 거리, 시야, 가림 현상, 또는 밀집된 재질 클러스터가 최대치를 유발해. 그 경로를 분석하고 동시에 높은 해상도 요구를 줄여.
- 경고는 반복 이동 후에만 나타납니다: 오래된 참조, 웜 캐시, 또는 라이프사이클 동작이 관련될 수 있습니다. 깨끗한 출시, 반복 이동, 해체를 동일한 테스트 순서와 비교해 보십시오.
정확한 카운터명과 레이아웃은 언리얼 버전마다 다를 수 있습니다. 프로젝트에 맞는 Epic 문서 버전 선택기를 사용하고, 포럼 스크린샷에서 임계값을 복사하는 대신 전체 출력을 기록하세요.
피크를 만드는 자산과 설정을 찾아보세요
실패한 뷰의 증거부터 시작한 후, 이를 설명할 가능성이 가장 높은 자산을 점검합니다. 유용한 체크로는 텍스처 치수, 픽셀 포맷, 압축 설정, 텍스처 그룹, LOD 바이어스, MIP 생성 설정, MIPS 수, Never Stream, 그리고 텍스처를 참조하는 모든 재질 또는 UI 경로 등이 있습니다. 4K 텍스처가 자동으로 틀린 것은 아닙니다; 그 텍스처의 세부 묘사가 대상 뷰와 하드웨어에 대한 측정 가능한 시각적 기여량보다 더 많은 비용을 들일 때 잘못된 것입니다.
FBX, GLB, OBJ, USD, SCAN, AI 생성 자산의 경우, 전체 핸드오프를 보이게 유지하세요: 업로드 또는 가져오기 → 미리보기 → 수정 → 최적화 → 변환 → 내보내기 → Unreal 검증. 소스 패키지가 거의 동일한 4K 맵을 여러 개 첨부하지 않았는지, 사용하지 않은 재질을 삽입하지 않았는지, 압축되지 않은 색상 텍스처로 마스크를 내보내지 않았는지, MIP 준비 가능한 치수를 누락하지 않았는지 확인하세요. 프리임포트 정리는 노이즈를 줄이지만, 재질, 텍스처 그룹, 스트리밍 규칙, 플랫폼 프로필이 프로젝트 네이티브이므로 최종 거주 결정은 언리얼에서 검증되어야 합니다.
특히 다음 근본 원인에 주의를 기울이세요:
- 과도한 소스 해상도: 텍스처에는 에셋이 화면에 보여주지 않는 세부 묘사가 포함되어 있습니다. 축소하기 전에 실제 카메라 경로에서 최대 투영 크기를 비교하세요.
- 누락 또는 비활성화된 MIP 생성: 스트리머가 더 저렴한 저해상도 레벨을 선택할 수 없습니다. 임포트 또는 MIP 생성 정책을 수정하고 원거리에서 품질을 점검하세요.
- 부적절한 텍스처 그룹 또는 LOD 정책: 광범위한 그룹은 이 자산군에 필요한 것보다 더 많은 세부 정보를 유지할 수 있습니다. 자산별 분산된 예외보다 소유 그룹 정책을 선호합니다.
- 잘못된 압축 또는 의미 유형: 노멀, 마스크, HDR 데이터, UI, 색상 텍스처는 서로 다른 요구사항을 가집니다. 압축은 파일 확장자뿐만 아니라 데이터의 의미에서 선택하세요.
Never Stream또는 강제 거주: 이들을 안정된 완전한 세부 묘사 거주가 진정으로 필요한 자산에만 예약하세요. UI, 시네마틱, 게임 플레이 요구사항이 없음을 확인한 후에만 제거하세요.- 중복되거나 사용하지 않은 참고문헌:재질 인스턴스, 숨겨진 메쉬, 변형, 혹은 오래된 콘텐츠가 불필요한 텍스처를 계속 유지할 수 있어. 일반적인 소스 컨트롤 리뷰를 통해 참조를 제거한 다음, 다시 빌드하고 테스트해봐.
근본 원인을 올바른 순서로 해결하세요
측정된 원인을 다루는 가장 작은 가역 가능한 변화를 사용하세요. 이 순서는 시각적 품질과 플랫폼 제약 조건을 가시화합니다.

- 기준선을 고정하세요. 실패한
STAT STREAMING캡처, 경로, 빌드 정체성, 풀 설정, 스크린샷을 비교 뷰에서 저장하세요. - MIP 가용성 복구. 스트리밍 가능한 월드 텍스처가 유효한 MIP 체인을 가지고, MIP 생성이 의도치 않게 비활성화되지 않았는지 확인하세요. 통제된 소스 자산에서만 재가져오기.
- 가장 무거운 텍스처는 적정 크기로 조정하세요. 대상 카메라가 제거된 디테일을 이해할 수 없는 부분에서는 치수를 줄이거나 LOD 바이어스를 적용하세요. 히어로 오브젝트와 클로즈업은 배경 자산과 별도로 확인하세요.
- 그룹 및 압축 정책을 올바르게 설정하세요. 관련 자산을 의도적인 텍스처 그룹과 데이터 적절한 압축 아래에 배치합니다. 패키지 크기, 메모리, 가시 아티팩트를 다시 점검합니다.
- 부당한 강제 거주 제거. 감사
Never Stream강제 거주 행동, 그리고 시네마틱, UI, 빠른 회전, 텔레포트 케이스를 테스트하여 허용되지 않는 팝인 현상을 확인한다. - 동시 수요 감소. 과도하게 빽빽한 재질 세트를 분할하고, 중복 맵을 제거하며, 먼 변형을 단순화하거나, 너무 많은 고비용 텍스처가 동시에 필요할 때 레벨 구성을 변경합니다.
- 풀을 마지막으로 평가하세요. 최적화된 콘텐츠가 하드웨어의 측정된 GPU 메모리 예산과 안전한 여유 공간에 여전히 맞는다면, 플랫폼별 풀을 의도적으로 설정하고 그 이유를 문서화하세요.
진단 시 실행 시간을 실험적으로 변경할 수 있습니다:
r.Streaming.PoolSize 1500이 숫자는 예시 명령어입니다. 권장 생산 값이 아님. 콘솔 변경은 일시적이며 "더 많은 풀 헤드룸이 이 특정 압력을 제거할까?"라는 질문에 답하는 데 도움이 됩니다. 영구 구성은 프로젝트가 검토한 구성 및 장치 프로필 전략에 포함됩니다. 올바른 값은 플랫폼, GPU 메모리, 해상도, 기타 렌더링 기능, 장면의 피크에 따라 다릅니다. 먼저 저메모리 장치를 테스트하세요; 에디터 워크스테이션은 안전하지 않은 배송 옵션을 숨길 수 있습니다.
가상 텍스처링이 언제 적합한지 결정하세요
기존 텍스처 스트리밍과 가상 텍스처링은 겹치지만 서로 다른 상주 문제를 해결합니다. Epic의 텍스처 스트리밍 개요는 전통적인 스트리머 워크플로우를 설명합니다; 런타임 가상 텍스처링과 스트리밍 가상 텍스처링은 각각 타일 제작, 피드백, 재질, 캐시, 플랫폼 고려사항을 도입합니다. 단 하나의 일반 풀 경고가 나타났다고 해서 가상화 텍스처링을 활성화하지 마십시오.
가상 텍스처링은 워크로드에 매우 큰 표면, 레이어드 랜드랜스 데이터, 또는 타일 접근 패턴이 전체 MIP 레지던시보다 더 적합할 수 있는 텍스처 세트를 포함하는 경우 별도의 평가가 가치가 있습니다. 평가에는 재질 호환성, 타일 업로드 동작, 캐시 압력, 시각적 지연, 쿡 크기, 타겟-플랫폼 지원, 셰이더 또는 샘플링 비용이 포함되어야 합니다. 백업 옵션을 유지하고 동일한 카메라 경로와 콘텐츠 수정 하에서 두 경로를 비교하세요.
문제가 중복된 4K 텍스처, 누락된 MIPS, 잘못된 압축 형식, 또는 부당한 Never Stream라면, 작업 부하를 변환해도 콘텐츠 오류를 해결하지 못하고 비용이 이동할 수 있습니다. 먼저 저작 문제를 해결하세요. 별도의 RVT 결정을 위해 별도의 Runtime Virtual Texturing guide를 사용하세요. 두 마이그레이션을 한 번에 섞어 문제 해결 패스를 진행하는 대신에요.
이미지 품질, 성능, 패키지 검증
합격 결과는 단순한 경고 이상의 것이 필요합니다. 반복 가능한 행렬을 실행하고 전후 증거를 유지하세요:
- 에디터 뷰포트: 캡처
STAT STREAMING, 참조 카메라 스크린샷, 풀과 비스트리밍 값. 경고가 설명되고 의도된 세부 사항이 안정적으로 유지되면 패스합니다. - PIE: 캡처 시작, 횡단, 텍스처 팝인, 프레임 페이싱. 게임 플레이 경로가 예산 내에서 늦은 미밌스(mips)가 허용되지 않는 경우에는 패스하세요.
- 독립 실행: 콜드 런치를 사용하고 대표성 결의로 경로를 반복하세요. 결과가 편집자 전용 웜 상태에 의존하지 않을 때는 패스합니다.
- 패키지 빌드: 각 하드웨어 클래스에서 개발 또는 테스트 빌드를 실행하세요. 풀 정책, 쿡 MIPS, 압축, 품질이 출하 구성과 일치하면 통과합니다.
- 스트레스 경로: 빠른 이동, 순간이동, 카메라 컷, 밀집된 장면, 또는 반복 지도 이동을 연습하세요. 피크가 예측 가능하게 회복되고 설명할 수 없는 거주 기간이 누적되지 않을 때 통과하세요.
GPU 메모리와 프레임 타임, 시각적 출력을 비교해 보세요. 낮은 풀은 거주 시간을 줄이지만 산만한 흐림이나 변화를 유발할 수 있습니다; 더 큰 풀은 경고를 억제하면서 나나이트, 루멘, 렌더링 타겟 또는 기타 GPU 자원의 헤드룸을 빼앗을 수 있습니다. 명시적인 헤드룸 요구사항을 설정하고 다른 렌더링 기능이 불안정해지면 테스트에 실패하세요.
프로젝트의 실제 화면 비율과 확장 가능성 계층을 검증하세요. 고정된 데스크톱 캡처는 콘솔, 노트북, 클라우드 스트리밍, 모바일 동작을 증명하지 않습니다. 플랫폼이 다른 카운터 집합을 노출하거나 CPU와 메모리를 공유한다면, 그 경계를 문서화하고 개별 GPU 예산을 기계적으로 변환하는 대신 해당 플랫폼의 네이티브 프로파일링 지침을 사용하세요.
흔히 실패한 해결책과 대신 해야 할 일들
"풀을 엄청난 가치로 설정하고 발송해라"
이렇게 하면 하드웨어가 안전한 여유가 있다는 것을 증명하지 않고도 경고를 숨깁니다. 더 큰 값은 통제된 실험으로만 사용하고, 측정된 패키지 빌드를 통해 플랫폼별 예산을 만드세요.
"DisableAllScreenMessage 실행"
화면 메시지 억제는 거주 기간이나 수리 콘텐츠를 줄이지 않습니다. 진단 시 경고를 유지하고, 측정된 예산 조건을 해결하거나 명시적으로 수용하세요.
"모든 텍스처를 가상 텍스처링으로 변환하기"
가상화된 타일은 다른 워크플로우와 실행 시간을 추가합니다. 한 풀 경고에 대한 전역 반응이 아니라 나란히 프로필을 통해 적절한 워크로드를 선택하세요.
"모든 텍스처를 다운스케일"
일괄 낮은 스케일링은 영웅 자산, UI, 시네마틱, 근거리 가독성에 손상을 줄 수 있습니다. 메모리 기여도와 예상 크기에 따라 자산을 순위 매기고, 그 후 가역 그룹 또는 자산별 결정을 내리세요.
"PIE에서는 통과하니 고정된 거야"
PIE는 편집기 상태를 재사용할 수 있으며, 조작된 데이터나 배송 프로필을 증명하지 않습니다. 콜드 독립 실행형 및 패키지 경로를 타겟 클래스 하드웨어에서 반복하세요.
팀 인계 체크리스트
- Unreal Engine 버전, 프로젝트 개정판, 대상 RHI, 장치 프로필, 화면 해상도, 확장성 계층.
- 실패하는 맵과 결정론적인 카메라 또는 게임 플레이 경로.
STAT STREAMING캡처 전후, 풀 및 비스트리밍 Mips 맥락 포함.- 텍스처, 소스 파일, 치수, MIP 설정, 압축, 그룹, 거주 플래그를 변경했습니다.
- 임시 콘솔 값은 지속적인 구성 변경과 분리되었습니다.
- 히어로, UI, 시네마틱, 접근성 자산에 대한 시각적 비교 포인트와 알려진 예외 사항.
- 모든 주장된 하드웨어 클래스에서 PIE, 독립 실행형, 패키지 빌드 결과가 나옵니다.
- 되돌려 수정하고 예산 결정을 다시 열게 하는 조건.
SEELE AI 핸드오프 및 제품 경계
새로운 개념의 경우,SEELE AI네이티브 언리얼 5 게임을 생성할 수 있고, 브라우저 미리보기를 제공하며, 최적화와 패키징을 지원하고, 프로젝트나 패키지된 결과물을 다운로드할 수 있게 제공할 수 있습니다. 그언리얼 게임 크리에이터그 창작 경로를 다루면서, 그리고언리얼 3D 에셋 최적화기Unreal로 가져오기 전에 내보낸 자산 검토를 지원해요.
이 새로운 프로젝트 워크플로우는 기존 프로젝트 문제 해결과는 별개입니다. 기존 프로젝트 텍스처 작업은 언리얼 팀의 몫입니다: 현재 .uproject를 열고 편집하고, DefaultEngine.ini 또는 장치 프로필을 변경하며, 가상 텍스처링 토글, 텍스처 자산 수정, STAT STREAMING 실행, 빌드 작업, 플랫폼 예산 검증 등이 포함됩니다. Unreal Engine는 Epic Games의 상표입니다; 이 독립 가이드는 Epic의 공식 승인을 의미하지 않습니다.
공식 출처 및 관련 언리얼 가이드
- 텍스처 스트리밍 구성은 Unreal Engine — 콘솔 변수와 풀 구성입니다.
- 텍스처 스트리밍 지표 Unreal Engine —
STAT STREAMING및 메모리/성능 지표. - 텍스처 스트리밍 개요 Unreal Engine — 기존 텍스처 스트리밍에 대한 1자 개요.
- Unreal Engine 렌더링 가이드 라이브러리 — 관련 렌더링, VFX 및 퍼포먼스 워크플로우.
- Unreal 런타임 가상 텍스처링 가이드 — 별도의 워크로드 결정으로 RVT를 평가하세요.
자주 묻는 질문
UE5에서 "텍스처 스트리밍 풀 초과 예산"이란 무엇을 의미하나요?
이는 텍스처 스트리머가 현재 뷰에 대해 설정된 풀이 허용하는 것보다 더 많은 메모리를 원한다는 뜻입니다. 스트리머 스스로 하나의 나쁜 텍스처를 식별하지 않습니다. STAT STREAMING 데이터를 캡처하고 스트리밍, 강제 수요, 비스트리밍 수요를 점검한 후, 근본 원인이 콘텐츠인지, 거주자 정책 문제인지, 아니면 진짜로 부족한 플랫폼 예산인지 판단하세요.
어떤 명령어가 Unreal Engine에서 텍스처 스트리밍 메모리를 표시하나요?
언리얼 콘솔에서 STAT Streaming을 사용하고, 고정된 카메라 또는 게임플레이 경로를 통해 경고를 재현하세요. 엔진 버전, RHI, 해상도, 확장성 티어, 맵, 빌드 아이덴티티가 포함된 완전한 캡처를 저장하세요. 카운터 레이아웃은 엔진 버전마다 다를 수 있으니, Epic 문서에 맞는 버전을 사용하세요.
r.Streaming.PoolSize를 늘리는 것이 유효한 해결책일까요?
패키지 빌드 측정 결과 최적화된 콘텐츠가 더 큰 풀이 필요하고 목표 하드웨어가 안전한 GPU 메모리 여유를 유지할 때 타당할 수 있습니다. 이 방법은 보편적인 해결책이 아닙니다. 임시로 가설을 검증한 후, 기기 간에 1메가바이트 값을 복사하는 대신 플랫폼별 영구 예산을 문서화하세요.
비스트리밍 MIP가 왜 높을까요?
높은 비스트리밍 MIP은 일반 스트리머가 자유롭게 줄일 수 없는 메모리를 가리킬 수 있으며, 여기에는 Never Stream 텍스처, 강제 거주, UI 텍스처, 큐브맵 또는 일부 플랫폼에서 풀에 포함된 기타 할당 등이 포함됩니다. 기여하는 자산과 자원 유형을 추적한 후, 풀을 늘리거나 관련 없는 스트리밍 텍스처를 줄이기 전에 반드시 추적하세요.
풀 경고를 제거하려면 Virtual Texturing을 활성화해야 할까요?
자동으로 되지 않아. 버추얼 텍스처링은 별도의 타일드 레지던시 워크플로우로, 머티리얼, 캐시, 피드백, 쿠킹, 셰이더, 플랫폼 간 트레이드오프가 있어. 먼저 누락된 밉맵, 너무 큰 소스 맵, 잘못된 압축이나 텍스처 그룹, 그리고 정당하지 않은 강제 레지던시를 고쳐. 실제로 타일드 액세스에서 이득이 있는 워크로드에만 버추얼 텍스처링을 비교해 봐.
배송 전에 텍스처 스트리밍 수정을 어떻게 검증하지?
각 주장된 하드웨어 클래스에서 에디터, PIE, 스탠드얼론, 패키지 빌드에서 동일한 대표 경로를 반복해 봐. STAT STREAMING, 총 GPU 메모리, 프레임 페이싱, 텍스처 선명도, 팝인, 콜드 로드 동작, 카메라 컷이나 이동 후 회복을 비교해. 롤백 가능한 리비전과 문서화된 헤드룸 요구사항을 유지해.


