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


위의 이미지는 이 페이지의 너비로 제한된 4K 이미지입니다. 압축되지 않은 전체 해상도로 이미지를 보려면 이미지를 우클릭한 뒤 컴퓨터에 저장하거나, 새 브라우저 창에서 이미지를 엽니다.
템포럴 슈퍼 해상도의 특징은 다음과 같습니다.
- 1080p의 낮은 입력 해상도로 네이티브 4K 퀄리티에 가깝게 프레임을 렌더링합니다.
- 언리얼 엔진 4의 디폴트 템포럴 안티 에일리어싱 메서드를 사용했을 때보다, 디테일이 정교한 배경에서 보이던 '고스팅(ghosting)' 아티팩트가 줄어들었습니다.
- 복잡도가 높은 지오메트리에서 깜빡임이 줄어들었습니다.
- 콘솔 플랫폼에서 동적 해상도 스케일링을 지원합니다.
- D3D11, D3D12, Vulkan, Metal, PlayStation 5, Xbox Series S|X를 지원하는 모든 하드웨어에서 실행됩니다.
- 셰이더가 PlayStation 5 및 Xbox Series S|X GPU 아키텍처에 맞게 최적화됩니다.
렌더링 체인에서 TSR은 뎁스 오브 필드 후에 발생하는 모든 렌더링 대상이 업스케일링됩니다.
TSR의 엔진 퀄리티
여러 지원 플랫폼에서 템포럴 슈퍼 해상도를 사용할 수 있지만, 프로젝트의 필요에 따라 각 플랫폼의 업스케일링 세팅을 커스터마이징하고 싶을 수도 있습니다. 아래 섹션에서는 프로젝트에서 TSR을 확인한 뒤 적절하게 스케일링하는 몇 가지 방법을 살펴볼 수 있습니다.
디테일의 템포럴 누적에 대한 주의사항 이해하기
TSR이 낮은 해상도에서 렌더링하여 프레임 레이트를 향상한다는 점만 광고하는 것은 충분치 않습니다. 템포럴 업스케일링 툴은 보통 저마다 주의사항이 있기 때문입니다. 스태틱 이미지 렌더링에 프레임 시간이 충분할 경우 모든 템포럴 업스케일링 툴이 똑같은 결과를 렌더링할 수 있을 것입니다. 다른 템포럴 업스케일링 툴과 마찬가지로, TSR은 저해상도 프레임을 시간에 따라 누적하여 이미지로 수렴하도록 하며, 이미지의 디테일은 충분한 디테일이 누적된 후에만 파악할 수 있습니다. 예를 들어, 지오메트리의 두께는 첫 프레임에서는 알 수 없습니다.


렌더링 해상도는 스크린 퍼센티지로 조절됩니다. 이는 하나의 프레임에 사용할 수 있는 정보의 양을 조절합니다. 수렴에 필요한 나머지 정보는 해당 프레임의 렌더링되어야 하는 남은 부분에 따라 달라집니다. 즉, TSR로 표시되는 정보는 렌더링되는 프레임의 해상도와 프레임 레이트에 모두 의존합니다. 이 두 가지 요소가 디테일이 누적되는 속도에 영향을 미치기 때문입니다.
GPU뿐만 아니라 CPU 바운드 또는 주사율이 고정된 모니터의 수직동기 등도 TSR에 영향을 미치는 프레임 레이트를 제한할 수 있습니다.
이 때문에 콘솔 명령 stat tsr 을 사용하면 전체 이미지에 대한 TSR의 누적에 영향을 미치는 요소를 파악하는 데 도움이 됩니다. 이 명령을 호출하면 일반적으로 stat unit 을 호출할 때 표시되는 내용에 TSR feed 및 TSR1spp 통계가 추가됩니다.
TSR feed 는 TSR에 피딩되는 초당 픽셀 수를 보여주며, 이는 TSR이 전체 이미지로 수렴해야 하는 데이터의 양을 파악하는 중요한 거시적 지표입니다. Rendering Resolution Width * Rendering Resolution Height * FrameRate = Display Resolution Width * Display Resolution Height * ScreenPercentage^2 * FrameRate. 이 지표의 장점은 디스플레이 해상도와 관계없이 모션의 거시적 이미지 퀄리티를 나타낸다는 것입니다. 스케일링에 대한 세부 사항은 다음과 같습니다.
| 디스플레이 해상도 | 스크린 퍼센티지 | 프레임 레이트 | 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이 하나의 픽셀당 샘플에 도달할 충분한 데이터를 보유하기 위해 필요한 시간입니다. 이는 디테일을 빠르게 누적해야 하는 디스오클루전이 있는 모션에서 특히 중요합니다. TSR 1spp = 1000 / (ScreenPercentage^2 * FrameRate).
| 스크린 퍼센티지 | 프레임 레이트 | 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밀리초가 소요된다고 하면, 화면의 디스오클루전 영역이 충분한 데이터를 보유하기까지 66.4ms, 4배 더 긴 시간이 걸린다는 것을 의미합니다(4*16.6 = 66.4ms).
TSR의 업스케일링 GPU 비용
TSR의 주된 목표는 업스케일링으로, 대다수의 GPU 작업은 지정된 해상도를 기반으로 스케일링됩니다. 이는 TSR이 렌더링 해상도보다 높은 디스플레이 해상도에서 수행되어야 할 때의 일부 GPU 비용 때문입니다.
stat gpu 를 사용하여 콘솔에서 GPU 통계 디스플레이를 열 수 있으며, 이를 통해 주요 스크린 퍼센티지를 조절하여 100% 스크린 퍼센티지에서 렌더링될 때와 50% 스크린 퍼센티지에서 렌더링될 때의 퍼포먼스 차이를 확인할 수 있습니다. 에인션트의 협곡 샘플 프로젝트에서 가져온 아래 예시가 이를 보여줍니다.
| r.ScreenPercentage=100에서 ~0.79ms | r.ScreenPercentage=50에서 ~0.43ms |
| 이미지를 클릭하면 최대 크기로 볼 수 있습니다. | 이미지를 클릭하면 최대 크기로 볼 수 있습니다. |
TSR의 패럴랙스 휴리스틱은 프레임의 씬 컬러 및 반투명보다는 뎁스 및 속도 버퍼에 따라 달라집니다. 이는 뎁스 및 속도 버퍼가 씬 컬러 및 반투명 버퍼보다 GPU에서 훨씬 빨리 완료되는 경우가 많기 때문입니다. 이로 인해 전체 TSR 패럴랙스 휴리스틱이 GPU에서 비동기적으로 계산을 수행하고 GPU가 잘 사용되지 않는 갭을 r.TSR.AsyncCompute=2 로 다른 렌더링 알고리즘을 통해 채울 수 있습니다.
PlayStation 5 및 Xbox Series X의 포트나이트 챕터 4에서는 전체 배틀로얄 퍼포먼스 리플레이의 퍼포먼스를 테스트했을 때 TSR의 총 GPU 비용 중 약 0.5ms가 상쇄되었습니다. 리플레이에서 약 0.1ms가 절약되었고, 효율적인 TSR 비용이 1.5ms로 절감되었으며, 프레임 렌더링을 마무리하는 필수 경로 GPU 비용은 1.1ms로 절감되었습니다.
콘솔 변수
엔진 퀄리티 세팅은 모든 플랫폼에서 TSR의 퀄리티를 스케일링합니다. 낮음(Low) 에서 시네마틱 까지 사전 정의된 엔진 퀄리티 그룹이 사용됩니다. 각 그룹은 안티 에일리어싱을 비롯하여 다양한 렌더링 프로퍼티에 영향을 미치는 콘솔 변수 세트에 의해 정의됩니다.
[언리얼 엔진 루트]/Engine/Config 폴더에서 BaseScalability.ini 파일을 열어 어떤 엔진 퀄리티 세팅이 사용되는지 점검할 수 있습니다. 사용되는 안티 에일리어싱 퀄리티 그룹에 따라 TSR이 어떻게 스케일링되는지 확인하려면 AntiAliasingQuality 섹션을 살펴보세요. [프로젝트 루트]\Config\DefaultScalability.ini 에서 세팅을 변경하여 본인의 프로젝트에 맞게 안티 에일리어싱 퀄리티 그룹을 수정할 수 있습니다.
프로젝트 조정 예시로는 오래된 데이터가 현재 프레임에 오류를 유발하는 것을 방지하기 위해 히스토리를 거부해야 할 때 사용되는 TSR의 스페이셜 안티 에일리어싱 알고리즘이 있습니다. 더 높은 해상도 또는 프레임 레이트로 렌더링하려는 게임 프로젝트의 경우 눈에 보이는 에일리어싱이 거부 대상이 아니므로 이 옵션이 필요하지 않을 수 있습니다. TSR의 히스토리 거부는 r.TSR.RejectionAntiAliasingQuality 로 제어할 수 있습니다.
템포럴 업스케일링의 숨은 추가 GPU 비용
템포럴 슈퍼 해상도를 비롯한 템포럴 업스케일링 툴은 렌더러의 포스트 프로세싱 체인 도중에 적용됩니다. 이는 모션 블러나 톤매퍼 등 TSR 이후 실행되는 패스는 이제 주요 스크린 퍼센티지로 스케일링되지 않는다는 것을 의미합니다. 스페이셜 업스케일링 툴(r.SecondaryScreenPercentage.GameViewport)을 사용하는 보조 스크린 퍼센티지가 없으면 TSR의 출력 해상도는 렌더링 해상도가 아니라 디스플레이 해상도로 실행됩니다. 기본적으로 TSR이 활성화된 경우, TSR 이후 실행되는 패스의 숨은 템포럴 업스케일링 비용을 줄이는 데 많은 노력이 필요합니다.
모션 블러
모션 블러 최적화를 사용하면 낮은 해상도의 TV에서도 항상 2160p 백버퍼를 표시하는 PlayStation 5 및 Xbox Series X 등의 플랫폼에서 3배에 달하는 모션 블러 GPU 퍼포먼스 비용을 줄일 수 있습니다.
stat gpu사용 시 TSR 비용 증가:- 모션 블러 활성화 및 비활성화 비교 시 TSR 비용은
stat gpu를 사용한 경우 약간 증가할 수 있습니다. - 모션 블러가 활성화된 경우 일반적으로 입력 해상도에서 실행되는 속도 평탄화(Velocity Flatten) 패스를 TSR이 대체합니다. 이는 콘솔 명령 r.MotionBlur.AllowExternalVelocityFlatten을 통해 제어되며 기본적으로 활성화됩니다.
- TSR은 반해상도 씬 컬러를 출력하여 대규모 디렉셔널 블러 커널을 유발할 수 있는 메모리 대역폭의 병목 구간을 줄여줍니다. 이는 콘솔 명령
r.MotionBlur.HalfResInput을 통해 제어되며 기본적으로 활성화됩니다.
- 모션 블러 활성화 및 비활성화 비교 시 TSR 비용은
- 디렉셔널 블러의 1/2 해상도:
- 디스플레이 해상도에서 발생하는 디렉셔널 블러는 움직임이 클 경우 자동으로 1/2 해상도로 실행되도록 최적화됩니다. 이 기능을 활성화하면 모션 블러의 VALU 비용이 줄어듭니다.
- 이 최적화를 활성화하려면 콘솔 명령
r.MotionBlur.HalfResGather 1을 사용하면 됩니다.
- 모션 블러 1/2 해상도 및 1/4 해상도:
- TSR과 모션 블러는 1/2 해상도 또는 1/4 해상도를 출력할 수 있습니다. 이는 모션 블러 이후 실행되는 가우시안 블룸, 컨볼루션 블룸, 렌즈 플레어, 시각 적응(자동 노출) 및 로컬 노출에 중요합니다.
PostProcessQuality 엔진 퀄리티 그룹은 Engine/Config/BaseScalability.ini에서 일부 r.MotionBlur.* 를 스케일합니다.
추가 참고사항
문제 해결 TSR
TSR을 템포럴 업스케일링 툴로 사용하면, 템포럴 업스케일링 툴에 영향을 미치는 아티팩트를 진단해야 하는 경우가 있습니다. VisualizeTemporalUpscaler 표시 플래그를 사용하여 원시 입력과 출력 버퍼를 출발점으로 볼 수 있습니다.
템포럴 스케일링 툴(TSR, TAAU 또는 서드파티 플러그인) 을 선택하여 레벨 에디터의표시(Show) > 시각화(Visualize) 메뉴에서 이 표시 플래그에 액세스할 수 있습니다.
자세한 정보는 템포럴 업스케일링 툴을 참조하세요.
픽셀 깜빡임 조정
프레임 내 픽셀 깜빡임 현상이 발생하는 이유는 다양하며, 몇몇 경우에는 완화할 수 있습니다. 몇 가지 콘솔 변수를 통해 비스듬한 각도로 건물을 볼 때나 픽셀 셰이더 애니메이션에서와 같이 의도적인 이펙트와 픽셀 깜빡임 현상 사이의 차이를 정의할 수 있습니다.
r.TSR.ShadingRejection.Flickering.Period 를 사용하여 주파수가 같거나 더 큰 루마 진동이 깜빡임 현상으로 간주되어 안정화되어야 하는 60hz 프레임의 주기를 설정할 수 있습니다. 그러나 이러한 안정화는 이미지의 원하지 않는 영역에서 발생한 경우 고스팅 현상을 유발할 수 있습니다.
![]() |
![]() |
|---|---|
| r.TSR.ShadingRejection.Flickering.Period: 0 | r.TSR.ShadingRejection.Flickering.Period: 3(기본) |
| 스크린 퍼센티지: 100 | 스크린 퍼센티지: 100 |
이 TSR 세팅은 픽셀 셰이더 애니메이션 등 의도한 비주얼 이펙트와 픽셀 깜빡임을 구분하므로 중요합니다. 하지만 깜빡임은 프레임 레이트에 관계없이 발생한다는 점이 중요한 차이점입니다. 비주얼 이펙트는 시간을 기반으로 하며, 따라서 프레임 레이트와는 별개로 작동합니다. 이는 60hz에서 매끄럽게 보이는 비주얼 이펙트가 24hz와 같이 낮은 프레임 레이트에서는 '깜빡이는 것처럼' 보일 수도 있다는 뜻입니다.
이 부분이 중요한 이유는 TSR이 GPU 퍼포먼스를 충족하기 위해 스케일링되므로 아티스트가 제작한 비주얼이 프레임 레이트에 영향을 받지 않는 상태로 남기 때문입니다. 즉, 플레이어의 머신이 예상 프레임 레이트보다 낮은 프레임 레이트로 실행될 경우 비주얼이 변하는 의도치 않은 이펙트가 발생할 수 있습니다. 이러한 목적을 위해 콘솔 명령 r.TSR.ShadingRejection.Flickering.Period 는 프레임 레이트가 r.TSR.ShadingRejection.Flickering.FrameRateCap 으로 정의된 프레임 레이트(기본 60hz) 아래로 떨어질 경우 자동으로 깜빡임 방지를 감소시킵니다. 이는 60hz에서는 안정적인 지오메트릭 디테일이 더 낮은 프레임 레이트에서는 덜 안정적으로 변할 수도 있음을 의미합니다. 이 동작은 기본적으로 활성화되어 있지만, r.TSR.ShadingRejection.Flickering.AdjustToFrameRate 를 통해 비활성화할 수 있습니다.
지원되는 플랫폼
템포럴 슈퍼 해상도는 셰이더 모델 5를 지원하는 모든 데스크톱 하드웨어의 데스크톱 렌더러에서 사용할 수 있습니다. 템포럴 슈퍼 해상도를 지원하는 플랫폼은 다음과 같습니다.
- Windows D3D11 SM5, D3D12 SM5, D3D12 SM6, Vulkan SM5
- Linux Vulkan SM5
- Mac Metal SM5
- PlayStation 5 및 Xbox Series S | X
TSR의 업스케일링 퀄리티 및 동작은 모든 지원 플랫폼에서 정확히 동일합니다. 그러나 TSR은 PlayStation 5 및 Xbox Series S | X 콘솔에 사용되는 AMD RDNA GPU에 맞게 최적화되어 16비트 타입 및 패킹된 인스트럭션을 활용합니다.
콘솔 변수
| 콘솔 변수 이름 | 설명 |
|---|---|
r.TSR.AsyncCompute |
TSR이 비동기 연산에서 실행하는 방식을 제어합니다. 일부 TSR 패스는 이전 패스로 오버랩할 수 있습니다.
|
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.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 |
City Sample처럼 빌딩의 창을 활용한 패럴랙스 오클루전 매핑을 사용하는 일부 머티리얼은 이 페이크 인테리어 지오메트리의 모션 벡터를 종종 정확하게 렌터링할 수 없습니다. 이로 인해 휴리스틱이 깜빡거리지 않아도 깜빡거린다고 판단하게 할 수 있습니다. 이 변수는 고스팅이 발생하지 않도록 휴리스틱을 비활성화해야 하는 시점에 r.TSR.ShadingRejection.Flickering.FrameRateCap 에서 정의된 프레임 레이트의 1080p 픽셀로 패럴랙스 속도를 정의합니다. |
r.TSR.ShadingRejection.Flickering.Period |
높거나 같은 주파수에서 루마 진동이 고려되며, 고스팅하여 이미지를 안정화하는 프레임의 주기. 자세한 내용은 r.TSR.ShadingRejection.Flickering 항목을 참조하세요. 기본적으로 3으로 설정합니다. |
r.TSR.ShadingRejection.SampleCount |
총 셰이딩 거부 이후 각 출력 픽셀에서의 최대 샘플 수. 값이 낮을수록 히스토리의 셰이딩 거부 이후 이미지의 분명해지지만 새로운 상세 정보를 누적하는 후속 프레임에서 픽셀의 불안정성은 높아지고, 시각적으로 방해가 될 수 있습니다. 기본적으로 2.0으로 설정합니다. |
r.TSR.Subpixel.DepthMaxAge |
자체 재투영 히스토리에서 최대 서브픽셀 깊이 수명(프레임). 기본적으로 3프레임입니다. |
r.TSR.Subpixel.IncludeMovingDepth |
이동 서브픽셀 디테일의 깊이가 재투영에 대한 서브픽셀 깊이 히스토리도 포함해야 합니다. 대부분의 경우, 속도만 종종 드로잉하는 경우 이동 오브젝트 속도가 시간 경과에 따라 발전하는 방법을 알 수 없기 때문에 활성화하면 안 됩니다. 이 세팅은 기본적으로 비활성화됩니다. |
r.TSR.Subpixel.Method |
나나이트가 렌더링할 수 있는 디테일 양에 대한 특정 문제는 메시의 디테일이 렌더링된 픽셀보다 종종 얇아서 일부 프레임만 렌더링하게 된다는 점입니다. 이 경우 뎁스나 속도 버퍼가 재투영할 수 없게 됩니다. 이 세팅은 서브픽셀 디테일을 재투영 및 버리는 방법을 제어합니다.
|
r.TSR.Velocity.WeightClampingPixelSpeed |
히스토리의 주파수가 높아 웨이트 범위제한에 기여하는 출력 픽셀 속도를 정의하세요. 이는 기본적으로 픽셀 속도가 r.TSR.Velocity.WeightClampingPixelSpeed 보다 작은 경우 r.TSR.Velocity.WeightClampingSampleCount 이펙트를 선형보간하는 것입니다. |
r.TSR.Velocity.WeightClampingSampleCount |
출력 속도가 r.TSR.Velocity.WeightClampingPixelSpeed 로 도달한 경우 히스토리를 제안하기 위해 히스토리 픽셀에서 세는 샘플 수. 값을 클수록 무브먼트의 안정성이 커지지만 각 히스토리 재투영의 연속된 컨볼루션으로 인해 추가 블러 비용이 발생합니다. vis TSR.History.Metadata 콘솔 명령으로 TSR 히스토리에서 샘플 수를 시각화할 수 있습니다. 출력 픽셀이 아닌 픽셀 히스토리에서 샘플 수를 제한합니다. 따라서 설계에 따라 값이 낮을수록 높은 TSR 스크린 퍼센티지로 덜 눈에 띄게 됩니다( r.TSR.History.ScreenPercentage ). 이러한 세팅에 관계없이 일방적이고 자동 증가시키면 추가 런타임 비용으로 디테일 재투영의 선명도를 유지하면서 템포럴을 보다 안정화합니다. 예를 들어, 스토리 기반 게임이 '시네마틱' 룩을 위해 4.0 세팅을 유지하는 반면 포트나이트와 같은 경쟁 게임은 2.0으로 낮추는 것을 선호합니다. (기본적으로 4.0f입니다.) |
r.TSR.WaveOps |
컨볼루션 속도를 높이기 위해 셰이딩 거부 휴리스틱에서 웨이브 옵션 사용 여부. 셰이딩 거부 휴리스틱 최적화는 셰이더 컴파일러에 어려울 수 있으며, 손상되거나 퀄리티 손실을 보일 수도 있습니다. |

