템포럴 슈퍼 해상도(Temporal Super Resolution, TSR) 는 언리얼 엔진이 아름다운 4K 이미지를 렌더링할 수 있도록 해 주며 플랫폼에 구애받지 않는 템포럴 업스케일러입니다. 템포럴 슈퍼 해상도는 비용이 높은 렌더링 계산 일부를 여러 프레임으로 나눠서 감당하므로 이미지에 드는 비용이 크게 줄어듭니다. TSR은 언리얼 엔진 4의 템포럴 안티 에일리어싱 업샘플링(Temporal Anti-Aliasing Upsampling, TAAU)보다 낮은 내부 해상도를 렌더링함으로써 이를 실현합니다.
TSR은 차세대 게임의 수요를 충족하는 네이티브 고퀄리티 업샘플링 기법으로, 나나이트 지오메트리에 요구되는 충실도와 디테일을 구현할 뿐만 아니라 훨씬 낮은 해상도로 프레임을 렌더링하여 루멘의 퍼포먼스를 충분히 수용할 수 있습니다.
아래 비교에서는 네이티브 4K 해상도로 렌더링된 프레임과 1080p 해상도에서 렌더링되어 4K로 업스케일링된 프레임 간의 퀄리티 및 퍼포먼스 차이가 나타납니다. TSR을 활용하면 GPU 프레임 시간을 절반으로 줄이면서도 4K 해상도에 근접한 이미지 퀄리티를 구현할 수 있습니다.


두 이미지는 모두 4K 이미지입니다. 완전한 비압축 해상도를 비교하고 싶다면 각 이미지를 우클릭하여 컴퓨터에 저장하세요.
템포럴 슈퍼 해상도의 특징은 다음과 같습니다.
- 1080p의 낮은 입력 해상도로 네이티브 4K 퀄리티에 가깝게 프레임을 렌더링합니다.
- 높은 주파수의 배경에 발생하는 '고스팅' 아티팩트가 언리얼 엔진 4의 디폴트 안티 에일리어싱 방식인 템포럴 안티 에일리어싱에 비해 적습니다.
- 나나이트로 렌더링한 지오메트리와 같이 복잡도가 높은 지오메트리에서 깜빡임 현상이 감소합니다.
- 콘솔 플랫폼에서 다이내믹 해상도 스케일링을 지원합니다.
- PlayStation 5 및 Xbox Series S | X GPU 아키텍처에 맞게 최적화된 셰이더가 탑재된 D3D11, D3D12, Vulkan, Metal, PlayStation 5, Xbox Series S | X를 지원하는 모든 하드웨어에서 실행됩니다.
렌더링 체인에서 템포럴 슈퍼 해상도는 뎁스 오브 필드 후에 발생하며, 모션 블러, 블룸 등 이후에 오는 모든 렌더링 대상이 업스케일링됩니다.

지원 플랫폼
TSR은 셰이더 모델 5 이상을 지원하는 모든 데스크톱 하드웨어의 데스크톱 렌더러에서 사용할 수 있습니다. 여기에는 다음 플랫폼에 대한 지원이 포함됩니다.
- Windows D3D11 SM5, D3D12 SM5 및 SM6, D3D12 SM6, Vulkan SM5 및 SM6
- Linux Vulkan SM5 및 SM6
- Mac Metal SM5 및 SM6
- PlayStation 5 및 Xbox Series S | X
TSR의 업스케일링 퀄리티 및 동작은 모든 지원 플랫폼에서 정확히 동일합니다. 그러나 TSR은 PlayStation 5 및 Xbox Series S | X 콘솔에 사용되는 AMD RDNA GPU에 맞게 최적화되어 16비트 타입 및 패킹된 인스트럭션을 활용합니다.
TSR 엔진 퀄리티
TSR의 업스케일링 세팅에는 수많은 커스터마이징 옵션이 포함되어 있어, 프로젝트의 요구사항에 따라 개별 플랫폼에 맞게 설정할 수 있습니다. 다음 섹션에서는 프로젝트의 TSR을 확인한 다음 적절하게 스케일 조절하는 몇 가지 방법을 다룹니다.
디테일의 템포럴 누적에 대한 주의사항 이해하기
일반적으로 모든 템포럴 업스케일러는 기능의 필수적인 부분을 사용하는 것으로 타협할 수밖에 없으며, TSR 역시 예외는 아닙니다. 하지만 낮은 해상도로 렌더링함으로써 프레임 레이트가 증가한다는 것만으로는 TSR의 작동 및 제한 사항을 충분히 설명할 수 없습니다. 템포럴 업스케일링 기술의 그러한 제한 사항 중 하나는 시간 경과에 따라 더 낮은 해상도의 프레임을 누적하여 한 이미지로 수렴하면, 일부 디테일(예: 첫 번째 프레임에 있는 어떤 지오메트리 조각의 두께)은 디테일이 충분히 누적되고 난 후에야 알 수 있다는 것입니다.
예를 들어, TSR이 활성화 및 비활성화된 아래 비교에서는 프레임이 시간 경과에 따라 누적될 때 근거리 및 원거리에서 씬에 유지되는 디테일의 양을 확인할 수 있습니다.


이 예시에서 TSR이 활성화된 스크린샷의 경우 스크린 퍼센티지는 61로 설정되었으며, 세컨더리 업스케일( r.Test.SecondaryUpscaleOverride
)은 4로 설정되었습니다.
프레임의 렌더링 해상도는 스크린 퍼센티지(Screen Percentage) 로 제어합니다. 스크린 퍼센티지는 각 프레임에 사용 가능한 정보의 양을 제어하며, 수렴에 필요한 나머지 정보는 해당 프레임의 렌더링되어야 하는 남은 부분에 따라 다릅니다. TSR은 렌더링되는 프레임의 해상도와 프레임 레이트에 따라 다릅니다. 둘 모두 디테일이 누적되는 속도에 영향을 줍니다. 이 동작의 주된 영향은 TSR이 GPU 외에도 CPU에 의한 프레임 바운드, 주사율이 고정된 모니터의 수직동기 등의 다른 요소에 영향을 받을 수 있다는 것입니다.
에디터에서 작업하는 동안, TSR 프레임 레이트 통계를 사용하여 전체 이미지로 수렴하는 TSR의 누적 작업에 영향을 미치는 요소를 확인할 수 있습니다. 뷰포트 옵션(Viewport Options) 메뉴의 통계(Stat) > 엔진(Engine) 에서 TSR 옆의 체크박스를 설정하면 됩니다.

또는 콘솔 명령 stat tsr
로 TSR 통계를 토글하여 끄고 켤 수 있습니다.
TSR 통계는 프레임 정보를 표시하는 stat unit
등 다른 통계 명령과 비슷한 정보를 표시하며, 여기에 TSR feed 및 TSR 1spp 라는 2가지 통계가 추가되었습니다.

TSR feed 는 TSR에 피딩되는 초당 메가픽셀 수를 표시하며, 이는 TSR이 전체 이미지로 수렴해야 하는 데이터의 양을 파악하는 중요한 거시적 지표입니다. 이 값은 Rendering Resolution Width * Rendering Resolution Height * FrameRate = Display Resolution Width * Display Resolution Height * ScreenPercentage^2 * FrameRate
입니다. 이 지표의 장점은 디스플레이 해상도와 관계없이 모션의 거시적 이미지 퀄리티를 나타낸다는 것입니다.
아래 표는 TSR의 스케일 피딩 방식을 나타냅니다.
디스플레이 해상도 | 스크린 퍼센티지 | 프레임 레이트 | TSR 피드(MP/s) |
---|---|---|---|
4k(3840x2160) | 50% | 60hz | 38402160(50/100)^2*60 = 124.4MP/s |
4k(3840x2160) | 58% | 60hz | 167.4MP/s |
4k(3840x2160) | 66% | 60hz | 216.7MP/s |
4k(3840x2160) | 50% | 30hz | 62.2MP/s |
4k(3840x2160) | 72% = 50% x sqrt(2) | 30hz | 124.4MP/s |
1080p (1920x1080) | 100% | 60hz | 124.4MP/s |
1080p (1920x1080) | 72% = sqrt(0.5) | 60hz | 62.2MP/s |
1080p (1920x1080) | 50% | 60hz | 31.1MP/s |
TSR 1spp 는 TSR의 수렴률, 즉 TSR이 하나의 픽셀당 샘플에 도달할 충분한 데이터를 보유하기 위해 필요한 시간입니다. 이는 디테일을 빠르게 누적해야 하는 디스오클루전이 있는 모션에서 특히 중요합니다. 구현 공식은 TSR1spp = 1000 / (ScreenPercentage^2 * FrameRate)
입니다.
아래 표는 TSR 1spp의 수렴을 나타냅니다.
스크린 퍼센티지 | 프레임 레이트 | TSR 수렴률 |
---|---|---|
50% | 60hz | 1000 / ((50/100)^2 * 60) = 66.6ms |
58% | 60hz | 49.5ms |
66% | 60hz | 38.2ms |
100% | 60hz | 16.6ms |
50% | 30hz | 133.3ms |
스크린 퍼센티지가 50으로 설정된 상황이라고 가정하고 이 데이터를 사용해 보겠습니다. 이는 적어도 하나의 픽셀당 샘플에 (50/100)^-2 = 4프레임이 필요하다는 뜻입니다. 각 프레임을 렌더링하는 데 16.6밀리초(ms)가 소요된다고 하면, 화면의 디스오클루전 영역이 충분한 데이터를 보유하기까지는 4배 더 긴 시간, 즉 66.4ms가 걸린다는 것을 의미합니다.
업스케일링 GPU 비용
TSR의 주요 목표는 업스케일링입니다. GPU 작업의 대부분은 제공된 해상도를 기반으로 스케일이 조절됩니다. 이는 TSR이 렌더링 해상도보다 높은 디스플레이 해상도에서 수행되어야 할 때의 일부 GPU 비용 때문입니다.
에디터에서 작업하는 TSR 프레임 레이트 통계를 사용하여 전체 이미지로 수렴하는 TSR의 누적 작업에 영향을 미치는 요소를 확인할 수 있습니다. 뷰포트 옵션 메뉴의 통계 > 고급(Advanced) 에서 GPU 옆의 박스에 체크하면 됩니다.

GPU 통계가 표시된 상태에서 스크린 퍼센티지를 100 과 50 으로 설정하여 렌더링했을 때의 퍼포먼스 차이를 확인하기 위해, 뷰포트 옵션 메뉴에서 스크린 퍼센티지 를 오버라이드할 수 있습니다. 이를 통해 업스케일링된 디스플레이 해상도가 프로젝트의 퍼포먼스에 어떤 영향을 미칠지 알 수 있습니다. 아래 예시는 에인션트의 협곡 샘플 프로젝트를 사용하여 이를 비교한 것입니다.
r.ScreenPercentage=100에서 ~0.79ms | r.ScreenPercentage=50에서 ~0.43ms |
이미지를 클릭하면 원본 크기로 볼 수 있습니다.
TSR의 패럴랙스 휴리스틱은 프레임의 씬 컬러 및 반투명보다는 뎁스 및 속도 버퍼에 따라 다릅니다. 이는 뎁스 및 속도 버퍼가 씬 컬러 및 반투명 버퍼보다 GPU에서 훨씬 빨리 완료되는 경우가 많기 때문입니다. 이로 인해 전체 TSR 패럴랙스 휴리스틱이 GPU에서 비동기적으로 계산을 수행하고 GPU가 잘 사용되지 않는 갭을 r.TSR.AsyncComputer=1
로 다른 렌더링 알고리즘을 통해 채울 수 있습니다.
예를 들어 PlayStation 5 및 Xbox Series X의 포트나이트 챕터 4에서는 전체 배틀로얄 퍼포먼스 리플레이의 퍼포먼스를 테스트했을 때 TSR 비동기 연산에서 TSR의 총 GPU 비용 중 약 0.5ms가 상쇄되었습니다. 약 0.1ms가 절약되었고, 효율적인 TSR 비용이 1.5ms로 절감되었으며, 프레임 렌더링을 완료하는 필수 경로 GPU 비용은 1.1ms로 절감되었습니다.

안티 에일리어싱 엔진 퀄리티 그룹
TSR의 GPU 비용은 스크린 퍼센티지로 렌더링되는 화면 해상도를 통해 조절됩니다. TSR은 SM5 이상을 지원하는 모든 GPU에서 작동하지만, 구버전 저사양 GPU의 경우 어느 정도의 GPU 런타임 비용을 필요로 합니다. 이는 TSR을 다른 타사 템포럴 업스케일링 솔루션과 차별화하는 한 가지 요소입니다. 즉, 사용자 대상 엔진 퀄리티 컨트롤을 제공해 주므로, 화면 렌더링 해상도와는 독립적으로 업스케일링, 안티 에일리어싱 퀄리티, 런타임 GPU 비용을 제어할 수 있습니다. 엔진 퀄리티 세팅(Engine Scalability Settings) 은 이러한 엔진 퀄리티 옵션의 베이스라인을 제공합니다.
아래 그래프는 화면의 렌더링 해상도 및 안티 에일리어싱 퀄리티가 TSR이 수행하는 업스케일링 타입을 결정하는 방식을 보여줍니다. 스크린 퍼센티지가 낮으면 극단적인 업스케일링이 필요하지만, 최종적으로는 보다 비용 효율적입니다. 반면 스크린 퍼센티지가 100% 이상이고 엔진 퀄리티 레벨이 높음(High) 이상인 경우, 슈퍼 샘플링되어 GPU 비용이 이를 기점으로 증가합니다.

스크린 퍼센티지가 50% 미만인 극단적인 업스케일링은 콘솔 플랫폼의 다이내믹 해상도 등 4K보다 높은 디스플레이 해상도를 목표로 하는 예외적인 경우에만 고려해야 합니다.
TSR은 세팅(Settings) > 엔진 퀄리티 세팅 에 위치한 엔진 퀄리티 그룹(Scalability Groups) 롤아웃의 안티 에일리어싱(TSR)(Anti-Aliasing (TSR)) 엔진 퀄리티 그룹에서 제어합니다.

에디터에서 플레이(Play-In-Editor) (PIE)를 사용하는 동안, 엔진 퀄리티 세팅은 에디터에서 플레이 3D 해상도(Play-In-Editor 3D Resolution) 아래에 화면 해상도, 스크린 퍼센티지, 사용 중인 활성 뷰포트 등의 정보를 표시합니다. PIE에서 아래의 슬라이더 또는 버튼을 사용하여 퍼포먼스, 밸런스, 퀄리티, 네이티브 해상도에 따라 스크린 퍼센티지를 자동으로 조정할 수 있습니다.

에디터 뷰포트에는 뷰포트 옵션 메뉴의 스크린 퍼센티지 세팅으로 제어되는 자체적인 렌더링 해상도가 있습니다. 커스텀 오버라이드(Custom Override) 체크 박스를 활성화하여 자체 스크린 퍼센티지를 설정하세요.

또는 콘솔에서 sg.AntiAliasingQuality
로 사용하여 안티 에일리어싱 엔진 퀄리티 그룹을 설정할 수 있습니다. 이 경우 0 = 낮음, 1 = 중간, 2 = 높음, 3 = 에픽, 4 = 시네마틱 퀄리티입니다.
[Unreal Engine Root]/Engine/Config
폴더의 환경설정 파일 BaseScalability.ini 에 모든 엔진 퀄리티 그룹 세팅 목록이 포함되어 있습니다. 사용되는 안티 에일리어싱 퀄리티 그룹에 따라 TSR이 어떻게 스케일링되는지 확인하려면 AntiAliasingQuality
섹션을 살펴보면 됩니다. 각 그룹에는 콘솔 변수 및 값의 목록이 포함되어 있습니다.
프로젝트의 [Your Project Root]/Config
폴더에 DefaultScalability.ini 로 명명된 자체 환경설정 파일이 포함되어 있습니다. 이러한 콘솔 변수를 프로젝트의 요구사항에 맞게 수정할 수 있습니다.
다음은 BaseScalability.ini 파일의 높음 안티 에일리어싱 퀄리티 값의 예시입니다.
[AntiAliasingQuality@3]
r.FXAA.Quality=4
r.TemporalAA.Quality=2
r.TSR.History.R11G11B10=1
r.TSR.History.ScreenPercentage=200
r.TSR.History.UpdateQuality=3
r.TSR.ShadingRejection.Flickering=1
r.TSR.RejectionAntiAliasingQuality=2
r.TSR.Resurrection=1
언리얼 엔진의 GPU 프로파일러인 DumpGPU와 같은 GPU 디버거나 타사 디버거를 사용하여 TSR의 안티 에일리어싱 그룹화를 검사할 수 있습니다. 선택된 AntiAlaisingQuality 그룹에는 Scene > PostProcessing > TemporalSuperResolution 에서 찾을 수 있는 드로 이벤트의 렌더링 및 디스플레이 해상도가 포함되어 있습니다.
GPU 프로파일러 | DumpGPU 뷰어 |
이미지를 클릭하면 원본 크기로 볼 수 있습니다.
뷰포트의 표시(Show) > 시각화(Visualize) 메뉴에서 VisualizeTemporalUpscaler 표시 플래그를 사용할 때, 좌측 하단 시각화에 입력 및 출력과 현재 사용되고 있는 AntiAliasingQuality 그룹이 표시됩니다.

원하는 경우 자체적인 안티 에일리어싱 엔진 퀄리티 그룹을 추가하여 별도의 세팅으로 노출할 수 있습니다. 다른 안티 에일리어싱 옵션과 TSR 세팅을 구별하는 한 가지 방법은 괄호를 추가하여 사용 중인 방식을 나타내는 것입니다.

자체 프로젝트의 경우 이를 추가적으로 구별하는 것이 좋습니다. 예를 들어 포트나이트에서는 여러 안티 에일리어싱 방식이 지원됩니다. TSR 세팅에서는 낮음, 중간, 높음, 에픽 퀄리티 세팅에 따라 선택 항목이 달라집니다. 또한 유저 인터페이스에 노출되는 몇 가지 추가 파라미터도 있습니다.

템포럴 업스케일링의 숨겨진 GPU 비용
TSR은 다른 템포럴 업스케일러와 마찬가지로 포스트 프로세싱 렌더 체인 중간에서 발생합니다. 즉, 모션 블러, 톤매퍼 등 TSR 이후 실행되는 패스는 더 이상 프라이머리 스크린 퍼센티지로 스케일 조절되지 않습니다. 스페이셜 업스케일러( r.SecondaryScreenPercentage.GameViewport
)를 사용하는 세컨더리 스크린 퍼센티지가 없으면 TSR의 출력 해상도는 스크린 퍼센티지로 설정된 렌더링 해상도가 아니라 디스플레이 해상도로 실행됩니다.
이러한 사실과 기본적으로 활성화된 TSR로 인해, TSR 이후 발생하는 패스의 숨겨진 템포럴 업스케일링 비용을 줄이는 데 많은 노력이 필요합니다.
TSR 사용 시 모션 블러 최적화
여러 가지 모션 블러 최적화 방식을 결합하여 사용하면 낮은 해상도의 TV에서도 항상 2160p 백버퍼를 표시하는 PlayStation 5 및 Xbox Series X 등의 플랫폼에서 3배에 달하는 모션 블러 GPU 퍼포먼스 비용 개선 효과를 실현할 수 있습니다. 그러므로 이 점을 고려하면 다음 사항을 기대할 수 있습니다.
stat gpu
사용 시 TSR 비용 증가:- 비교를 위해 모션 블러를 켜고 끌 때
stat gpu
에서 TSR 비용이 약간 증가할 수 있습니다. - 모션 블러가 활성화된 경우 일반적으로 입력 해상도에서 실행되는 속도 평탄화(Velocity Flatten) 패스를 TSR이 대체합니다. 이는 기본적으로 활성화된 콘솔 명령
r.MotionBlur.AllowExternalVelocityFlatten
을 사용하여 제어할 수 있습니다. - TSR은 1/2 해상도의 씬 컬러를 출력하여 대규모 디렉셔널 모션 블러 커널에서 발생하는 메모리 대역폭의 병목 현상을 줄여줍니다. 이는 기본적으로 활성화된
r.MotionBlur.HalfResInput
을 사용하여 제어할 수 있습니다.
- 비교를 위해 모션 블러를 켜고 끌 때
- 디렉셔널 블러의 1/2 해상도:
- 디렉셔널 블러가 디스플레이 해상도로 발생할 때 매우 큰 움직임의 경우 1/2 해상도로 자동 실행됩니다. 이 기능을 활성화하면 모션 블러의 VALU 비용이 줄어듭니다.
- 콘솔 명령
r.MotionBlur.HalfResGather 1
을 사용하면 1/2 해상도가 활성화됩니다.
- 모션 블러 1/2 해상도 및 1/4 해상도:
- TSR 및 모션 블러가 1/2 또는 1/4 해상도를 출력할 수 있습니다. 모션 블러 패스 뒤에 실행되는 가우시안 뎁스 오브 필드, 컨볼루션 블룸, 렌즈 플레어, 시각 적응(자동 노출), 로컬 노출에 중요합니다.
포스트 프로세스 퀄리티(Post Process Quality) 엔진 퀄리티 그룹은 언급된 모션 블러 값 중 일부를 스케일 조절합니다. [엔진 루트]/Engine/Config 폴더에 위치한 BaseScalability.ini 환경설정 파일에서 이러한 값이 어떻게 설정되어 있는지 확인할 수 있습니다.
템포럴 슈퍼 해상도 디버깅 툴
TSR은 순수한 이미지 프로세싱 기법이라는 것이 주된 장점입니다. 이는 모든 입력 및 출력이 눈에 보이는 이미지로, 기본 시각화 툴인 DumpGPU 뷰어나 RenderDoc, PIX와 같이 널리 알려진 플랫폼 GPU 디버깅 툴에서 확실하게 볼 수 있다는 것을 의미합니다.
템포럴 업스케일러 입력 및 출력 시각화
템포럴 업스케일링에 영향을 미치는 아티팩트를 진단해야 하는 경우가 있습니다. 이때 템포럴 업스케일러(Temporal Upscaler) 표시 플래그를 사용하면 됩니다. 시각화 툴에는 원시 입력 및 출력 버퍼가 이러한 아티팩트 진단을 위한 시작점으로 표시됩니다.
표시 > 시각화 에서 템포럴 업스케일러 I/O(TSR, TAAU 또는 서드 파티 플러그인)(Temporal Upscaler I/O (TSR, TAAU, or third party plugins)) 를 선택하여 뷰포트에 이 표시 플래그를 활성화할 수 있습니다.

안티 에일리어싱(TSR) 그룹 퀄리티를 '높음'으로 설정한 템포럴 업스케일러 시각화 모드
자세한 내용은 템포럴 업스케일러를 참조하세요.
TSR 시각화
템포럴 슈퍼 해상도 시각화는 특정 문제를 진단하는 데 가장 유용한 TSR 개요를 표시합니다. 이 시각화 모드는 TSR의 내부 작동 방식과 TSR이 이미지를 안정화하기 위해 수행하는 작업을 이해하는 데 좋은 시작점이 되어주기도 합니다.
뷰포트 표시 > 시각화 메뉴에서 템포럴 슈퍼 해상도 를 선택하여 이 표시 플래그에 액세스할 수 있습니다.

안티 에일리어싱(TSR) 그룹 퀄리티를 '높음'으로 설정한 TSR 시각화 모드
시각화 내 컬러는 다음과 같은 의미가 있습니다.
- 분홍색: 비활성화됨
- 노란색/빨간색: 이미지 퀄리티에 안 좋은 영향을 미침
- 녹색: 이미지 퀄리티에 좋은 영향을 미침
템포럴 슈퍼 해상도 표시 플래그는 다양한 시각화 옵션에 대한 개요를 제공합니다. 콘솔 명령 r.TSR.Visualize
를 사용하고 다음 값 중 하나를 입력하여 이러한 뷰 중 하나를 선택할 수 있습니다.
- -2 는 뷰포트의 표시 메뉴에서 표시 플래그가 어떻게 설정되어 있는지와 관계없이 개요 그리드 VisualizeTSR 시각화를 표시합니다.
- -1 은 뷰포트의 표시 메뉴에서 표시 플래그가 어떻게 설정되어 있는지에 따라 VisualizeTSR의 개요 그리드를 표시합니다.
- 0 은 히스토리에 누적된 샘플의 수를 표시합니다.
- 1 은 뎁스 및 속도 버퍼에 따른 패럴랙스 디스오클루전을 표시합니다.
- 2 는 히스토리가 거부되는 마스크를 표시합니다.
- 3 은 히스토리가 범위제한되는 마스크를 표시합니다.
- 4 는 히스토리가 리저렉션되는 마스크를 표시합니다.
- 5 는 리저렉션된 프레임에서 히스토리가 리저렉션된 마스크를 표시합니다.
- 6 은 스페이셜 안티 에일리어싱이 계산되고 있는 마스크를 표시합니다.
- 7 은 깜빡임 템포럴 분석 휴리스틱 기법이 영향을 미치는 마스크를 표시합니다.
DumpGPU 뷰어
DumpGPU는 기본으로 제공되며 플랫폼과 무관한 중간 GPU 리소스 뷰어입니다. TSR은 주로 이미지를 처리하므로 DumpGPU는 여러 프레임에 걸쳐 TSR 아티팩트를 진단하는 데 적합합니다. 최소한의 구성으로 콘솔 (`)에서 바로 DumpGPU를 사용하여 TSR의 중간 렌더 타깃을 검사할 수 있습니다. 이를 위해 다음 명령을 사용할 수 있습니다.
콘솔 명령 | 설명 | 사용할 값 |
---|---|---|
r.DumpGPU.Root |
GPU 덤프를 GPU 패스로만 제한합니다. | “TemporalSuperResolution” |
r.DumpGPU.FrameCount |
다수의 연속 프레임을 덤프합니다. 여러 프레임에 걸쳐 결과를 누적하므로 TSR 문제를 진단하는 데 유용합니다. | 30 |
r.DumpGPU.Stream |
덤핑 프로세스 속도를 높이기 위해 GPU에서 디스크로 리소스를 비동기적으로 스트리밍합니다. | 1 |
r.DumpGPU.FixedTickRate |
덤핑 프로세스로 인해 프레임 레이트가 느려지는 경우 엔진 틱 속도를 원하는 프레임 레이트로 고정합니다. t.MaxFPS 가 작동하는 방식과 유사합니다. |
30 |
r.DumpGPU. Delay |
덤핑 프로세스를 몇 초 딜레이하여 게임플레이 로직 관련 아티팩트를 재현할 시간을 확보합니다. | 3 |
r.DumpGPU.CameraCut |
처음 덤프된 프레임에 카메라 컷을 발행합니다. 선택사항으로, DumpGPU 관련 문제를 진단합니다. | 1 |
선택사항으로, 이러한 명령을 프로젝트의 ConsoleVariables.ini 파일로 복사할 수 있습니다.
r.DumpGPU.Root="*TemporalSuperResolution*"
r.DumpGPU.FrameCount=30
r.DumpGPU.Stream=1
; t.MaxFPS와 마찬가지로, 덤핑 프로세스로 인해 프레임 레이트가 느려지는 경우 엔진 틱 속도를 원하는 프레임 레이트로 고정합니다.
r.DumpGPU.FixedTickRate=30
r.DumpGPU.Delay=3
r.DumpGPU.CameraCut=1
검사할 TSR의 중간 렌더 타깃을 통해 프레임을 앞뒤로 재생하여 캡처된 프레임에서 아티팩트가 어떻게 진전되는지 확인할 수 있습니다.

콘솔에 r.ResetRenderTargetsExtent
를 입력하여 렌더러의 내부 렌더 타깃이 렌더링 해상도에 맞춰지도록 덤프 GPU 스트리밍의 속도를 높일 수 있습니다. 이는 스크린 퍼센티지로 렌더링 해상도를 변경할 때 유용합니다. 또한 다이내믹 해상도가 활성화되어 있을 때 렌더링 해상도를 r.DynamicRes.TestScreenPercentage
로 고정할 수 있지만, 내부 렌더 타깃 크기는 여전히 r.DynamicRes.MaxScreenPercentage
로 제어된다는 점에 유의하세요.
에픽에 버그 리포트를 제출하거나 TSR 문제 관련 도움을 요청하는 경우, 파일 업로드를 위해 덤프 디렉터리를 압축하려면 압축된 7-zip(*.7z) 파일이 가장 적합합니다.
TSR의 컴포넌트
TSR은 현세대 콘솔에서 구현 가능한 최고의 이미지 퀄리티를 얻기 위해 특정 문제를 해결하도록 설계된 다양한 알고리즘으로 구성되어 있습니다.
TSR이 사용하는 알고리즘은 다음과 같습니다.
- 히스토리(History) 는 프레임 간 디테일을 누적, 저장, 재사용하는 동작을 수행합니다.
- 패럴랙스 휴리스틱(Parallax Heuristics) 은 디스오클루전 시 이미지 퀄리티를 유지하면서 모션 벡터를 사용하여 히스토리를 재투영합니다.
- 셰이딩 거부(Shading Rejection) 는 컬러 변화 및 반투명을 탐지하며, 나나이트를 통해 프레임에 포함된 디테일 양과의 균형도 찾습니다.
- 깜빡임 템포럴 분석(Flickering Temporal Analysis) 은 일부 지오메트리의 무아레 패턴과 같은 아티팩트를 줄여 프레임을 안정화합니다.
- 히스토리 리저렉션(History Resurrection) 은 현재 프레임에 이전 프레임이 다시 표시될 때 이전 프레임에서 저장된 데이터를 다시 호출합니다.
아래 차트를 통해 이러한 알고리즘이 모두 TSR의 프레임 출력에 어떻게 피딩되는지 알 수 있습니다.

다음 섹션에서는 위에 나와 있는 이러한 개별 알고리즘과 템포럴 업스케일러 및 템포럴 슈퍼 해상도 시각화 모드와의 작동 방식을 살펴보겠습니다.
TSR 히스토리
이는 모든 TSR 안티 에일리어싱 엔진 퀄리티에서 필수이지만, r.TSR.History.*
콘솔 명령으로 커스터마이징할 수 있습니다.
TSR은 시간 경과에 따라 디테일을 누적합니다. 이렇게 시간 경과에 따라 렌더링된 디테일의 수집 및 통합은 디스플레이 해상도로 히스토리에서 이루어집니다. TSR에는 또한 TSR의 내부 알고리즘별 히스토리 내 숨겨진 추가 데이터도 포함되어 있습니다.

시간 경과에 따라 렌더링된 프레임에서 수집된 디테일이 누적되어 TSR 히스토리를 구성합니다.
TSR 시각화 모드를 사용할 때 히스토리에 누적되는 디테일의 양이 Accumulated Sample Count 입력의 좌측 상단에 표시됩니다. 이미지가 녹색에 가까울수록 더 많은 디테일이 누적된 것입니다. 빨간색 영역은 누적되는 픽셀의 양이 충분하지 않다는 뜻인 반면, 녹색 영역은 히스토리별 최대 샘플 수에 도달했다는 뜻입니다. 히스토리별 샘플 수는 r.TSR.History.SampleCount
로 필요에 맞게 조정할 수 있습니다.

Accumulated Sample Count 입력을 전체화면으로 보려면 콘솔 명령 r.TSR.Visualize 0
을 사용하세요. TSR 시각화 옵션에 대한 자세한 내용은 이 페이지의 TSR 시각화 섹션을 참조하세요.
히스토리 업데이트(History Update) 는 히스토리가 디스플레이 해상도로 렌더링되기 때문에 TSR의 총 GPU 비용에서 가장 비용이 많이 드는 패스입니다.

TSR의 히스토리 업데이트에는 선택 가능한 순열이 포함되어 있으며, 콘솔 명령 r.TSR.UpdateHistory
사용 시 0은 낮음, 1은 중간, 2는 높음, 3은 에픽 퀄리티입니다. 이러한 퀄리티 레벨은 안티 에일리어싱(TSR) 엔진 퀄리티 그룹 퀄리티 세팅에 의해 구동됩니다. 각 퀄리티 레벨의 제공 사항에 대한 자세한 내용은 [Unreal Engine Root]/Engine/Shaders/Private
에 위치한 TSRUpdateHistory.usf 파일의 DIM_UPDATE_QUALITY
를 참조하세요. 여기에서 검사하여 프로젝트의 요구사항에 맞춰 커스터마이징할 수 있습니다.

GPUDump 뷰어에 표시된 대로 안티 에일리어싱 엔진 퀄리티가 '높음'으로 설정된 TSR UpdateHistory를 보여주는 예시
r.TSR.History.ScreenPercentage=100
일 때 히스토리 재투영 블러를 해결하려면 r.TSR.Velocity.WeightClampingSampleCount
로 디테일 누적을 다시 가속화하는 것이 좋습니다. 예를 들어 포트나이트와 같이 경쟁적인 성격의 게임은 프로젝트의 DefaultEngine.ini 환경설정 파일 내 r.TSR.Velocity.WeightClampingSampleCount
를 4.0(디폴트)에서 2.0으로 낮춰 선명도를 위해 움직임 중에 이미지 안정성을 어느 정도 희생하여 이점을 얻을 수 있습니다.
TSR Nyquist-Shannon 히스토리
에픽 및 시네마틱 TSR 안티 에일리어싱 엔진 퀄리티 레벨에서 기본적으로 활성화됩니다. 콘솔 변수 r.TSR.History.ScreenPercentage
로 제어 가능합니다.
시중의 다른 템포럴 업스케일러와 마찬가지로, 이론상 잘 작동할 경우 TSR은 즉시 사용 가능한 이미지로 이미 수집된 지오메트릭 및 텍스처 디테일이 있는 이전 프레임의 히스토리를 재투영합니다.

실제로 움직임에 적용되면, 현재 프레임과 이전 프레임 사이의 픽셀이 정렬되지 않을 가능성이 있습니다. 그 대신 TSR을 비롯한 템포럴 업스케일러는 이전 프레임의 픽셀을 보간해야 하는데, 이로 인해 블러가 발생합니다. TSR은 이 커널에서 약간의 샤프닝 작업을 통해 픽셀의 과도한 블러를 완화하려고 시도하지만, 이 방법으로는 프레임에서 한 픽셀의 절반만큼만 움직이는 1픽셀 두께의 트랜스폼 디테일 문제를 해결할 수 없습니다. 이러한 제한 때문에 블러로 인한 디테일 손실이 훨씬 심해지며, 사후에 이러한 디테일을 복원하는 것이 불가능해집니다.

히스토리 재투영의 결과, 프레임에서 움직임이 발생하는 동안 템포럴 업스케일러는 1080p의 해상도로 표시할 때 540p의 해상도처럼 보일 수 있습니다. 이는 프레임에서 움직이는 요소의 블러로 인해 생긴 부정적인 평판을 한층 악화시킬 뿐입니다. 이 문제를 해결하기 위해 에픽 및 시네마틱 안티 에일리어싱 엔진 퀄리티 그룹은 TSR의 히스토리 스크린 퍼센티지( r.TSR.History.ScreenPercentage
)를 200으로 설정하며, 이는 TSR 히스토리를 디스플레이 해상도의 2배로 저장하기 위한 목적입니다.
이 접근법은 히스토리 재투영 중 발생하는 블러를 제거해 주는 장점이 있지만, Mitchell-Netravali 다운샘플링 커널을 통해 재투영이 Nyquist-Shannon 샘플링 정리에 의존하게 됩니다.

히스토리 재투영 중 발생하는 블러는 템포럴 업스케일러의 단점으로 알려져 있습니다. 이 문제를 해결하기 위해 높은 디폴트 히스토리 스크린 퍼센티지에서는 히스토리 업데이트의 GPU 비용이 4배 더 들어, TSR의 GPU 비용이 상당히 증가합니다. 이 접근법은 발생하는 비용으로 인해 직관적이지 않아 보일 수 있지만, 해상도 축을 따라 모니터의 디스플레이 해상도보다 2배 더 많은 정보를 제공한다는 개념에 기반합니다. 슈퍼 샘플링된 히스토리 업데이트가 다운샘플링되면, 히스토리에 높은 스크린 퍼센티지를 사용하지 않은 경우보다 훨씬 많은 디테일이 유지됩니다.

히스토리 스크린 퍼센티지가 200%일 때 TSR의 총 GPU 비용에 미치는 영향을 보여주는 그래프
프로젝트의 프레임 예산이 너무 많이 드는 것이 우려된다면, 에픽 안티 에일리어싱 엔진 퀄리티에 높은 GPU 비용이 수반되므로 높음 이하의 엔진 퀄리티 그룹을 사용하면 됩니다.
Nyquist-Shannon 히스토리 구성은 언리얼 엔진 4.22와 템포럴 안티 에일리어싱(TAA)을 사용한 2019년 굿바이 캔자스(Goodbye Kansas)와 딥 포레스트 필름스(Deep Forest Films)의 '트롤(Troll)' 데모까지 거슬러 올라가는 에픽의 자체 데모에서 사용되어 왔습니다. 이는 템포럴 업스케일러를 사용하는 에픽의 프로젝트를 위한 검증된 방식입니다.
패럴랙스 디스오클루전
모든 TSR 안티 에일리어싱 엔진 퀄리티 그룹에서 필수입니다.
TSR에는 패럴랙스 디스오클루전(Parallax Disocclusion) 휴리스틱 기법이 있습니다. 이 기법은 카메라와 더 가까운 프레임 영역 뒤에서 점차 보이는 프레임 영역에서 발생하는 아티팩트를 줄이는 데 도움이 됩니다. 예를 들면 아래 씬에서 카메라가 패닝 중이며, 먼 거리에 있는 건물이 더 가까운 건물 뒤에서 점차 보이게 됩니다. 이러한 타입의 디스오클루전은 이미지를 안정화하기 위해 멀리 있는 건물이 프레임에서 디테일을 누적해야 하므로 아티팩트를 유발할 수 있습니다.

엔진 퀄리티는 에픽(r.AntiAliasingMethod=4, sg.AntiAliasingQuality=3), 스크린 퍼센티지는 50%로 설정된 TSR
이러한 휴리스틱 기법은 볼 수 있는 템포럴 업스케일러 시각화 모드인 현재 프레임의 뎁스 및 속도 버퍼에 전적으로 기반합니다. 패럴랙스 디스오클루전 마스크는 이 버퍼에서 생성되며, 템포럴 슈퍼 해상도 시각화 모드에서 볼 수 있습니다.

TSR의 시각화 모드에서 디스오클루전 마스크 생성에 사용되는 템포럴 업스케일러 시각화 모드의 뎁스 및 속도 입력
일부 오브젝트의 모션 벡터가 씬의 각 코드 경로 처리 지오메트리에 의해 계산되고 드로되는 경우를 발견할 수도 있으며, 이로 인해 이러한 오브젝트에 영향을 미치는 문제가 발생할 수 있습니다. 발견할 경우, 올바르게 작동하지 않는 지오메트리에 의해 드로되는 모션 벡터에 대해 가장 먼저 확인할 컴포넌트는 TSR의 패럴랙스 휴리스틱 및 생성된 디스오클루전 마스크입니다.
이러한 타입의 문제를 조사하려면 다음 TSR 시각화를 사용하세요. 뷰포트의 표시 > 시각화 메뉴에서 토글하여 켤 수 있습니다.
- 모션 블러 (
Show VisualizeMotionBlur
)는 카메라가 이동할 때 모션 벡터를 화면상의 화살표로 표시합니다.- 화살표가 오브젝트에 맞게 올바른 방향인지 확인합니다.
- 문제의 오브젝트가 노란색인지 확인합니다. 이는 해당 오브젝트가 모션 벡터를 드로하고 있음을 나타냅니다.
- 이전 프레임의 재투영(Previous Frame's Reprojection) (
Show VisualizeReprojection
)은 현재 프레임과 재투영된 이전 프레임 간의 차이를 보여줍니다.- 올바르게 재투영되지 않는 오브젝트의 모션 벡터가 컬러로 표시되고, 해당 디테일이 올바르게 정렬되지 않습니다.
- 템포럴 업스케일러 I/O(Temporal Upscaler I/O) (
Show VisualizeTemporalUpscaler
)는 TSR 입력 및 출력의 개요를 보여줍니다. - 템포럴 슈퍼 해상도 패럴랙스 디스오클루전(Temporal Super Resolution Parallax Disocclusion) (
Show VisualizeTSR
)은 오브젝트 드로잉 속도 뒤에 있어야 하는 디스오클루전 비네트를 표시합니다.
애니메이션 월드 포지션 오프셋
버텍스 애니메이션에 월드 포지션 오프셋(World Position Offset, WPO)을 사용하는 머티리얼과 같이 애니메이션 파라미터가 있는 머티리얼은 TSR을 비롯한 렌더러의 템포럴 누적에 문제가 됩니다. 이러한 머티리얼 타입의 경우 WPO가 적절한 모션 벡터를 얻기 위해 현재 프레임과 이전 프레임을 평가해야 합니다. WPO 로직의 이전 프레임 평가에는 현재 프레임의 값만 있기 때문에, 이전 프레임 결과는 잘못된 것으로 평가됩니다. 속도를 드로하는 머티리얼의 경우, 이전 프레임의 값을 지정하는 것이 중요합니다.
Previous Frame Switch 머티리얼 노드는 TSR 및 모션 블러와 함께 작동하는 올바른 모션 벡터를 생성하는 방법을 제공하여 이 문제를 해결합니다. 이 노드는 버텍스 애니메이션에 모션 블러를 올바르게 추가하고 TSR이 이 과정에서 오브젝트를 올바르게 재투영하도록 합니다. 시간 함수만 있는 머티리얼은 수정 없이도 작동하지만, 런타임 시 애니메이션에 영향을 줄 수 있는 머티리얼 파라미터와 같은 다른 변수를 처리하지 못합니다. Previous Frame Switch 노드는 이러한 파라미터가 머티리얼에서 변경되는 방식을 추적하여 이런 유형의 문제를 해결합니다.

추가로 고려할 사항은 다음과 같습니다.
- 프로젝트 세팅 버텍스 디포메이션으로 인한 출력 속도(Output velocities due to vertex deformation) 는 WPO를 사용하는 머티리얼이 현재 및 이전 프레임에 대한 이중 평가를 사용하도록 합니다. 이 세팅은 액터가 움직이지 않을 때도 속도 패스 중에 속도를 출력하며, 기본적으로 활성화되어 있습니다.
- 프로젝트 세팅 속도 패스(Velocity Pass) 를 Write after base pass 로 설정하는 경우, 추가 드로 콜로 인해 퍼포먼스 비용이 발생할 수 있습니다. 퍼포먼스 비용은 나무로 가득 찬 숲처럼 많은 오브젝트에서 월드 포지션 오프셋을 사용 중인 경우 높아질 수 있습니다.
이 표현식의 구성 및 사용에 대한 자세한 내용은 Utility 머티리얼 표현식의 'Previous Frame Switch' 섹션을 참조하세요.
셰이딩 거부
이는 모든 TSR 안티 에일리어싱 엔진 퀄리티 그룹에서 필수이지만, r.TSR.ShadingRejection.*
콘솔 변수로 커스터마이징할 수 있습니다.
TSR의 셰이딩 거부 휴리스틱 기법은 현재 프레임이 이전 프레임과 얼마나 많이 일치하는지, 모두 재사용되어야 하는지 또는 거부되어야 하는지 여부를 결정하는 프로세스입니다.

셰이딩 거부의 입력은 Scene Color, After DOF Translucency Color, Color A 로, 템포럴 업스케일러 시각화 모드에서 볼 수 있습니다. 출력, 즉 프레임에서 거부되는 양이 어느 정도인지는 템포럴 슈퍼 해상도 시각화 모드의 History Rejection 및 History Clamp 에 표시됩니다.

디스플레이 해상도나 Nyquist-Shannon 히스토리를 통한 더 높은 해상도로 실행되는 히스토리 업데이트는 시간 경과에 따른 디테일 통합만 수행하여 원칙적으로 단순해지며, 빨라서 편리합니다.
(w:800)
TSR 및 반투명
모든 TSR 안티 에일리어싱 엔진 퀄리티 그룹에서 필수입니다.
반투명은 TSR이 처리해야 할 특수한 문제로, 한 레이어 위로 임의의 레이어가 몇 개든 블렌딩될 수 있기 때문입니다. 기본적으로 반투명 머티리얼은 속도를 아예 드로하지 않거나, 최대 하나만 드로합니다. 이로 인해 TSR이 반투명 머티리얼의 움직임을 정확히 파악하지 못하므로 에지의 선명함이 다른 경우에 비해 덜해 보입니다.
반투명 패스
반투명 머티리얼은 뎁스 오브 필드 이전, 뎁스 오브 필드 이후(디폴트), 모션 블러 이후 등 다른 반투명 패스에서 렌더링됩니다. 반투명을 사용하는 모든 표면에서 나타나는 일반적인 문제는 서로 오버랩되는 다수의 반투명 오브젝트가 있을 때 발생합니다. 이는 뎁스 버퍼가 어떤 반투명 오브젝트가 다른 반투명 오브젝트 앞에 나타나야 할지 결정하지 못하는 반투명 정렬 문제로 이어집니다.
머티리얼 세팅에서 반투명 패스가 발생해야 하는 위치를 지정할 수 있습니다. 반투명(Translucency) 카테고리에서 반투명 패스(Translucency pass) 드롭다운을 사용하여 이 반투명 머티리얼이 발생해야 하는 위치를 선택합니다. 기본적으로 반투명 머티리얼은 After DOF 에서 렌더링하도록 설정되어 있습니다.

블렌딩되고, 속도를 절대 드로하지 않는 반투명의 특성으로 인해, TSR은 반투명을 불투명 지오메트리와는 다른 방식으로 처리해야 합니다. TSR의 셰이딩 거부 휴리스틱 기법은 뎁스 오브 필드 이후에 발생하는 반투명을 활용하는데, 이러한 반투명은 나머지 씬 지오메트리에서 별도로 드로되기 때문입니다.
아래 차트는 이러한 각각의 반투명 패스가 렌더링 파이프라인의 어디에 발생하는지 보여줍니다.

DumpGPU에서 출력을 여는 경우 반투명 패스는 씬(Scene) > 반투명(Translucency) 에서 찾을 수 있습니다.
DumpGPU 출력 예시 1 | DumpGPU 출력 예시 2 |
이미지를 클릭하면 원본 크기로 볼 수 있습니다.
DumpGPU 명령이 모든 프레임 정보를 디스크에 덤프하는 데 어느 정도 시간이 걸리는 경우, 템포럴 업스케일러 시각화 모드는 반투명이 올바른 위치에서 드로되는지 온전성을 확인하는 편리한 방법인 After DOF 뷰를 제공합니다.
DumpGPU 출력 예시 1 | DumpGPU 출력 예시 2 |
이미지를 클릭하면 원본 크기로 볼 수 있습니다.
나나이트가 제공하는 디테일의 양을 유지하기 위해, TSR의 셰이딩 거부 휴리스틱 기법은 수동 작성된 컨볼루션 네트워크로 구축되어 거부 결정을 내립니다. 이러한 컨볼루션 대부분은 전적으로 이미지 안정성을 위한 용도입니다. 하지만 결국에는 고스팅 아티팩트를 생성하는 잘못된 모션 벡터가 있는 이후 컨볼루션에서 고스팅 현상이 발생할 수 있습니다. 반투명에는 모션 벡터가 없는 경우가 종종 있으므로, 뎁스 오브 필드 뒤에 발생하고 별도의 패스에서 드로되는 반투명 머티리얼의 셰이딩 거부는 전용 블러 컨볼루션을 추가합니다. 이 컨볼루션은 고스팅 현상을 줄이기 위해 반투명 오브젝트의 이미지 안정성을 약간 희생합니다.
아래 차트는 나나이트가 제공하는 모든 디테일로 이미지를 안정화하기 위해 TSR 히스토리에서 이러한 컨볼루션이 발생하는 위치를 보여줍니다.

원하는 이펙트를 얻으려면 때로는 반투명을 수동으로 조정해야 합니다. 예를 들어, 샷별로 머티리얼의 반투명 패스를 수동으로 조정해야 하는 경우가 흔히 있습니다. Auto Before DOF ( r.Translucency.AutoBeforeDOF
) 기능을 사용하면 뎁스 오브 필드 이전 패스에서 초점 거리 뒤에 반투명 이펙트를 자동으로 드로하여, 샷별로 또는 비슷한 스타일 구성으로 이 작업을 수행할 필요가 없습니다. 이 기능은 기본적으로 활성화됩니다.
![]() |
![]() |
---|---|
Before DOF 사용 | Before DOF 미사용 |
의도가 확실한 경우에만 머티리얼에서 반투명 패스를 조정할 것을 적극 권장합니다. 이 세팅을 변경하면 반투명 머티리얼의 외관에 영향을 미칠 수 있을 뿐만 아니라 예상치 못한 퍼포먼스 비용이 발생할 수 있습니다. 디폴트인 After DOF 를 사용하는 것이 좋습니다.
값을 조정해야 하는 경우 콘솔 변수는 다음과 같이 설정되는 0에서 1 사이의 플로트 값을 받습니다.
- 0.0인 경우 초점 거리의 1배수로 설정됩니다.
- 0.5인 경우 초점 거리의 2배수로 설정됩니다.
- 1.0인 경우 초점 거리의 100배수로 설정됩니다.
머티리얼에서 반투명 속도 출력하기
TSR에는 광학 플로가 없어 움직이는 반투명 오브젝트의 에지가 선명하게 보이며, 이는 전적인 고스팅 문제가 아니더라도 보기 좋지 않은 경우가 많습니다. 반투명을 사용하는 머티리얼에는 속도를 출력하여 속도 패스의 뎁스 버퍼에 모션 벡터를 작성하는 옵션이 있습니다. 이 옵션은 이 세팅을 활성화한 오브젝트의 선명한 반투명 디테일이 씬에서 움직이는 방식을 TSR이 결정하는 데 있어 유용한 시작점이 되어줍니다.
디테일(Details) 패널의 반투명 카테고리에서 출력 뎁스 및 속도(Output Depth and Velocity) 박스에 체크하여 머티리얼이 모션 벡터를 출력하는 기능을 활성화할 수 있습니다.

아래 예시 씬은 태양 캐릭터의 반투명 머티리얼 뎁스 및 속도 출력이 뎁스 및 속도가 없는 경우와 비교했을 때 눈과 입 부분 디테일을 얼마나 선명하게 만드는지 보여줍니다.
![]() |
![]() |
---|---|
출력 뎁스 및 속도: 비활성화됨 | 출력 뎁스 및 속도: 활성화됨 |
템포럴 업스케일러 시각화 모드를 사용하여 vis SceneDepthZ, show VisualizeMotionBlur, show VisualizeReprojection 뷰로 이 세팅을 검사할 수 있습니다.
![]() |
![]() |
![]() |
---|---|---|
vis SceneDepthZ | show VisualizeMotionBlur | show VisualizeReprojection |
템포럴 업스케일러 시각화 모드에서는 반투명 머티리얼이 최종 결과물을 구현하기 위해 활성화된 출력 뎁스 및 속도 세팅에서 이 3가지 입력을 통해 어떻게 정보를 수신하는지 확인할 수 있습니다.

반투명은 어느 정도의 오파시티를 가지고 씬 컬러에 블렌딩되지만, 뎁스 및 속도 버퍼는 컬러처럼 블렌딩되지 않습니다. 뎁스 및 속도 버퍼는 완전히 덮어쓰거나 덮어쓰지 않는 것만 가능합니다. 오파시티 마스크 클립 값(Opacity Mask Clip Value) 머티리얼 세팅은 렌더러의 머티리얼 오파시티를 비교하는 데 사용됩니다.
디테일 패널의 머티리얼(Material) > 고급 카테고리에서 오파시티 마스크 클립 값 을 설정할 수 있습니다.

디폴트 오파시티 마스크 클립 값(0.333)이 반투명 머티리얼을 사용하는 비주얼 이펙트(VFX)에 항상 적합한 것은 아닙니다. 뎁스 및 속도를 덮어쓰면 투명한 오브젝트 뒤에서 불투명 지오메트리를 재투영하는 경우에 악영향을 미칠 수 있습니다. 이러한 경우 더 높은 오파시티 마스크 클립 값을 사용하여 VFX의 가장 불투명한 영역에만 속도를 드로하면 투명 오브젝트 뒤 불투명 지오메트리의 재투영 오류가 훨씬 눈에 덜 띕니다.
아래 예시에서는 출력 뎁스 및 속도 세팅이 활성화 또는 비활성화되었을 때 오파시티 마스크 클립 값이 디테일의 선명도나 매끄러운 정도에 어떤 차이를 만들어 내는지 보여줍니다.
![]() |
![]() |
---|---|
출력 뎁스 및 속도: 비활성화됨 | 출력 뎁스 및 속도: 활성화됨 |
포스트 프로세스 머티리얼에 TSR 사용하기
TSR과 다른 안티 에일리어싱 기법 간의 동일한 동작입니다.
포스트 프로세스 머티리얼이 제공하는 유연성에는 TSR이 포스트 프로세싱 체인 중간에 발생하는 것으로 인한 자체적인 조건부 제한도 포함됩니다. 머티리얼은 뎁스 오브 필드 반투명 뒤 씬 컬러의 다양한 위치에 삽입됩니다.
머티리얼은 포스트 프로세스 머티리얼을 통해 씬 컬러의 다양한 위치에 삽입될 수 있습니다. 블렌더블 위치(Blendable Location) 머티리얼 세팅을 사용하여 씬 컬러를 수정할 포스트 프로세스 머티리얼의 위치를 지정할 수 있습니다.

블렌더블 위치 | 설명 |
---|---|
Scene Color Before DOF | 씬 컬러를 수정할 포스트 프로세스 머티리얼의 위치를 반투명 디스토션과 뎁스 오브 필드 사이에 배치합니다. 항상 렌더 해상도로 실행되며, 입력과 출력은 항상 선형 컬러 스페이스에서 이루어집니다. |
Scene Color After DOF | 포스트 프로세스 머티리얼의 위치를 뎁스 오브 필드와 뎁스 오브 필드 반투명 이후 사이에 배치합니다. 항상 렌더링 해상도로 실행되며, 입력과 출력은 항상 선형 컬러 스페이스에서 이루어집니다. |
Translucency After DOF | 씬 컬러로 컴포지션하기 전 포스트 프로세스 머티리얼을 뎁스 오브 필드 반투명 뒤에 배치합니다. 항상 렌더링 해상도로 실행되며, 입력과 출력은 항상 선형 컬러 스페이스에서 이루어집니다. |
SSR Input | 이 포스트 프로세스 머티리얼은 TSR/TAA와 다음 프레임의 스크린 스페이스 리플렉션(SSR) 사이에서 백플레이트를 SSR로 컴포지션합니다. TSR 디스플레이 해상도 또는 TAAU 렌더링 해상도로 실행되며, 입력과 출력은 항상 선형 컬러 스페이스에서 이루어집니다. |
Scene Color Before Bloom | 이 포스트 프로세스 머티리얼 위치는 블룸 앞에 씬 컬러를 수정합니다. TSR 디스플레이 해상도 또는 TAAU 렌더링 해상도로 실행되며, 입력과 출력은 항상 선형 컬러 스페이스에서 이루어집니다. |
Replacing the Tonemapper | 이 포스트 프로세스 머티리얼은 씬 컬러를 수정하기 위해 톤매퍼를 대체합니다. TSR 디스플레이 해상도 또는 TAAU 렌더링 해상도로 실행되며, 입력은 항상 선형 컬러 스페이스에서 이루어집니다. |
Scene COlor After Tonemapping | 이 포스트 프로세스 머티리얼 위치는 톤매퍼 후에 씬 컬러를 수정합니다. TSR 디스플레이 해상도 또는 TAAU 렌더링 해상도로 실행되며, 입력과 출력은 렌더링 세팅에 따라 다양한 컬러 스페이스에서 이루어집니다. 예를 들면 sRGB/Rec709, HDR 또는 선형 컬러가 있습니다. |
아래 차트는 어떤 위치가 실행되는지, 언제 실행되는지, 어떤 해상도로 실행되는지 대략적으로 파악하는 데 도움이 됩니다. 아래 차트는 예시로 Scene Color Before DOF, Scene Color After DOF, Translucency After DOF 를 사용합니다.

템포럴 업스케일러 시각화 모드는 이러한 뷰와 파이프라인 내 뷰의 위치를 보다 잘 이해할 수 있는 유용한 방법입니다. 구체적으로는 vis SceneColor, vis Translucency.AfterDOF.Color, vis Translucency.AfterDOF.Color A, vis TSR.Output 이 있습니다.

명령 DumpGPU
를 사용하여 GPU의 로그 덤프를 출력할 수 있습니다. DumpGPU 뷰어에서 로그를 열 때, 머티리얼 이름을 검색하여 포스트 프로세스 머티리얼이 어떤 모습인지 입력과 출력을 확인할 수 있습니다. 보다 제한된 빠른 덤프 로그를 원하는 경우 r.DumpGPU.Root *PostProcessing*
으로 로그가 포스트 프로세싱 부분만 덤프하도록 제한할 수 있습니다.
이미지를 클릭하면 원본 크기로 볼 수 있습니다.
스페이셜 안티 에일리어싱 툴
중간, 높음, 에픽, 시네마틱 TSR 안티 에일리어싱 엔진 퀄리티 그룹에서 기본적으로 활성화됩니다. 콘솔 명령 r.TSR.RejectionAntiAliasingQuality
로 퀄리티를 제어할 수 있습니다.
카메라 컷이 있을 때나 새 오브젝트가 화면에 나타나거나 변경될 때 등 TSR이 단일 프레임만큼의 데이터만 작업 가능한 경우가 있습니다. 이러한 이유로 TSR에는 기본 스페이셜 안티 에일리어싱 툴 알고리즘이 탑재되어 있어, 안티 에일리어싱이 가장 많이 필요한 이미지 영역에 향상된 안티 에일리어싱을 자동으로 제공합니다.
아래 예시에서는 이 알고리즘이 프레임 중앙과 가까운 바위 에지 주변 등 안티 에일리어싱이 가장 많이 필요한 이미지 영역의 퀄리티를 높이는 데 얼마나 유용한지 확인할 수 있습니다.
![]() |
![]() |
---|---|
스페이셜 안티 에일리어싱 툴 사용 | 스페이셜 안티 에일리어싱 툴 미사용 |
다음 명령을 사용하여 프로젝트에서 직접 테스트해 볼 수 있습니다.
r.Test.CameraCut 1
r.Test.SecondaryUpscaleOverride 8
설정한 후에는 콘솔 명령 r.TSR.RejectionAntiAliasingQuality
를 사용하여 스페이셜 안티 에일리어싱 툴의 퀄리티를 테스트할 수 있습니다. 값을 0 또는 1 로 설정하여 끄거나 켭니다.
템포럴 슈퍼 해상도 시각화 모드에는 좌측 하단에 스페이셜 안티 에일리어싱(Spatial Anti-Aliasing) 뷰가 포함되어 있습니다. 콘솔 명령 r.TSR.Visualize 6
을 입력하여 전체화면으로 볼 수 있습니다.

비슷한 에일리어싱 탐지 담당 알고리즘으로는 프레임에서 가로 또는 세로 검색을 수행하는 빠른 어프록시메이트 안티 에일리어싱(Fast Approximate Anti-Aliasing, FXAA) 스타일 알고리즘이 있습니다. 이 알고리즘은 현재 프레임에 있는 것의 퀄리티를 개선할 수 있지만, 보유하지 않은 정보를 생성할 수는 없습니다. 이 알고리즘의 유일한 목적은 히스토리 수렴률에 따라 디테일이 계속 누적되는 짧은 시간 동안 디테일이 충분히 누적되지 않은 프레임 영역을 낮은 비용으로 숨기는 것입니다.
자세한 내용은 이 페이지의 디테일의 템포럴 누적에 대한 주의사항 이해하기 섹션에서 알아볼 수 있습니다.
TSR 깜빡임 템포럴 분석
높음, 에픽, 시네마틱 TSR 안티 에일리어싱 엔진 퀄리티 그룹에서 기본적으로 활성화됩니다. 콘솔 명령 r.TSR.ShadingRejection.Flickering
으로 퀄리티를 제어할 수 있습니다.
좋은 이미지 퀄리티를 제공하는 데 있어 중요한 요인은 시간이 지나도 안정성을 유지하는 것입니다. 나나이트가 생성하는 디테일의 양은 템포럴 통합을 어렵게 만들 수 있습니다.
이 섹션에서는 처리할 프레임 내에 대량의 디테일이 있는 경우 TSR에서 이미지 안정성 유지를 시도하는 동안 발생할 수 있는 일반적인 문제를 살펴봅니다. 이 섹션에서는 TSR에서 발생할 수 있는 깜빡임을 분석하는 방법, 발생 원인, 이 문제를 완화하기 위해 프로젝트에서 시도해 볼 수 있는 방법을 살펴봅니다.
무아레 패턴
무아레 패턴은 반복적인 디테일에서 종종 발생하는 아티팩트로, 보통 원거리에서 화면에 오버랩되거나 충분히 작은 선으로 인해 원하지 않는 패턴이 생기는 경우 등이 있습니다. 게임 내에서는 메시에 디테일을 직접 추가하기 보다는 텍스처를 사용하여 지오메트리에 디테일을 추가하여 해결되는 경우가 많으며, 이는 텍스처가 원거리에서 낮은 해상도의 밉맵을 사용하여 원하지 않는 아티팩트를 완화하기 때문입니다.
나나이트로 생성되는 디테일의 양으로 인해 완전히 불안정한 이미지가 생성될 수 있으며, 오브젝트를 지표각에서 볼 때 특히 그렇습니다. 에픽의 '매트릭스 어웨이큰스' GDC 데모를 위해 제작된 도시 샘플 프로젝트를 예로 들어 보겠습니다. 이러한 환경에서는 디테일의 양과 지표각의 카메라 뷰를 활용할 때의 디스오클루전으로 인해 어려움이 많았습니다.
왼쪽 캡처는 화면에서 거의 픽셀을 차지하지 않는 수많은 지오메트릭 디테일에서 발생할 수 있는 무아레 패턴 타입의 아티팩트를 보여줍니다. TSR이 깜빡임 셰이딩 거부를 사용할 때, 이러한 타입의 아티팩트는 가까이에서 해석되지 않는 경우 완화할 수 있습니다. 첫 번째 이미지는 이 아티팩트 타입에서 최악의 시나리오입니다.
TSR의 깜빡임 셰이딩 거부가 비활성화되어 있을 때 지표각에서 아티팩트가 유발되는 정도와 활성화되어 있을 때 아티팩트가 감소하는 정도 및 약간 늘어난 깜빡임 주기를 살펴보는 식으로 아래 표의 두 캡처를 비교해 볼 수 있습니다. 첫 번째 캡처에서 비활성화된 깜빡임 셰이딩 거부가 이 아티팩트 타입에서 최악의 시나리오입니다.
![]() |
![]() |
---|---|
셰이딩 거부 미사용(r.TSR.ShadingRejection.Flickering 0) | 셰이딩 거부 사용 및 늘어난 깜빡임 주기(r.TSR.ShadingRejection.Flickering 1) |
각각의 캡처는 60Hz로 설정되어 있으며 에픽 안티 에일리어싱 엔진 퀄리티 그룹을 사용했습니다. 오른쪽 캡처는 또한 콘솔 명령 r.TSR.ShadingRejection.Flickering.Period
를 통해 디폴트 깜빡임 셰이딩 거부 주기를 2(디폴트)에서 3으로 늘립니다.
이러한 아티팩트 타입에서 발생하는 핵심 문제는 디테일이 손실된다는 것입니다. 아래 스크린샷처럼 안티 에일리어싱이 비활성화된 경우에도 이 문제가 발생할 수 있습니다.

안티 에일리어싱을 비활성화한 결과 원거리 건물 표면의 디테일이 손실된 도시 샘플의 한 씬
이러한 디테일 손실의 원인은 나나이트가 모든 주어진 프레임에서 유지하는 디테일의 양입니다. 특히 이 씬에서 창문 주변 지오메트리의 경우, 건물 기둥 구조가 픽셀을 거의 차지하지 않고 카메라와 멀리 떨어진 지오메트리에서 디테일 손실을 유발합니다.
아래 그림은 건물의 지오메트리를 상단, 정면, 지표각 뷰 포인트에서 단순화하여 표현한 것입니다. 상단 뷰에서는 기둥이 각 창문 사이에 들어가 있는 것을 볼 수 있습니다. 정면 뷰에서는 이러한 창문들이 기둥 사이에 배치된 간격과, 기둥이 지면에서 건물 꼭대기까지 세로로 뻗어 있는 모습을 보여줍니다. 지표각에서는 먼 거리에서 볼 때 이러한 세로 기둥이 얼마나 압축되어 나타나는지 보여줍니다.

이 건물의 디테일 대부분과 같이 한 이미지를 구성하는 픽셀들은 그리드에 구조화되며, 이 그리드는 디테일이 시간 경과에 따라 통합되면서 각 프레임을 변경합니다.
![]() |
![]() |
![]() |
---|---|---|
빨간색은 프레임 N의 픽셀 샘플링 위치입니다. 녹색은 프레임 N+1의 위치입니다. | 빨간색은 프레임 N의 렌더링된 픽셀 위치입니다. 검은색은 프레임 N의 표시된 픽셀 위치입니다. | 빨간색은 프레임 N의 픽셀 위치입니다. 검은색은 프레임 N의 고해상도 디스플레이 픽셀 위치입니다. |
그 결과, 프레임에는 몇 프레임마다 픽셀보다 작은 일부 건물 디테일이 포함되어 있기도 합니다. TSR은 모든 프레임에 서브픽셀 나나이트 디테일이 있는 것은 아니라는 점을 염두에 두고 설계되었습니다. 즉, 하나의 프레임에서 다음 프레임으로 넘어갈 때 이미지의 어떤 부분을 안정화해야 하는지 인식할 수 있습니다. 이 경우 건물의 기둥 부분이 프레임 간에 움직이지 않고 안정화되어야 합니다.
아래 그림은 픽셀이 첫 번째 프레임(빨간색)과 다음 프레임(황갈색) 간에 정렬할 수 있는 방식과 안정적이라고 인식된 지오메트리가 다음 프레임까지 이어지는 모습을 보여줍니다.

지표각에서 일부 작은 구조물의 디테일은 다른 부분과 비교했을 때 더 시각적으로 우세합니다. 구조물 디테일의 정렬은 현재 렌더링되는 픽셀과 정렬될 수 있으며, 이는 각 창문 사이의 기둥이 아니라 창문과 벽만 발견된다는 의미입니다.
아래 그림은 그리드 배치로 인해 각 프레임이 서로 다른 것을 보면서 프레임 N(빨간색) 픽셀과 프레임 N+1(황갈색) 픽셀이 이러한 종류의 정렬 불일치를 유발하는 상황을 보여줍니다.

이는 프레임에 무아레 패턴이 발생하는 요인이 되며, TSR은 픽셀이 동일한 지오메트리를 포함하는지 또는 셰이딩 변화가 발생한 것인지 알 방법이 없으므로 TSR에서는 특히 해결하기 힘든 문제입니다. 이와 더불어 변경된 사항을 파악하기 위해 지오메트리에 의존하는 것뿐만 아니라, 프레임의 렌더링 해상도 역시 문제가 됩니다.
예를 들어, 렌더링 해상도를 줄이고 렌더링되는 모든 픽셀의 샘플링 위치 사이 공간을 늘리면 결국 건물의 지오메트리 디테일이 더욱 상이해집니다. 건물의 창문, 벽, 기둥 등이 여기에 해당할 수 있습니다. 이들은 건물의 동일한 지오메트리이며 셰이딩 변화가 아니라는 사실을 TSR이 인식할 수 있는 추가 정보가 됩니다.
아래 그림에서는 이미지 안정성을 유지하는 데 도움이 되는 이러한 픽셀이 세로로 정렬된 지오메트리에서 프레임 N(빨간색)의 픽셀과 프레임 N+1(황갈색)의 픽셀을 보다 쉽게 구별할 수 있습니다.

건물의 이 특정 에일리어싱 문제는 씬 지오메트리와 프레임마다 렌더링되는 픽셀에서 발생할 수 있는 일반적인 샘플링 문제의 예시입니다. TSR은 렌더링되는 픽셀이 시간 경과에 따라 씬의 특정 지오메트리에 속하는지, 렌더링된 픽셀을 샘플링해야 하는지 여부를 결정합니다.

이미지 안정성은 다면적인 문제로, TSR은 프레임에서 안정화해야 하는 대상을 결정하는 역할을 합니다. 이는 무아레 패턴을 유발할 수 있는 요인이므로, 안정화해야 하는 대상을 TSR이 제어하게 하는 것이 낫습니다. 렌더링된 픽셀 그리드와 지오메트리 간에 무아레 패턴이 없는 화면의 일부에 불안정성이 있을 수도 있습니다. 이 예시는 최악의 시나리오이며, TSR이 셰이딩 변화를 탐지하고 템포럴 안정성을 일관적으로 유지하는 기술적 솔루션의 역할을 하는 이유가 무엇인지 보여줍니다.
템포럴 히스토리의 인과 관계 딜레마
TSR에서 불안정성을 일으키는 샘플링 문제는 무아레 패턴뿐만이 아닙니다. 렌더링된 픽셀 그리드에서 샘플링된 나나이트 디테일의 지나친 양이 문제가 되기도 합니다. 궁극적으로 이는 렌더링된 프레임 내 디테일의 양이 히스토리에 없는 경우 히스토리가 렌더링된 프레임과 동일할 수 없으며, 히스토리가 렌더링된 프레임과 너무 다른 경우 히스토리가 이러한 디테일을 누적할 수 없다는 결론에 도달하게 됩니다.
이 셰이딩 거부 문제를 해결하려고 시도하면 화면에서 비주얼 이펙트가 움직이거나 환경에서 라이팅 변화가 발생하는 경우 등 유사한 상황에서 터무니없는 양의 고스팅이 발생합니다. TSR은 이미지를 안정화하고 이 순환을 끊으려는 추가적인 노력을 통해 시간 경과에 따라 이 문제를 해결합니다.

깜빡임 휘도 측정
무아레 패턴과 템포럴 히스토리 인과 관계 딜레마는 모두 나나이트가 화면에서 처리할 수 있는 디테일의 양으로 인해 발생합니다. TSR의 안티 고스팅 메커니즘을 방해할 수 있는 모든 유형의 렌더링 알고리즘을 완화하기 위해, TSR은 불투명 라이팅 뒤에 단순히 프레임 내 불투명 지오메트리의 스냅샷을 찍는 용도로 추가 패스를 삽입합니다. 이 패스는 TSR.Flickering.Luminance 라고 하며, 이 패스의 입력은 템포럴 업스케일러 시각화 모드에서 확인할 수 있습니다.

또는 DumpGPU 뷰어에서도 찾을 수 있습니다. 'TSR'을 검색하고 TSR MeasureFlickeringLuma 를 선택하여 출력을 점검하세요.

TSR MeasureFlickeringLuma 패스는 주로 씬 컬러를 로우 다이내믹 레인지(Low Dynamic Range, LDR) 휘도로 변환합니다. 이 작업을 마지막 라이팅 패스에서 수행할 수 있지만, 언리얼 엔진이 렌더러에서 지원하는 대량의 코드 경로로 인한 것은 아니며 대신 독립형 패스로 유지됩니다.
게임 출시를 준비 중일 때, 이 방법으로 어떤 코드 경로가 사용되는지 확인하고 사용되지 않는 경로를 비활성화하여 최적화할 수 있습니다. 예를 들어, 다이내믹 라이팅만 사용하는 경우 구운 스태틱 라이팅을 비활성화할 수 있습니다.
이 스냅샷은 TSR이 포그, 구름, 단일 레이어 물, 사전 디스토션 반투명, 디스토션 등 씬 컬러 내 다른 이펙트를 깜빡임으로 간주할지 여부를 파악하는 데 도움이 됩니다. 이를 위해 씬 컬러를 TSR 깜빡임 Luma 스냅샷과 비교합니다.
프레임 중앙 오른쪽 근처의 건물을 살펴보면, 깜빡임 휘도 시각화에서 프레임 간 무아레 패턴 변화를 확인할 수 있습니다.

깜빡임 템포럴 분석
TSR은 불투명 라이팅포함 지오메트리가 하나의 프레임에서 다른 프레임까지 얼마나 깜빡이는지 파악하고 있기 때문에, 깜빡임 간 시간이 r.TSR.ShadingRejection.Flickering.Period
로 지정한 시간보다 짧아지는 경우 시간 경과에 따른 추적이 가능합니다. 이 콘솔 변수는 프레임의 깜빡임 주기를 측정하고, 셰이딩 거부 휴리스틱을 완화하여 이미지 안정화를 시도합니다.
템포럴 슈퍼 해상도 시각화 모드를 사용하여 셰이딩 휴리스틱이 깜빡임을 얼마나 완화하는지 직접 확인할 수 있습니다.

이 모든 입력은 깜빡임 방지 휴리스틱이 프레임 중앙 근처의 건물 기둥 및 창문의 깜빡임과 같이 이미지에서 깜빡임을 드러내는 부분에 빠르게 포커스할 수 있도록 합니다. 출력은 깜빡임이 나타나는 문제 영역을 빨간색으로 하이라이트합니다.

CitySample, 5.4, r.TSR.ShadingRejection.Flickering.Period=3, r.TSR.Visualize=7
퍼포먼스상의 이유로, 깜빡임 템포럴 분석은 픽셀의 휘도만 모니터링합니다. 분석 비용은 각 컬러 채널을 모니터링할 때 발생하는 비용 대비 3분의 1 수준으로 유지됩니다. 즉, 일부 깜빡임이 휘도에서는 많이 발생하지 않지만 프레임의 색채 엘리먼트에서는 발생하는 경우, 휴리스틱이 해당 깜빡임을 그냥 허용할 수도 있습니다.
프레임 레이트의 이펙트
깜빡임은 프레임 레이트에 관계없이 발생할 수 있습니다. 프레임 레이트와 별개인 시간 기반 비주얼 이펙트가 여기에 해당합니다. 이는 60Hz에서 매끄럽게 보이는 비주얼 이펙트가 24Hz 정도의 낮은 프레임 레이트에서는 '깜빡이는' 것처럼 보일 수도 있다는 뜻입니다. 따라서 아티스트가 제작한 비주얼이 프레임 레이트에 영향을 받지 않는 상태로 유지되는 것이 중요합니다. TSR이 특별히 프레임 레이트를 위해서가 아니라 GPU 퍼포먼스를 충족하기 위해 스케일링되기 때문입니다. 즉, 디바이스 또는 플랫폼이 예상 프레임 레이트보다 낮은 프레임 레이트로 실행될 때 비주얼이 변하는 의도치 않은 결과가 발생할 수 있습니다.
이러한 이유로, 콘솔 명령 r.TSR.ShadingRejection.Flickering.Period
를 사용하여 프레임 레이트가 r.TSR.ShadingRejection.Flickering.FrameRateCap
으로 정의된 프레임 레이트(디폴트 60Hz) 아래로 떨어질 때 자동으로 깜빡임을 감소시킬 수 있습니다. 이는 60Hz에서는 안정적인 지오메트릭 디테일이 더 낮은 프레임 레이트에서는 덜 안정적으로 변할 수도 있음을 의미합니다. 아래 캡처에서 그 예시를 확인할 수 있습니다.
![]() |
![]() |
---|---|
주사율 60Hz | 주사율 30Hz |
아래 그래프는 이 값 아래로 떨어지면 깜빡임으로 간주되는 프레임 주기를 2프레임으로, 프레임 레이트 한도는 60Hz로 설정한 모습을 보여줍니다. 60Hz 미만의 값은 프레임 레이트가 떨어질 때 깜빡임이 나타날 가능성이 더 높습니다. 60Hz 이상의 값은 안정적이라고 간주됩니다.

아래 캡처의 프레임 레이트는 30Hz로, 이전 캡처와 동일한 세팅을 사용합니다. 이번을 제외하면 깜빡임 프레임 레이트 한도( r.TSR.ShadingRejection.Flickering.FrameRateCap
)는 계속해서 30Hz가 아닌 60Hz로 설정하여 이미지를 안정화했습니다.
![]() |
![]() |
---|---|
주사율 60Hz | 주사율 30Hz |
프로젝트의 깜빡임 방지를 미세조정하려면 다음 단계를 따릅니다.
r.TSR.ShadingRejection.Flickering.FrameRateCap
을 30Hz 또는 60Hz와 같이 프로젝트의 타깃 프레임 레이트로 설정합니다.t.MaxFPS
를 통해 에디터의 주사율 또는 FPS를 30 또는 60과 같이 동일한 프레임 레이트 값으로 고정합니다.r.TSR.ShadingRejection.Flickering.Period
를 통해 원하는 룩에 맞게 깜빡임 주기를 커스터마이징합니다.
에디터에서 이러한 세팅을 고정했으면, 에디터와 타깃 플랫폼에서 일관된 동작을 위해 [프로젝트의 루트]/Config 폴더의 DefaultEngine.ini 파일로 세팅을 복사합니다.
이 깜빡임 방지 동작은 기본적으로 활성화되어 있지만, r.TSR.ShadingRejection.Flickering.AdjustToFrameRate
를 0으로 설정하여 비활성화할 수도 있습니다. 그러나 비주얼 이펙트를 위해 이 동작을 비활성화하지 않을 것을 적극 권장합니다.
움직임 및 해상도 변경에 따른 안티 에일리어싱
이 페이지의 무아레 패턴 섹션에서 앞서 언급한 것처럼, 픽셀 그리드와 나나이트 지오메트리 간에 발생하는 무아레 패턴은 렌더링 해상도에 따라 움직입니다. 무아레 패턴은 또한 카메라를 기준으로 한 프레임 내 오브젝트의 위치에 따라서도 달라집니다.
예를 들어 아래 씬에서는 스크린 퍼센티지가 60%에서 90%로 변경될 때 건물의 깜빡임 위치가 바뀌는 모습을 확인할 수 있습니다. 이 씬에서 그 밖에 다른 요소는 움직이지 않는다는 점도 눈여겨볼 만 합니다.
![]() |
![]() |
---|---|
스크린 퍼센티지: 60 | 스크린 퍼센티지: 90 |
스크린 퍼센티지 및 지오메트리를 기준으로 씬 내 픽셀 그리드의 위치를 파악하는 것은 기존 깜빡임 방지 휴리스틱 기법이 지닌 한계이므로 중요합니다. 기존 하드웨어에서 이 문제를 극복할 정도로 퍼포먼스가 충분한 효과적인 솔루션은 존재하지 않습니다. 따라서 카메라 이동이나 렌더링 해상도 변경으로 인해 무아레 패턴이 움직이는 경우 TSR은 안정화를 시도해야 하는 실제 깜빡임인지 확실해지기 전에 몇 프레임 동안 새 영역에서 깜빡임을 탐지합니다.
아래 캡처에서 카메라를 뒤로 당기자 건물의 무아레 패턴이 이미지를 안정화하는 TSR의 깜빡임 방지 휴리스틱의 타깃이 되기까지 몇 프레임이 소요되는 것을 확인할 수 있습니다. 또한 위의 두 예시와 같이 건물에서 무아레 패턴의 위치가 변하는 것도 확인할 수 있습니다.

(r.AntiAliasingMethod=4, sg.AntiAliasingQuality=3, r.TSR.ShadingRejection.Flickering=1, r.TSR.ShadingRejection.Flickering.FrameRateCap=30, r.TSR.ShadingRejection.Flickering.Period=3)
TSR의 깜빡임 템포럴 분석은 움직이는 오브젝트 및 충분히 큰 패럴랙스 변화가 있는 픽셀에서 픽셀별로 비활성화됩니다. 이는 리플렉션, 패럴랙스 오클루전 매핑, 시차가 있는 건물 내부 등 모션 벡터가 없는 다른 콘텐츠의 문제를 완화합니다.
움직이는 동안 비활성화된 화면 부분을 보려면 템포럴 슈퍼 해상도 시각화 모드를 사용하여 TSR Flickering Analysis 입력을 살펴볼 수 있습니다. 비활성화된 픽셀은 프레임에서 분홍색으로 표시됩니다. 콘솔 명령 r.TSR.Visualize 7
을 사용하여 이 입력을 전체화면으로 볼 수 있습니다.

픽셀 애니메이션을 사용하는 머티리얼
텍스처 패닝 등 어느 정도의 픽셀 셰이더 애니메이션을 수행하는 불투명 머티리얼은 깜빡임 주기 한계치를 넘는 경우 TSR에서 고스팅을 유발하여 문제가 될 수 있습니다. 이는 움직이는 픽셀 애니메이션에 모션 벡터가 없고, 깜빡임 템포럴 분석에서 불투명 픽셀로 인해 컬러가 변하는 경우가 종종 관찰되기 때문입니다.
연속 애니메이션을 적용한 불투명 머티리얼이 있는 아래 캐릭터를 예로 들어 보겠습니다. 템포럴 업스케일러 시각화 모드의 TSR Flickering Luminance 입력은 깜빡임 템포럴 분석에서 머티리얼 변화를 반영하지 않습니다.

이러한 픽셀은 시간 경과에 따라 변화하므로 '깜빡임'으로 탐지되며, 이로 인해 TSR이 이미지를 안정화하려고 시도하여 원하지 않는 고스팅 현상이 발생합니다. 이는 템포럴 슈퍼 해상도 시각화 모드의 깜빡임 템포럴 분석 입력을 살펴보는 경우에도 확인할 수 있습니다.

문제가 되는 불투명 머티리얼을 모션 벡터로 나타낼 수 없는 픽셀 애니메이션을 보유했다고 표시함으로써 TSR의 깜빡임 템포럴 분석에서 발생한 고스팅 현상에 대응할 수 있습니다. 머티리얼의 디테일 패널에서 머티리얼의 픽셀 애니메이션 보유(Has Pixel Animation) 세팅을 활성화합니다. 이 동일한 세팅을 머티리얼 프로퍼티 오버라이드(Material Property Overrides) 아래의 머티리얼 인스턴스에서 오버라이드할 수도 있습니다.
![]() |
![]() |
---|---|
픽셀 애니메이션 보유 머티리얼 프로퍼티 | 픽셀 애니메이션 보유 머티리얼 인스턴스 프로퍼티 오버라이드 |
이 세팅은 TSR이 입력으로 사용하는 속도 버퍼 내 머티리얼로 프리미티브를 인코딩합니다. 템포럴 업스케일러에서 머티리얼은 UMaterial bHasPixelAnimation 입력에 마스크를 표시합니다. 이 마스크는 이러한 픽셀을 무시하기 위한 템포럴 슈퍼 해상도 시각화 모드의 깜빡임 템포럴 분석 입력의 일부로 사용됩니다.

히스토리 리저렉션
중간, 높음, 에픽, 시네마틱 TSR 안티 에일리어싱 엔진 퀄리티 그룹에서 기본적으로 활성화됩니다. r.TSR.Resurrection.*
콘솔 변수로 퀄리티를 제어할 수 있습니다.
TSR의 히스토리 리저렉션은 직전 프레임을 사용할지, 또는 현재 프레임의 디테일과 더 일치하는 히스토리의 이전 '리저렉션' 프레임을 사용할지를 결정하는 프로세스입니다. 이 프로세스에서는 노이즈 및 고스팅 아티팩트를 제한하거나 방지하기 위해 이미지를 안정화하도록 시도합니다. 이러한 고스팅 아티팩트는 이전에 누적된 디테일이 오클루전, 셰이딩 변화, 프레임을 벗어나는 오브젝트 등 다양한 이유로 폐기되기 때문에 발생합니다. 이러한 디테일이 다시 표시되면 TSR은 디테일을 다시 누적해야 하므로 고스팅 아티팩트를 유발합니다.
TSR의 리저렉션된 프레임 히스토리를 통해 현재 프레임과의 비교를 위해 히스토리에서 제한된 수의 프레임에 액세스할 수 있습니다. 히스토리 리저렉션이 비활성화되면, 현재 프레임으로 재투영되는 디테일을 비교할 때 이전 프레임만 사용할 수 있습니다. 새 디테일이나 누락된 디테일을 누적해야 하며, 이는 고스팅 아티팩트의 주된 원인이 됩니다.

TSR 리저렉션이 활성화된 경우, 이전 퍼시스턴트 프레임의 히스토리가 Texture2DArray 내 메모리에 유지됩니다. 이 배열은 이전 프레임 히스토리를 저장하는 데 사용되는 배열과 동일합니다. 현재 프레임과 더 많이 일치하는 경우 히스토리에서 사용 가능한 가장 오래된 퍼시스턴트 프레임이 바로 직전 프레임 대신 비교 및 사용됩니다. 이러한 프레임이 Texture2DArray에 저장되고 글로벌 셰이더는 배열에서 가져온 이전 프레임 또는 리저렉션된 프레임 중 하나를 재투영하므로 리저렉션 히스토리 업데이트의 비용은 많이 들지 않습니다. 비용은 주로 리저렉션 마스크 에지의 추가 캐시 메모리 대역폭에서 발생하지만, Texture2DArray 히스토리로 인해 텍스처 페치의 수는 완전히 같습니다.
이전 프레임보다 일치율이 높은 여러 개의 프레임이 있는 경우, 이러한 프레임을 현재 프레임과 비교하여 사실인 경우 재투영합니다. 프레임 수 및 현재 프레임의 간격에 따라 오래된 퍼시스턴트 프레임은 제거되어 새 프레임으로 교체됩니다.

히스토리 리저렉션이 토글되어 꺼졌을 때와 켜졌을 때의 결과를 비교할 수 있습니다. 리저렉션 히스토리를 비교 및 재투영에 사용할 수 없는 경우 이전 프레임이 사용되며, 디테일을 다시 누적해야 하므로 프로세스에서 고스팅 현상이 발생하는 경우도 있습니다. 이는 애니메이션을 통해 무기를 교체하는 아래 프레임에서 특히 명확하게 확인할 수 있습니다.
![]() |
![]() |
---|---|
TSR 리저렉션 비활성화됨 | TSR 리저렉션 활성화됨 |
누적된 샘플 입력을 뷰포트에서 전체 크기로 보려면 콘솔 명령 r.TSR.Visualize 0
을 사용하세요.
템포럴 슈퍼 해상도 시각화 모드의 Resurrection Mask 및 Resurrected Frame 입력은 현재 및 이전 프레임의 리저렉션 마스크 색(녹색)으로 표시된 프레임 영역과 리저렉션된 프레임 바운드 바깥에 있어 리저렉션이 불가능한 픽셀(분홍색)을 보여줍니다.

프로젝트의 요구사항에 맞는 퍼시스턴트 프레임 히스토리의 수를 환경설정하는 것이 좋습니다. 이 작업은 다음 콘솔 변수를 통해 가능합니다.
r.TSR.Resurrection.PersistentFrameCount
: 향후의 히스토리 리저렉션을 위해 기록할 퍼시스턴트 프레임의 수를 설정합니다. 이는 전체 TSR 히스토리의 메모리 풋프린트를 늘립니다. 이 값은 2 이상의 짝수 여야 합니다.r.TSR.Resurrection.PersistentFrameInterval
: 퍼시스턴트 프레임이 향후의 히스토리 리저렉션을 위해 히스토리에 얼마나 자주 기록되어야 하는지 프레임 수로 설정합니다. TSR 히스토리의 메모리 풋프린트에는 영향을 미치지 않습니다. 이 값은 1 이상의 홀수 여야 합니다. 콘텐츠에 맞게 미세조정하려면r.TSR.Visualize 5
를 사용하세요.
TSR의 고스팅 현상 해결하기
다음은 프로젝트의 고스팅 현상을 해결할 수 있는 몇 가지 방법입니다.
-
고스팅 현상의 원인이 TSR인지 또는 다른 이유가 있는지 확인합니다.
템포럴 업스케일러 시각화 모드를 사용하여 입력 뷰에서 고스팅 현상이 보이는지 살펴봅니다. 보이는 경우
DumpGPU
명령 및 뷰어를 사용하여 어떤 시스템이 TSR에서 고스팅 현상을 유발하고 있는지 확인합니다.고스팅 현상의 원인이 TSR인지 확실하지 않은 경우 다른 안티 에일리어싱 방식으로 전환해 보거나 안티 에일리어싱을 모두 비활성화하여 고스팅 현상이 여전히 일어나는지 확인합니다.
-
잘못된 모션 벡터가 아티팩트나 고스팅 현상을 유발하나요?
TSR은 모션 벡터에 의존하여 불투명 지오메트리를 재투영합니다. 오브젝트 재투영 정렬을 확인하는 것은 고스팅 현상을 방지하는 데 중요합니다. 모션 벡터가 고스팅 현상의 원인이고, 문제가 전체 씬이 아닌 특정 오브젝트에서만 발생하는지 확인하여 결정할 수 있는 경우도 있습니다.
경우에 따라 모션 벡터 문제가 머티리얼 세팅에서 속도를 덮어쓰는 구름 등의 미세한 반투명 이펙트에 의해 탐지될 수도 있습니다. 콘솔 명령
r.Translucency.Velocity 0
을 사용하여 이 사례에 해당하는지 여부를 빠르게 확인할 수 있습니다.월드 포지션 오프셋이 애니메이션 머티리얼 파라미터에 기반하는지 여부를 확인해 보고, 기반하는 경우 Previous Frame Switch 노드가 이전 프레임의 값에 피딩되는지 확인합니다. 머티리얼에 이를 구성하는 방법에 대해 알아보려면 Utility 머티리얼 표현식을 참조하세요.
모션 벡터 계산에는 인스턴스 트랜스폼 모션당 자동 속도 벡터가 없습니다.
-
TSR의 깜빡임 템포럴 분석이 고스팅 현상을 유발하나요?
깜빡임 템포럴 분석을 조사하기 전에 모션 벡터가 올바르다는 것이 확실해야 합니다. 그렇지 않으면 깜빡임 템포럴 분석이 고스팅 현상의 원인이라고 오해할 수 있습니다.
템포럴 슈퍼 해상도 시각화 모드를 사용하여 고스팅 현상이 발생하는 프레임의 빨간색 영역을 찾습니다. 텍스처 패닝과 같은 셰이더 애니메이션이 적용된 불투명 머티리얼이라면 머티리얼 세팅 픽셀 애니메이션 보유 가 설정되어 있어야 합니다. 자세한 내용은 이 페이지의 픽셀 애니메이션을 사용하는 머티리얼 섹션을 참조하세요.
-
고스팅 아티팩트를 유발하는 오브젝트는 반투명인가요?
템포럴 업스케일러 시각화 모드를 사용하여 오브젝트가 Translucency.AfterDOF.Color 입력 뷰에 있는지 확인합니다. TSR의 셰이딩 거부는 모든 머티리얼의 디폴트인 After DOF 반투명에 비교적 엄격한 기준을 적용합니다. 기본적으로 속도를 드로하지 않으며 올바르게 재투영하는 것이 불가능하기 때문입니다. 자세한 내용은 이 페이지의 TSR 및 반투명 섹션을 참조하세요.
![]() |
![]() |
---|---|
반투명 머티리얼이 뎁스 오브 필드 뒤에 발생하도록 설정됨 | 반투명 머티리얼이 뎁스 오브 필드 앞에 발생하도록 설정됨 |
템포럴 슈퍼 해상도 관련 자주 묻는 질문
이 페이지에서 논의된 주제에 대한 자주 묻는 질문과 답변은 템포럴 슈퍼 해상도 관련 자주 묻는 질문을 참조하세요.
콘솔 변수
콘솔 변수 이름 | 설명 |
---|---|
r.TSR.16BitVALU |
bSupportRealTypes=RuntimeDependent를 보유한 플랫폼에서 16비트 VALU를 사용할지 여부입니다. |
r.TSR.16BitVALU.AMD |
AMD 데스크톱 GPU에서 16비트 VALU를 사용할지 여부를 오버라이드합니다. |
r.TSR.16BitVALU.Intel |
Intel 데스크톱 GPU에서 16비트 VALU를 사용할지 여부를 오버라이드합니다. |
r.TSR.16BitVALU.Nvidia |
NVIDIA 데스크톱 GPU에서 16비트 VALU를 사용할지 여부를 오버라이드합니다. |
r.TSR.AplhaChannel |
TSR이 씬 컬러의 알파 채널을 처리해야 하는지 여부를 제어합니다.
|
r.TSR.AsyncCompute |
TSR이 비동기 연산에서 실행하는 방식을 제어합니다. 일부 TSR 패스는 이전 패스로 오버랩할 수 있습니다.
|
r.TSR.Debug.ArraySize |
TSR.Debug.* 렌더 종속성 그래프(Render Dependency Graph, RDG) 텍스처의 배열 크기입니다. |
r.TSR.ForceSeparateTranslucency |
TSR이 활성화될 때마다 r.SeparateTranslucency 를 오버라이드합니다. 이 옵션은 기본적으로 활성화됩니다. |
r.TSR.History.R11G11B10 |
'1'로 설정된 경우 히스토리의 비트 뎁스를 선택하세요. 이전 프레임의 히스토리 재투영 및 출력과 새로운 히스토리의 작성 모두에 메모리를 저장하여 TSR UpdateHistory의 런타임 퍼포먼스에서 특히 중요한 메모리 대역폭을 저장합니다. 이 최적화는 r.PostProcessing.PropagateAlpha=1 을 사용할 경우 미지원됩니다. 또한, r.TSR.History.ScreenPercentage 가 200으로 증가하면 TSR 히스토리 해상도에서 TSR 출력 해상도로의 다운스케일링 패스로 인해 TSR 출력의 비트 뎁스 대비 히스토리에서 두 개의 추가 인코딩 비트가 추가됩니다. |
r.TSR.History.SampleCount |
TSR 히스토리에서 각 출력 픽셀에 대한 최대 샘플 수. 값이 클수록 스태틱 이미지에 대한 하이라이트가 안정화되며, 파이어플라이 등 일부 VFX 스타일에서 추가 고스팅을 도입할 수도 있습니다. TSR.History.Metadata 인코딩으로 인해 최소 8개에서 최대 32개의 샘플을 가질 수 있습니다. 기본 샘플 수는 16입니다. |
r.TSR.History.ScreenPercentage |
출력 해상도를 바탕으로 한 TSR 히스토리의 해상도 배수입니다. 해상도 증가로 런타임 비용이 TSR에 추가되지만 재투영 전체에 걸쳐 히스토리에 저장된 디테일을 통해 선명도와 안정성이 향상된 상태로 유지될 수 있게 합니다. 기본적으로 NyQuist-Shannon 샘플링 정리에 따른 특정 프로퍼티가 사용되고 히스토리에서 누적 디테일의 샘플 레이트에 대한 충분한 조건을 확립하기 때문에 값이 200으로 설정됩니다. 결과적으로 100~200 값만 지원됩니다. 이 값은 안티 에일리어싱 엔진 퀄리티 그룹으로 제어됩니다. 에픽 및 시네마틱 퀄리티 레벨은 200을 사용하고 다른 레벨들은 100을 사용합니다. |
r.TSR.History.UpdateQuality |
TSRHistoryUpdate 패스에서 히스토리의 업데이트 퀄리티 셰이더 순열을 선택하세요. 현재 sg.AntiAliasingQuality 엔진 퀄리티 그룹으로 수행됩니다. 각 그룹의 제공 사항은 TSRUpdateHistory.usf 에서 DIM_UPDATE_QUALITY 를 참조하여 커스터마이징할 수 있습니다. |
r.TSR.RejectionAntiAliasingQuality |
히스토리를 거부해야 할 경우 TSR의 기본 스페이셜 안티 에일리어싱 기술 퀄리티를 제어합니다. 렌더링 해상도가 디스플레이 해상도보다 훨씬 낮지 않은 경우 중요하지 않은 반면, 이 기술은 다음 두 가지 이유로 인해 낮은 렌더링 해상도를 숨길 때 필수입니다. 에일리어싱의 스크린 스페이스 크기가 렌더링 해상도와 비례합니다. 그리고 반전되거나, 낮은 해상도에서 렌더링은 디스플레이당 1개 이상의 렌더링당 픽셀에 이르기 위해 보다 많은 프레임이 필요하기 때문입니다. 기본적으로 이 옵션은 낮은 엔진 퀄리티 그룹을 제외한 모든 안티 에일리어싱 엔진 퀄리티 그룹에 대해 활성화됩니다. |
r.TSR.Resurrection |
TSR이 이전에 폐기된 디테일을 여러 프레임 전에 리저렉션하도록 합니다. TSR은 이미지를 안정화하기 위해 디테일을 재투영할 때 직전 프레임 또는 현재 프레임과 많이 일치하는 히스토리 내 프레임을 조회합니다. TSR의 리저렉션 작동 방식을 알아보려면 이 페이지의 히스토리 거부 섹션을 참조하세요. |
r.TSR.Resurrection.PersistentFrameCount |
향후의 히스토리 리저렉션을 위해 히스토리에 기록할 퍼시스턴트 프레임의 수를 환경설정합니다. 히스토리 리저렉션에 저장되는 프레임 수를 늘리면 전체 TSR 히스토리가 늘어납니다. 이 값은 2 이상의 짝수여야 합니다. (디폴트는 2입니다.) TSR의 리저렉션 작동 방식을 알아보려면 이 페이지의 히스토리 거부 섹션을 참조하세요. |
r.TSR.Resurrection.PersistentFrameInterval |
퍼시스턴트 프레임이 향후의 히스토리 리저렉션을 위해 히스토리에 얼마나 자주 기록되어야 하는지 프레임 수로 환경설정합니다. TSR 히스토리의 메모리 풋프린트에는 영향을 미치지 않습니다. 이 값은 1 이상의 홀수여야 합니다. 콘텐츠에 맞게 이 파라미터를 미세조정하려면 TSR 시각화 및 r.TSR.Visualize 5 를 사용하세요. (디폴트는 31입니다.) TSR의 리저렉션 작동 방식을 알아보려면 이 페이지의 히스토리 거부 섹션을 참조하세요. |
r.TSR.ShadingRejection.ExposureOffset |
셰이딩 거부는 사용자에게 표시되는 최종적인 선형 컬러 픽셀이 얼마나 밝은지 대략적으로 알아야 합니다. 또한 셰이딩 거부는 이 변수는 TSR의 거부 휴리스틱 기법에서 오직 선형 컬러 스페이스 노출만 조정합니다. 높은 값은 섀도의 LDR 강도를 높이며, 이는 이를 검증하는 최선의 방법은 템포럴 업스케일러 시각화 모드의 TSR.Flickering.Luminance 입력을 살펴보거나, DumpGPU 뷰어에서 sRGB 소스 컬러 스페이스 내 톤매퍼 출력에 대한 TGB 선형 [0;1] 소스 컬러 스페이스를 살펴보는 것입니다. |
r.TSR.ShadingRejection.Flickering |
TSR의 불안정성은 대부분 셰이딩 거부의 안정성으로 인해 발생합니다. 이는 다음과 같은 여러 이유로 인해 발생할 수 있습니다.
활성화된 경우, 이 휴리스틱은 TSR.Moire.Luma 리소스에 저장된 반투명 드로잉이 연속 프레임에 걸쳐 발전하기 직전 프레임의 휘도를 모니터링합니다. 깜빡이는 픽셀 대비 애니메이션 픽셀로 간주되는 것을 결정할 때 주의해야 할 또 다른 점은 깜빡임이 프레임 레이트와는 관계없이 발생하지만 시간을 기준으로 일어나거나, 일어나야 하는 비주얼 이펙트가 프레임 레이트와는 상관없다는 점입니다. 즉, 초당 60프레임에서 부드럽게 보이는 비주얼 이펙트가 24fps처럼 낮은 프레임 레이트에서 '깜빡이는' 것처럼 보일 수 있습니다. 아티스트가 만든 비주얼 이펙트로 인한 고스팅을 방지하기 위해, 콘솔 변수 기본적으로 이 콘솔 변수는 높음, 에픽, 시네마틱 레벨의 안티 에일리어싱 엔진 퀄리티 그룹에서 활성화됩니다. |
r.TSR.ShadingRejection.Flickering.AdjustToFrameRate |
깜빡임 시간 세팅(r.TSR.ShadingRejection.Flickering.Period )이 프레임 레이트 제한보다 낮은 경우 프레임 레이트로 조정해야 하는지 여부는 r.TSR.ShadingRejection.Flickering 에서 자세한 내용을 확인하세요. |
r.TSR.ShadingRejection.Flickering.FrameRateCap |
렌더링 프레임 레이트가 낮은 경우 r.TSR.ShadingRejection.Flickering.Period 자동 조정이 있는 프레임 레이트 제한(헤르츠 단위) 자세한 내용은 r.TSR.ShadingRejection.Flickering 항목을 참조하세요. 기본적으로 60hz로 설정합니다. |
r.TSR.ShadingRejection.Flickering.MaxParallaxVelocity |
건물의 창문 인테리어가 포함된 도시 샘플과 같이 패럴랙스 오클루전 매핑을 사용하는 일부 머티리얼은 이 페이크 인테리어 지오메트리의 모션 벡터를 정확하게 렌더링하지 못하는 경우가 종종 있습니다. 이로 인해 휴리스틱이 깜빡거리지 않아도 깜빡거린다고 판단하게 할 수 있습니다. 이 변수는 고스팅이 발생하지 않도록 휴리스틱을 비활성화해야 하는 시점에 r.TSR.ShadingRejection.Flickering.FrameRateCap 에서 정의된 프레임 레이트의 1080p 픽셀로 패럴랙스 속도를 정의합니다. |
r.TSR.ShadingRejection.Flickering.Period |
높거나 같은 주파수에서 루마 진동이 고려되며, 고스팅하여 이미지를 안정화하는 프레임의 주기. 자세한 내용은 r.TSR.ShadingRejection.Flickering 항목을 참조하세요. 기본적으로 3으로 설정합니다. |
r.TSR.ShadingRejection.SampleCount |
총 셰이딩 거부 이후 각 출력 픽셀에서의 최대 샘플 수. 값이 낮을수록 히스토리의 셰이딩 거부 이후 이미지의 분명해지지만 새로운 상세 정보를 누적하는 후속 프레임에서 픽셀의 불안정성은 높아지고, 시각적으로 방해가 될 수 있습니다. 기본적으로 2.0으로 설정합니다. |
r.TSR.ShadingRejection.TileOverscan |
셰이딩 거부가 GPU에서 컨볼루션 네트워크를 실행합니다. 이는 메인 비디오 메모리로의 라운드 트립 없이 수행됩니다. 하지만 타일에서 컨볼루션을 많이 변경하면 에지 주변의 일부 컨볼루션이 손상되므로 이를 숨기기 위해 타일을 약간 오버랩해야 합니다. 값이 높을수록 타일링 아티팩트에 덜 취약하지만 퍼포먼스 손실이 발생합니다. |
r.TSR.Velocity.WeightClampingPixelSpeed |
히스토리의 높은 주파수가 가중치 범위제한에 기여하게 되는 출력 픽셀 속도를 정의합니다. 이는 기본적으로 픽셀 속도가 r.TSR.Velocity.WeightClampingPixelSpeed 보다 작은 경우 r.TSR.Velocity.WeightClampingSampleCount 이펙트를 선형보간하는 것입니다. |
r.TSR.Velocity.WeightClampingSampleCount |
출력 속도가 r.TSR.Velocity.WeightClampingPixelSpeed 로 도달한 경우 히스토리를 범위제한하기 위해 히스토리 픽셀에서 세는 샘플 수입니다. 값을 클수록 움직임의 안정성이 커지지만 각 히스토리 재투영의 연속된 컨볼루션으로 인해 추가 블러 비용이 발생합니다. r.TSR.History.Metadata 콘솔 명령으로 TSR 히스토리에서 샘플 수를 시각화할 수 있습니다. 출력 픽셀이 아닌 픽셀 히스토리에서 샘플 수를 제한합니다. 따라서 설계에 따라 값이 낮을수록 높은 TSR 스크린 퍼센티지로 덜 눈에 띄게 됩니다( r.TSR.History.ScreenPercentage ). 이러한 세팅에 관계없이 일방적이고 자동 증가시키면 추가 런타임 비용으로 디테일 재투영의 선명도를 유지하면서 템포럴을 보다 안정화합니다. 예를 들어, 스토리 기반 게임이 '시네마틱' 룩을 위해 4.0 세팅을 유지하는 반면 포트나이트와 같은 경쟁 게임은 2.0으로 낮추는 것을 선호합니다. (기본적으로 4.0f입니다.) |
r.TSR.Visualize |
이 변수에 다음 값 중 하나를 사용하여 템포럴 슈퍼 해상도 시각화 모드의 입력을 구성하는 다양한 시각화 입력을 볼 수 있습니다.
|
r.TSR.WaveOps |
컨볼루션 속도를 높이기 위해 셰이딩 거부 휴리스틱에서 웨이브 옵션을 사용할지 여부입니다. 셰이딩 거부 휴리스틱 최적화는 셰이더 컴파일러에 어려울 수 있으며, 손상되거나 퀄리티 손실을 보일 수도 있습니다. 이러한 최적화는 DXC를 활용해 SPIR-V 백엔드에서 컴파일 시간에 추가되기 때문에 SPIR-V 플랫폼(주로 Vulkan 및 Metal)에서 현재 비활성화되어 있으며, 이로 인해 에디터 시작이 오래 걸릴 수 있습니다. |
r.TSR.WaveSize |
사용할 WaveSize를 오버라이드합니다.
|