언리얼 엔진의 템포럴 슈퍼 해상도 관련 자주 묻는 질문 | 언리얼 엔진 5.7 문서

이 페이지는 템포럴 슈퍼 해상도 (Temporal Super Resolution, TSR)와 관련된 자주 묻는 질문을 다룹니다. 이 페이지의 각 섹션은 TSR 기술 개요의 각 섹션에 해당하며, 자세한 내용과 예시는 템포럴 슈퍼 해상도를 참고하세요.

TSR 엔진 퀄리티

TSR에는 업스케일링 세팅을 위한 다양한 커스터마이징 옵션이 포함되어 있어, 프로젝트의 요구 사항에 따라 개별 플랫폼에 맞게 설정할 수 있습니다. TSR의 엔진 퀄리티 옵션 및 기능에 대한 자세한 내용은 템포럴 슈퍼 해상도의 'TSR의 엔진 퀄리티' 섹션을 참고하세요.

Stat GPU에 나타나는 TSR의 런타임 GPU 비용이 예상보다 느린 이유는 무엇인가요?

TSR은 디스플레이 해상도로 업스케일링하기 전에 에일리어싱을 지우기 위해 GPU에서 거의 프레임을 마치기 전에 실행됩니다. TSR은 렌더러의 마지막 컴포넌트로, 여러 프레임에 걸쳐 데이터를 축적하는 데 사용되는 히스토리에 퍼시스턴스 GPU 리소스를 할당합니다. GPU의 비디오 메모리가 다 떨어진 경우, GPU 리소스를 호스트 GPU 메모리에 할당해야 하는 성능 문제를 겪는 첫 번째 컴포넌트는 보통 TSR이 됩니다.

GPU에서 메모리 부족 문제가 발생하면, GPU 크래시 발생을 트리거하는 타임아웃 감지 및 복구(Timeout Detection and Recovery, TDR) 이벤트를 조정해 볼 수 있습니다. 자세한 내용은 GPU 드라이버 크래시 해결하기를 참고하세요.
TSR이 지원하는 스크린 퍼센티지 범위는 얼마인가요?

TSR 셰이더는 콘솔 명령 r.TSR.History.ScreenPercentage 를 사용하여 25%에서 200% 사이 범위에서 스크린 퍼센티지를 처리하도록 설계되었으며, r.ScreenPercentage 를 함께 사용하여 작동합니다. 예를 들어 다음과 같이 설정할 수 있습니다.
- r.TSR.History.ScreenPercentage=200 인 경우, r.ScreenPercentage=50 에서 r.ScreenPercentage=200 까지 입력할 수 있습니다.
- r.TSR.History.ScreenPercentage=100 인 경우, r.ScreenPercentage=25 에서 r.ScreenPercentage=100 까지 입력할 수 있습니다.
TSR feed 및 TSR 1spp의 히스토리를 자세히 살펴보고 TSR이 각 프레임에서 얼마나 많은 정보를 처리해야 하는지 자세히 확인하는 것이 좋습니다.
TSR은 다이내믹 렌더링 해상도를 지원하나요? 어떤 플랫폼이 지원되나요?

예. 다이내믹 해상도를 지원하며 콘솔 플랫폼에서 활성화할 수 있습니다. 하지만 Windows 및 다른 데스크톱 플랫폼에서는 지원 및 활성화되지 않습니다. 이는 TSR에만 해당하는 것이 아닙니다. 현재 이에 대해 연구를 진행하고 있으며 포트나이트에서 테스트하고 있습니다. 현재 발생하는 몇 가지 문제는 다음과 같습니다.
- 다이내믹 해상도의 목적은 최대 해상도를 얻는 것이지, 가장 높은 TSR 히스토리 수렴 속도를 얻기 위해 GPU를 덜 사용하는 것이 아닙니다. 콘솔과 달리 다른 플랫폼에서는 GPU에서 실행되는 게임 외에 더 많은 프로그램이 존재하며, 이러한 프로그램은 자체 프레임 레이트로 실행됩니다. 기존 API로는, 원하는 프레임 레이트로 프레임을 완성하기 위해 다른 프로그램에 얼마나 많은 GPU 헤드룸을 남겨줘야 하는지 파악하는 것이 현재로서는 불가능합니다.
- D3D의 교체 체인에 누락된 API가 있어 VSync가 활성화된 화면 상단에 약간의 공간이 생기는데, 이는 콘솔에서 일반적으로 쓰이는 방법입니다( rhi.PresentThreshold.Top 으로 지정됨). 다이내믹 해상도가 몇 마이크로초 늦게 완료될 때 프레임 누락이 발생하지 않는 것이 중요합니다. 이러한 현상은 테스트 결과, 콘솔보다는 타사 프로그램 사용을 위해 GPU가 선점될 수 있는 Windows와 같은 데스크톱 플랫폼에서 더 자주 일어납니다.
- GPU는 절전을 위해 동적으로 클럭을 스케일 조절합니다. 이때 다이내믹 해상도를 낮추려는 경향이 있는데, 보수적으로 GPU 비용을 적게 사용하려고 하기 때문입니다. 여기에서 문제는 GPU 스케일 조절을 쿼리하는 공식 D3D API가 없다는 점입니다. 드라이브 백도어(D3DKMTQueryStatistics 함수에 대한 Microsoft 문서 참고)만 사용하며, GPU Clock 및 DynRes 통계와 함께 Stat TSR 을 사용할 때 포트나이트에서 이러한 문제가 나타나는 것을 확인할 수 있었습니다.
TSR이 보간을 하거나 중간 프레임을 생성하나요?

그렇지 않습니다. TSR은 언리얼 엔진에서 기본으로 제공되는 템포럴 업스케일러/슈퍼 해상도 기술입니다. 템포럴 업스케일링 툴/슈퍼 해상도는 중간 프레임을 생성하는 기술과는 다릅니다. 이러한 두 기술 타입 모두 이점이 있기 때문에, 관련 정보를 명확히 하지 않으면 혼란스러울 수 있습니다.
TSR을 타사 프레임 보간/생성과 함께 사용할 수 있나요?

예. 가능합니다. 이는 렌더러와 같은 방식으로 작동합니다. 이러한 종류의 프레임 보간 기술은 모션 블러, 색수차, 샤프닝, 필름 그레인, 블룸, 렌즈 먼지, 로컬 노출, 포스트 프로세스 머티리얼 등 템포럴 업스케일러 이후 포스트 프로세싱 체인에서 더 많은 기능을 처리해야 합니다. 프레임 보간/생성 플러그인은 ISceneViewExtensions 덕분에 TSR을 대체할 ITemporalUpscaler를 구성하지 않고도 뎁스 및 모션 벡터에 자유롭게 액세스할 수 있습니다. 예를 들어 TV 제조사는 브로드캐스트 채널, 스트리밍 서비스, 실물 미디어 또는 게임 콘솔 어디에서든 비디오 피드에서 프레임 생성을 수행합니다.
프레임 보간/생성이 TSR에 어떤 여향을 미치나요?

프레임 보간/생성은 수많은 렌더링 기술과 마찬가지로 GPU 비용을 추가합니다. GPU 비용이 늘어나면, GPU가 바인딩된 상태에서 TSR 또는 다른 템포럴 업스케일러가 디테일을 누적할 때 프레임 레이트에 영향을 줄 수 있습니다.

예를 들어 프레임을 늘리고 표시 프레임 수를 2배로 만들어 게임의 FPS를 55Hz에서 88Hz(보간된 FPS)로 높이는 프레임 보간 기술이 있다고 가정해 보겠습니다. 게임의 새 프레임 레이트는 보간된 게임 FPS와 동일한 값을 구하여 활성화된 프레임 보간으로 계산할 수 있습니다.

예를 들어 FrameMultiplier=2로 표시하는 프레임의 수를 두 배로 만들어 GameFPS=55Hz에서 InterpolatedFPS=88Hz까지 높이는 프레임 보간 기술이 있다고 가정해 보겠습니다. 새로운 게임 프레임 레이트는 InterpolatedGameFPS=FPSInterpolatedFPS/FrameMultiplier=44Hz를 구하여 활성화된 프레임 보간으로 계산할 수 있습니다. 즉, InterpolatedGameFPS/GameFPS=0.8을 곱하는 만큼 게임의 프레임 레이트가 드롭됩니다. 이는 템포럴 업스케일러의 MP 피드에 *0.8만큼 직접적인 영향을 미치며, 히스토리 수렴 속도를 1/0.8=1.25배만큼 증가시킵니다.

TSR Feed 및 TSR 수렴 속도를 표시하는 Stat TSR 로 이러한 결과를 확인할 수 있습니다. 디테일 누적 속도에서 프레임 보간 활성화로 인한 효과를 확인할 수 있습니다.
템포럴 안티 에일리어싱(Temporal Anti-Aliasing, TAA) 또는 템포럴 안티 에일리어싱 업스케일링(Temporal Anti-Aliasing Upscaling, TAAU)을 개선할 계획이 있나요?

계획이 없습니다. TAA 및 그 변형인 TAAU는 전 세대 콘솔이라는 제한을 두고 개발되었습니다. 개발 이래로 유일하게 추가된 사항은 히스토리에 심각한 색 정밀도 문제를 일으키지 않고 R11G11B10을 사용할 수 있는 TSR의 기능뿐입니다. 이를 통해 기존 플랫폼에서 더 많은 메모리 대역폭 퍼포먼스를 절약할 수 있으며, 이 기능은 명령 r.TemporalAA.R11G11B10History 로 제어할 수 있습니다(기본적으로 활성화되어 있음). 자신의 프로젝트에서 낮은 안티 에일리어싱 엔진 퀄리티의 TSR 비용도 버거운 저사양 GPU 사용자를 위해 D3D11 또는 D3D12에서 TAA를 노출할 수 있습니다. 포트나이트를 이렇게 구성한 이유는 저사양 플레이어를 배려하기 위한 것입니다.
TSR을 다른 타사 템포럴 업스케일러와 비교하는 것이 가능한가요?

TSR이 언리얼 엔진 5의 기본 방식이지만, 타사 템포럴 업스케일러를 프로젝트에 사용할 수 있습니다. 타사의 템포럴 업스케일러 간에 전환할 때 크래시가 발생할 수 있었던 5.3 버전의 ITemporalUpscaler 인터페이스 제한 사항이 해결되었습니다. 뷰포트에서 표시(Show) > 시각화(Visualize) 메뉴를 사용하여 템포럴 업스케일러(Temporal Upscaler) 시각화를 토글할 수 있습니다. 이 시각화 툴은 언리얼 엔진 기본 업스케일러든 타사 제품이든, 모든 템포럴 업스케일러에서 작동합니다. 이 시각화 툴은 동일한 렌더링 및 디스플레이 해상도를 사용하여 기본 제공되는 템포럴 업스케일링 툴과 타사 템포럴 업스케일러를 비교할 수 있는 유용한 방법이 됩니다.
TSR에 샤프닝 패스가 있나요?

아니요. 없습니다. 에픽은 TSR로 제작된 이미지에서 레퍼런스에 일치시키는 데에만 집중합니다. 하지만 템포럴 업스케일링 툴 이후에 실행되는 톤매퍼 패스에는 r.Tonemapper.Shapen 으로 활성화할 수 있는 선택사항 샤프닝 기능이 있습니다. 표시 > 시각화 메뉴에서 찾을 수 있는 템포럴 업스케일러 시각화를 통해 사용 여부를 확인할 수 있습니다.

포트나이트는 본질적으로 경쟁 게임이므로, 모든 플랫폼의 모든 템포럴 업스케일러에서 r.Tonemapper.Sharpen=0.5 로 설정합니다.

TSR 히스토리

TSR은 시간에 따라 디테일을 누적합니다. 이렇게 시간에 따라 렌더링된 디테일이 모이는 통합은 히스토리에서 디스플레이 해상도에 따라 이루어집니다. TSR의 히스토리 및 기능에 대한 자세한 내용은 템포럴 슈퍼 해상도의 'TSR 히스토리' 섹션을 참고하세요.

TSR의 히스토리 샘플 수가 히스토리의 메모리 점유율에 영향을 미치나요?

r.TSR.History.SampleCount 로 높은 샘플 수를 설정해도 TSR의 히스토리는 영향을 받지 않습니다. 픽셀의 디테일은 TSR에서 원시 상태로 유지되지 않으며, 퍼포먼스를 위해 히스토리에서 누적/통합됩니다. 히스토리 샘플 수는 히스토리 내 현재 프레임의 최소 기여도에만 영향을 미칩니다. 이는 '1/히스토리 샘플 수'로 계산합니다. 샘플 수가 적어질수록 히스토리 내 현재 프레임의 최소 기여도는 더 높아지며, 이로 인해 템포럴 불안정성이 커질 수 있습니다. 샘플 수가 높아지면 현재 프레임에서 최소 기여도가 더 작아지며, 이미지의 안정성이 높아집니다. 하지만 고스팅 현상이 발생할 경우 이 현상이 사라지는 데 시간이 걸립니다.

히스토리 샘플 수는 TSR 출력/디스플레이 픽셀별로 다르며, Nyquist-Shannon 히스토리에서는 히스토리 픽셀별로 더 낮은 히스토리 샘플 수를 사용합니다. 이 값이 템포럴 슈퍼 해상도 시각화 모드( show VisualizeTSR ) 사용 시 표시됩니다.
이동에서 히스토리 가중치는 어떻게 조정해야 하나요?

이동 중에 히스토리 가중치를 설정하는 것은 이미지 안정성과 선명도를 서로 절충하여 조정합니다. 예를 들어 포트나이트와 같이 서로 경쟁하는 게임은 r.TSR.Velocity.WeightClampingSampleCount 를 낮춤으로써 선명도를 확보하고 이동 중 이미지 안정성을 희생하여 이득을 볼 수 있습니다. 이 콘솔 변수는 r.TSR.History.ScreenPercentage 를 100으로 설정한 상태에서 조정해야 하는데, 히스토리 해상도가 높아지면 블러 및 이동 중 안정성이 모두 자동으로 감소합니다.
에픽 안티 에일리어싱 엔진 퀄리티로 4K 모니터에서 TSR을 실행하면 8K 텍스처가 렌더링되나요?

예. 그렇습니다. 에픽 안티 에일리어싱 엔진 퀄리티로 4K 모니터에서 TSR을 실행하면 8K 텍스처를 효과적으로 사용할 수 있습니다. 모션에 선명한 비주얼이 필요하지 않은 경우 높은 안티 에일리어싱 엔진 퀄리티를 대신 사용하는 것을 고려해 볼 수 있습니다. 한 가지 고려할 점은 강력한 최신 GPU에서 실행하지만 아직 1080p 모니터를 사용 중인 경우, 히스토리 재투영으로 인한 디테일 손실이 훨씬 더 눈에 띈다는 것입니다. 이 때문에 TSR 안티 에일리어싱 엔진 퀄리티를 낮음, 중간, 높음, 에픽 퀄리티 레벨로 선택할 수 있도록 하는 것이 프로젝트에 도움이 되며, 플레이어가 자신의 하드웨어 구성에 맞게 경험을 조정하게 데 있어 중요한 선택 사항이 됩니다.
제 프로젝트가 스크린 퍼센티지가 200이 넘는 TSR 히스토리를 사용해야 하나요?

꼭 그런 것은 아닙니다. 디스플레이 픽셀에서 히스토리 픽셀 간 보간을 숨기려면 축당 2배의 픽셀만 있으면 충분합니다. 또한 200이 넘는 스크린 퍼센티지를 사용하면 렌더링 해상도와 히스토리 해상도 간 업스케일링 요소가 테스트 수치를 훨씬 더 초과하게 됩니다. TSR 히스토리는 이미 100~200 사이에서 스크린 퍼센티지를 임의로 스케일 조절합니다. 또한 히스토리 스크린 퍼센티지가 200인 경우만을 위한 다운샘플링 패스의 셰이더 순열이 있다는 점도 강조하고 싶습니다. 이 경우 Nyquist-Shannon의 필요 조건이 성립되며, 순열에 다운샘플링을 편리하게 단순화해 주는 몇 가지 수학 계산이 있기 때문입니다. 필요한 경우 r.TSR.History.ScreenPercentage 로 TSR 히스토리 스크린 퍼센티지를 조정할 수 있습니다.
TSR 히스토리 스크린 퍼센티지를 100%보다 높게 설정하려면 프라이머리 스크린 퍼센티지에 일치시켜야 하나요?

예. TSR 히스토리 스크린 퍼센티지( r.TSR.History.ScreenPerecentage )를 100%보다 높게 설정하려는 경우 프라이머리 스크린 퍼센티지( r.ScreenPercentage )에 일치해야 합니다. 그렇지 않으면 슈퍼 샘플링된 렌더링에 히스토리 거부 블러가 발생할 수 있습니다. 프로젝트의 프레임 예산이 더 커지는 프라이머리 스크린 퍼센티지를 감당할 수 있는 경우, 그에 상응하는 TSR 히스토리 스크린 퍼센티지도 감당할 수 있습니다.
TSR에서 8K를 렌더링할 수 있나요?

TSR은 가능한 한 빠르게 히스토리를 업데이트하도록 개발 및 설계되었습니다. 4K에서 렌더링하는 콘솔의 경우, 이미지 퀄리티를 위해 시차 및 셰이딩 휴리스틱 기법을 사용할 때 렌더링 해상도에서 예산에 여유가 있습니다. PC에서 이는 고사양 GPU 사용 시 4K에서, 또는 적절히 빠른 GPU 사용 시 낮은 디스플레이 해상도에서 Nyquist-Shannon 히스토리 예산을 의미합니다. 8K를 적극적으로 테스트하고 있지는 않지만, 높은 안티 에일리어싱 퀄리티에서나, 16K 히스토리를 방지하기 위해 낮은 TSR 히스토리 스크린 퍼센티지 설정( r.TSR.History.ScreenPerecentage ) 시 문제가 발생하지는 않습니다.

엔진은 r.PostProcessing.QuarterResolutionDownsample 2 사용 시 포스트 프로세싱 체인 일부를 해상도의 1/8로 실행할 수 있도록 8K를 실험 수준으로 지원합니다. 이를 r.Bloom.ScreenPercentage 12.5 와 함께 사용하면 FFT도 이 해상도에서 실행할 수 있습니다. 이러한 세팅을 통해 r.TSR.History.ScreenPercentage 가 100일 경우(또는 에픽 안티 에일리어싱 엔진 퀄리티를 사용하는 경우), TSR은 1/8 크기의 히스토리 업데이트에서 씬 컬러를 생성할 수 있습니다.
Nyquist-Shannon 히스토리에서 비디오 메모리가 다 소진되어 크래시가 발생하는 경우 어떤 위험이 있나요?

사용 가능한 비디오 메모리가 있는 경우에는 문제가 발생하지 않습니다. 하지만 사용 가능한 비디오 메모리가 없으면 드라이브가 CPU 메모리를 할당하기 시작하므로 퍼포먼스가 저하될 수 있습니다. TSR은 하드웨어가 픽셀 좌표(보통 16384픽셀)에 인코딩 가능한 것보다 더 큰 히스토리를 할당하지 않도록 하기 위해 GMaxTextureDimensions를 확인합니다. 또한 TSR은 16비트 VALU 셰이더 순열에서도 23비트 가수 정밀도를 확보하기 위해 32비트 플로트로 모든 텍스처 UV 좌표를 계산합니다.
TSR의 Nyquist-Shannon 히스토리가 포스트 프로세싱 체인에서 퍼포먼스에 영향을 미치나요?

디스플레이 해상도에 대한 다운샘플링은 TSR 내에서 일어나기 때문에 Nyquist-Shannon 히스토리 이후 포스트 프로세싱 체인에는 영향을 미치지 않습니다. 따라서 이후 패스에서는 에픽과 높음 안티 에일리어싱 엔진 퀄리티 세팅 간에 해상도 차이를 확인할 수 없습니다.
Nyquist-Shannon 히스토리를 사용하는 경우 비용이 높아질 수 있습니다. 플레이어를 위해 다른 옵션을 제공할 수 있나요?

퀄리티를 스케일 조절하는 데 언리얼 엔진의 엔진 퀄리티 그룹(낮음, 중간, 높음, 에픽, 시네마틱)이 사용되며, 플레이어에게 제공할 수 있는 최고의 퀄리티는 에픽 엔진 퀄리티입니다. 모든 사용자가 4K 모니터를 가지고 있는 것은 아니며, Steam 하드웨어 및 소프트웨어 설문조사를 보면 사용자들이 가장 흔히 쓰는 디스플레이 해상도가 무엇인지 알 수 있습니다. 이를 염두에 두고 Nyquist-Shannon 히스토리의 퀄리티와 퍼포먼스 간에 더 다양하게 절충할 수 있는 다른 옵션(예: 사용자가 TSR에서 제공되는 낮은 안티 에일리어싱 엔진 퀄리티도 사용할 수 있게 함)도 고려해 볼 수 있습니다. 예를 들어 사용자에게 1080p 모니터가 있는 경우 1080p 모니터에서 히스토리 거부 블러 때문에 스크린 퍼센티지는 540p가 될 수 있습니다.
TSR의 히스토리 스크린 퍼센티지를 위한 별도의 TSR 세팅을 노출하는 것을 고려하세요.

원하는 경우 자체적인 안티 에일리어싱 엔진 퀄리티 그룹을 추가하여 별도의 세팅으로 노출할 수 있습니다. 다른 안티 에일리어싱 옵션과 TSR 세팅을 구별하는 한 가지 방법은 괄호를 추가하여 사용 중인 방식을 나타내는 것입니다. 또한 자신만의 프로젝트 인터페이스를 통해 이러한 구별 방식을 더 두드러지게 할 수 있습니다. 예를 들어 포트나이트에서는 여러 안티 에일리어싱 방식이 지원됩니다. TSR 세팅에서는 낮음, 중간, 높음 및 에픽 퀄리티 세팅에 따라 선택 항목이 달라집니다. 또한 TSR의 히스토리 스크린 퍼센티지( r.TSR.History.ScreenPercentage )와 같이 사용자 인터페이스에 노출되는 몇 가지 추가 파라미터도 있습니다.

TSR 히스토리 스크린 퍼센티지를 추가할 때 명명 방식도 고려하세요. 'TSR 슈퍼 샘플링'과 같은 이름은 효과적이기는 하지만 스크린 퍼센티지나 슈퍼 샘플링 기능이 있는 다른 타사 템포럴 업스케일러와 혼동을 일으킬 수 있습니다.

셰이딩 거부

TSR의 셰이딩 거부 휴리스틱 기법은 현재 프레임이 이전에 렌더링된 프레임과 얼마나 많이 일치하는지와, 재사용 또는 거부 여부를 결정하는 프로세스입니다. TSR의 셰이딩 거부 및 기능에 대한 자세한 내용은 템포럴 슈퍼 해상도의 '셰이딩 거부' 섹션을 참고하세요.

BlendFinal 및 ClampBlend가 1보다 작을 때 TSR 고스팅 현상이 발생합니다.

TSR 개발 과정에서 이 문제를 해결하려고 최대한 노력했지만, 이는 TSR 셰이딩 거부의 알려진 문제 중 하나입니다.
ClampBlend를 사용한 히스토리 거부의 이점은 무엇인가요?

언리얼 엔진 4의 템포럴 안티 에일리어싱은 ClampBlend를 사용한 거부 기법에 크게 의존합니다. 이는 일부 안티 에일리어싱된 에지를 보존하면서 히스토리 컬러가 입력 해상도에서 너무 크게 벗어나지 않도록 하는 데 유용합니다. 하지만 노이즈가 많을 때는 고스팅 현상이 발생할 수 있다는 단점도 있으므로, 고스팅을 최소화하도록 히스토리 거부에 단독으로 사용해서는 안 됩니다. 또한 텍스처 디테일에 블러가 발생하므로 필요시에만 사용해야 합니다.
BlendFinal을 사용한 히스토리 거부의 이점은 무엇인가요?

BlendFinal은 히스토리와 비교하여 현재 프레임의 가중치를 동적으로 제어하도록 허용합니다. 블렌드 최종 값이 높아질수록, 히스토리가 더 이상 사용되지 않는 지점까지 현재 프레임이 출력을 더 많이 차지하게 됩니다. BlendFinal 값이 1인 경우 히스토리 재투영을 비활성화하여 공간 안티 에일리어싱 툴의 비용을 상쇄합니다. 이 방식으로 BlendFinal을 사용하면 노이즈가 지나치게 심한 화면 영역에서 히스토리를 거부하는 데 유용하며, 이로 인해 범위제한 시 템포럴 안티 에일리어싱에서 볼 수 있는 것과 같은 고스팅 아티팩트가 발생합니다. 또한 렌더링 해상도 노이즈에서와 같은 단점도 나타납니다.

TSR과 반투명

반투명은 TSR이 처리해야 할 특수한 문제로, 한 레이어 위로 임의의 레이어가 몇 개든 블렌딩될 수 있기 때문입니다. 특히 속도를 드로하지 않기 때문에 더욱 그렇습니다. TSR이 반투명 머티리얼에서 작동하는 방식에 대한 자세한 내용은 템포럴 슈퍼 해상도의 'TSR과 반투명' 섹션을 참고하세요.

TSR이 반응형 AA 세팅을 사용하려면 반투명 머티리얼이 필요한가요?

TSR은 반응형 AA 세팅을 사용하는 데 반투명 머티리얼이 필요하지 않습니다. 반응형 AA 세팅은 템포럴 안티 에일리어싱(TAA)에 유용합니다. 이 세팅은 TAA가 반투명 머티리얼을 사용하는 VFX에서 많은 디테일을 손실하지 않도록 합니다. TSR은 반투명 머티리얼에서 반투명 패스(Translucency Pass) 를 기본적으로 After DOF 로 설정하여 이 문제를 해결합니다.
퍼포먼스 절약을 위해 씬 컬러에 직접 드로하려면 After DOF 반투명을 비활성화해야 하나요?

r.SeparateTranslucency 0 을 사용하면 씬 컬러에 직접 드로해 컴포짓 패스 비용을 제거함으로써 퍼포먼스를 절약할 수 있습니다. 하지만 이 작업은 권장하지 않습니다. 해당 기능을 비활성화해도 TSR의 GPU 비용은 줄어들지 않습니다. 사실 TSR은 프로세스에서 별도의 컴포짓 패스가 필요하지 않으며, 절약할 수 있는 유일한 퍼포먼스는 플로트 R16G16B16A16 픽셀 포맷 대신 플로트 R11G11B10( r.SceneColorFormat 으로 환경설정된 경우)으로 반투명을 드로하는 경우뿐입니다. 하지만 이로 인해 연기 구름과 같이 매우 낮은 주파수 투명 이펙트로 블렌딩할 때 양자화 문제가 발생하는 경향이 있습니다.

알려진 문제로 낮은 이펙트 퀄리티에서 BaseScalabililty.ini가 r.SeparateTranslucency 를 0으로 설정하여 씬의 반투명에서 TSR 고스트 현상이 발생하게 됩니다. 이 문제를 우회하려면 r.TSR.ForceSeparateTranslucency 를 사용하여 TSR을 사용할 때마다 별도의 반투명 패스를 강제 활성화하면 됩니다.
뎁스 오브 필드 후 발생하는 반투명으로 인해 메모리 부담이 늘어나나요?

엔진이 중간 리소스 메모리를 하나의 프레임에서 여러 번 재사용하는 방식 덕분에, 뎁스 오브 필드 후 발생하는 반투명이 메모리에 부담을 더하지는 않습니다. 이 작업은 렌더 종속성 그래프 및 일시적 메모리 할당자가 있는 RHI를 통해 이루어집니다. r.RDG.TransientAllocator 1 로 설정할 수 있으며, 기본적으로 활성화되어 있습니다.
After DOF 반투명이 초점 거리 뒤에서 Before DOF로 드로되는 경우 고스팅 현상이 발생할 위험이 있나요?

발생할 확률이 낮습니다. 반투명 머티리얼에 적용된 뎁스 오브 필드의 블러가 TSR의 셰이딩 거부에서 정밀도를 낮추는 노이즈를 감소시키기 때문입니다. 대신 나나이트 디테일의 결과로 노이즈가 발생할 수 있습니다.

포스트 프로세스 머티리얼의 TSR

포스트 프로세스 머티리얼은 머티리얼 렌더링 시 TSR에 어느 정도의 유연성을 제공하지만, TSR은 포스트 프로세싱 렌더링 체인 중에 이루어지기 때문에 자체적인 한계가 있습니다. 머티리얼은 씬 컬러의 다양한 위치에, 뎁스 오브 필드 반투명 이후 삽입됩니다. TSR이 포스트 프로세스 머티리얼을 처리하는 방법에 대한 자세한 내용은 템포럴 슈퍼 해상도의 '포스트 프로세스 머티리얼의 TSR' 섹션을 참고하세요.

TSR에서 셀 셰이딩 외곽선을 처리하는 가장 좋은 방법은 무엇인가요?

외곽선이 잘 구현되지 않는 것은 주로 이러한 외곽선에 모션 벡터가 없기 때문입니다. 이 경우 지오메트리가 오브젝트의 모션 벡터 주변의 선을 끌어올수 있도록 윤곽을 만드는 지오메트리에서 인라인 처리하는 것을 고려해 보세요. 외곽선이 끊어져 보이지 않게 하려면 선이 최소 픽셀만큼은 두꺼워야 합니다.

달리는 캐릭터와 같이 다이내믹 오브젝트에서 외곽선이 카메라 뷰에 종속된 경우, 움직임이 캐릭터 표면에서 일어나며 해당 움직임이 모션 벡터에 피딩되지 않는 경향이 있습니다. 포스트 프로세스 머티리얼 세팅인 블렌더블 위치(Blendable Location) 를 Translucency After DOF 와 함께 사용하여, 모션 벡터가 제공되지 않을 때 고스트 현상을 방지하기 위해 반투명 머티리얼용으로 만들어진 특수 로직을 활용해 보세요.
TSR 이후 안티 에일리어싱 뎁스 버퍼에 액세스하려면 어떻게 해야 하나요?

이렇게 하기는 어렵습니다. 기본적으로 백 버퍼는 안티 에일리어싱될 수 없습니다. 백 버퍼가 안티 에일리어싱될 수 없는 이유를 생각해 보는 한 가지 방법은, 30미터 떨어진 배경에 있는 10미터 거리의 가로등을 상상하는 것입니다. 둘 사이의 뎁스를 안티 에일리어싱하는 것은 결국 뎁스가 10미터와 30미터 사이에서 도출된다는 뜻입니다. 가로등과 건물은 연결되어 있지 않습니다. 이러한 이유로 뎁스 템포럴 누적은 구현하지 않았으며, 뎁스 버퍼의 불안정성과 에일리어싱으로 발생하는 지터 때문에 앞으로도 구현할 계획이 없습니다. 이미지에서 다시 에일리어싱과 불안정성이 발생하지 않고는, TSR 후 이러한 결과를 제대로 된 형태로 사용하는 것은 불가능합니다. 따라서 모든 뎁스 기반 이펙트를 TSR 또는 TAA 전에 처리할 것을 추천합니다.

깜빡임 템포럴 분석

TSR의 깜빡임 템포럴 분석에서는 무늬 패턴과 같은 아티팩트를 찾기 위해 이미지를 분석하고, 먼 거리에서도 지오메트릭 디테일이 일관되게 잘 보이도록 유지하려 합니다. 또한 이미지를 가능한 한 안정화하려고 합니다. TSR의 깜빡임 템포럴 분석이 작동하는 방식에 대한 자세한 내용은 템포럴 슈퍼 해상도의 '깜빡임 템포럴 분석' 섹션을 참고하세요.

TSR로 깜빡임이 항상 완화되나요?

현재 TSR로 완화할 수 없다고 알려진 깜빡임의 두 가지 원인은 다음과 같습니다.
- 루멘 글로벌 일루미네이션이 안정성을 잃도록 하는 높은 강도의 오브젝트가 씬에 있는 경우
- 지오메트리 에지가 결합되지 않는 경우 나나이트 단순화에서 원거리 오브젝트가 깜빡임을 유발할 수 있음
'픽셀 애니메이션 보유(Has Pixel Animation)' 머티리얼 세팅이 오브젝트 드로 속도를 강제하나요?

픽셀 애니메이션 보유(Has Pixel Animation) 머티리얼 세팅은 이 머티리얼에서 애니메이션이 모션 벡터로 완전히 그려진다고 가정하는 렌더의 휴리스틱 기법을 강제로 비활성화합니다. GBuffer에 사용 가능한 비트가 부족하고 이 기능을 포워드 렌더링과 함께 사용할 수 있도록 하기 위해, 이 세팅은 속도 버퍼에 인코딩되어 있으며 TSR이 재투영 시 이 버퍼를 먼저 읽습니다. 따라서 이 머티리얼 세팅을 활성화한 불투명 지오메트리가 스태틱이더라도, 이 세팅을 인코딩하기 위해서라도 스태틱 속도를 드로해야 합니다.
'픽셀 애니메이션 보유' 세팅이 머티리얼 인스턴스에 머티리얼 셰이더 순열을 추가하나요?

픽셀 애니메이션 보유 머티리얼 세팅은 해당 세팅을 사용하는 머티리얼 인스턴스에 셰이더 순열을 추가하지 않습니다. 더 많은 셰이더 순열을 컴파일하지 않도록, 이 세팅을 사용하는 할당된 머티리얼이 있는 프리미티브에서 세팅이 자동으로 설정됩니다. 하지만 머티리얼 슬롯 중 하나에서 플래그가 활성화된 머티리얼이 하나 이상 있는 프리미티브는 이 프리미티브의 모든 머티리얼에서 TSR의 깜빡임 템포럴 분석이 비활성화됩니다. 복잡한 지오메트리를 가진 프리미티브의 경우 다수의 머티리얼 슬롯이 있지만 메시의 일부분만 머티리얼 애니메이션을 사용하게 되므로, 사용하지 않는 것이 좋습니다.

히스토리 리저렉션

TSR의 히스토리 리저렉션은 직전 프레임을 사용할지, 또는 현재 프레임의 디테일과 더 일치하는 히스토리의 이전 '리저렉션' 프레임을 사용할지를 결정하는 프로세스입니다. 이 프로세스에서는 노이즈 및 고스팅 아티팩트를 제한하거나 방지하기 위해 이미지를 안정화하도록 시도합니다. 히스토리에서 프레임이 리저렉션되는 방식에 대한 자세한 내용은 템포럴 슈퍼 해상도의 '히스토리 리저렉션' 섹션을 참고하세요.

일부 프레임만 영구적으로 유지되는 이유는 무엇인가요?

비디오 메모리를 절약하기 위해 일부 프레임만을 영구적으로 유지합니다. 이는 특히 에픽 및 시네마틱 안티 에일리어싱 엔진 퀄리티 세팅에서 TSR 히스토리 스크린 퍼센티지( r.TSR.History.ScreenPercentage )가 200인 Nyquist-Shannon 히스토리에서 중요합니다.
TSR의 히스토리 리저렉션으로 인해 메모리 점유율이 늘어나나요?

히스토리 리저렉션을 사용하지 않는 경우 TSR에는 현재 프레임과 이전 프레임이라는 두 개의 히스토리가 필요하며, 프레임마다 둘은 서로 역할을 바꿉니다. 리저렉션이 활성화된 경우( r.TSR.Resurrection 1 ) 히스토리의 수는 2 + TSR 리저렉션 퍼시스턴트 프레임 수( r.TSR.Resurrection.PersistentFrameCount )가 됩니다. 퍼시스턴트 프레임 수가 2프레임이므로, 히스토리 리저렉션은 기본적으로 TSR의 메모리 점유율을 두 배로 늘립니다. 히스토리의 메모리 점유율은 템포럴 업스케일러 시각화 모드에서 시각화할 수 있습니다. 뷰포트의 표시 > 시각화 메뉴에서 템포럴 업스케일러 를 선택하여 이 시각화 모드를 토글할 수 있습니다.
가장 오래된 퍼시스턴트 프레임만 리저렉션하는 이유는 무엇인가요?

가장 오래된 퍼시스턴트 프레임만 리저렉션하는 것은 리저렉션의 기본 GPU 비용이 그 원인으로, 이전 및 현재 프레임과 비교하기 위해 리저렉션 프레임의 렌더링 해상도 버전을 재투영할 필요가 있기 때문입니다. 이 작업은 결과적으로 리저렉션이 필요하지 않더라도 프레임마다 해야 합니다.
TSR의 리저렉션 퍼시스턴트 프레임 간격 수에 제약이 있는 이유는 무엇인가요?

디스플레이 해상도 이상에서 일어나는 업데이트 히스토리 패스에서 추가적인 텍스처 페치 인스트럭션 없이도 최대한 히스토리 리저렉션을 최적화하기 위해, TSR은 Texture2DArrays를 사용합니다. 이에 따라 하나의 셰이더가 읽기 및 쓰기를 모두 수행해야 하는 경우, 셰이더가 동시에 읽을 수 있는 텍스처 슬라이스의 범위에 어느 정도 제약이 적용됩니다.
GPU가 퍼시스턴트 프레임을 유지하기 위해 히스토리를 추가로 복사하나요?

아니요. 그렇지 않습니다.
리저렉션이 모든 위치에서 예상대로 이루어지지 않는 이유는 무엇인가요?

히스토리 리저렉션은 다음 두 가지 조건을 만족할 때 이뤄집니다.
- 리저렉션 프레임이 이전 프레임보다 현재 프레임에 더 일치하는 경우
- 이전 프레임이 고려 대상인 현재 프레임에 충분히 일치하지 않는 경우
이러한 조건을 만족해야 리저렉션 프레임이 현재 프레임과 비교됩니다. 충분히 일치하는 경우 리저렉션 프레임이 사용됩니다. 다량의 간접광이 존재하는 경우에는 현재 프레임에 루멘의 샘플이 충분하지 않아, 현재 프레임이 원래 실제로 표현되어야 하는 화면이나 리저렉션 프레임의 화면과 다르게 보일 수 있습니다. 이 경우 프레임 리저렉션이 일어나지 않을 수 있습니다.
TSR의 최근 변경사항을 언리얼 엔진 이전 버전에 병합하는 것은 얼마나 복잡한가요?

언리얼 엔진 5.4에서 시작된 TSR 히스토리는 Texture2D 대신 Texture2DArray로 만들어졌습니다. 이후의 포스트 프로세싱 체인에서 Texture2D를 출력하는 추가적인 GPU 복사를 방지하기 위해, 포스트 프로세싱 패스에 몇 가지 변경사항이 적용되었습니다. 이제 PostProcessing.cpp 파일에서 새로운 FScreenPassTextureSlice 로 RDG 텍스처에서 SRV를 대신 사용하게 됩니다. 이러한 변경사항 대부분은 이미 언리얼 엔진 5.3에 포함되어 있으므로, 일반적인 TSR 파일에 이미 적용된 변경사항을 5.4 이상 버전에서 원하는 대로 활용할 수 있습니다.

언리얼 엔진 5.3 이전 버전의 경우, 히스토리 리저렉션을 가능하게 하는 포스트 프로세싱 체인의 5.3 변경사항을 다음 링크에서 확인할 수 있습니다.
언리얼 엔진 5.4에는 포스트 프로세싱 체인에 추가적인 변경이 필요했으며, 해당 내용은 다음 링크에서 확인할 수 있습니다.
- https://github.com/EpicGames/UnrealEngine/commit/59a7373ea7bde36706a2f8601ff6d72979624672
히스토리 리저렉션을 콘솔 플랫폼용으로 개발된 프로젝트에 포함하여 출시할 수 있나요?

언리얼 엔진 5.4를 기준으로 리저렉션의 기본 비용이 언리얼 엔진 5.1과 동일한 GPU 런타임 비용을 갖도록 TSR에서 최적화가 충분히 구현되어 있습니다. 이러한 최적화는 60Hz에서 4K 콘솔로 포트나이트를 실행하는 데 TSR이 적용된 시점에 이뤄졌습니다. 60% 다이내믹 솔루션 스케일로 고정하여 진행한 퍼포먼스 리플레이 테스트에서 전반적인 평균 비용이 0.24밀리초로 측정된 반면, 포트나이트는 다이내믹 해상도에서 평균 51%의 스크린 퍼센티지로 실행되었습니다.
이동하는 오브젝트를 리저렉션할 수 있나요?

리저렉션은 처음부터 디테일을 누적해야 하는 빈도를 최대한 줄이도록 시도합니다. 프레임 안의 무언가에 가려지거나 프레임 바깥으로 이동하여 오브젝트가 더 이상 화면에 없는 경우, TSR은 오브젝트의 이동 방식을 놓쳐 디테일을 다시 누적해야 합니다. TSR에 시각 요소의 흐름이 없으면, TSR은 화면이 현재 프레임과 일치하는지 확인하기 위해 리저렉션 프레임의 뷰 및 투영 매트릭스를 사용하는 현재 프레임의 뎁스 버퍼로 재투영하게 됩니다.

오브젝트가 이동하지 않았거나 아주 조금만 이동하면, TSR은 컬러가 일치하지 않는 경우 외에는 디테일을 리저렉션합니다. 예를 들어 포트나이트에서 TSR은 느리게 움직이는 잔디가 완벽하게 일치하지 않더라도 리저렉션할 수 있습니다. 새로 표시되는 잔디의 새로운 디테일은 누적되므로 캡처하기에 충분합니다. 더 빠르게 이동하는 디테일의 경우, 이러한 디테일 드롭이 쉽게 눈에 띄는 씬의 스태틱 오브젝트와 비교했을 때 화면에서 이동할 때 리저렉션의 부재를 눈치채기 어렵습니다.