프레임의 여정 — 프레임 타이밍, 동기화, 지연 시간

한 줄 결론

입력 지연과 히치 내성(hitch resiliency)은 정확히 맞바꾸는 관계입니다. 파이프라인을 길게 잡으면 히치를 흡수하지만 지연이 늘고, 짧게 잡으면 지연은 줄지만 히치가 그대로 화면에 나옵니다. 그리고 파이프라인이 히치를 전부 흡수해도 저더(judder)는 남습니다 — 이것이 대부분의 게임이 미묘하게 끊겨 보이는 진짜 이유입니다.

기초 다지기

저더 · 지터 · 테어링 — 먼저 용어를 분리합니다

세 단어가 한국어 자료에서 자주 섞여 쓰이지만 가리키는 현상이 다릅니다. 이 문서는 아래 구분을 끝까지 유지합니다.

• 저더(judder) — 프레임이 표시되는 간격과 그 프레임이 담고 있는 시간 진행량이 어긋나 움직임이 덜컹거리는 현상입니다. 마이크로소프트의 디스플레이 하드웨어 가이드라인은 24fps 영상을 60Hz에 3:2 풀다운으로 얹으면 “33.3ms, 50ms, 33.3ms, 50ms … 패턴이 생겨 필름 저더를 유발한다”고 설명합니다. 프레임이 하나도 누락되지 않아도 발생한다는 점이 핵심입니다.
• 지터(jitter) — 간격 자체가 불규칙하게 흔들리는 것을 가리키는 더 일반적인 말입니다. 저더는 “규칙적으로 잘못된 간격”, 지터는 “불규칙한 간격”에 가깝습니다.
• 테어링(tearing) — 스캔아웃 도중에 버퍼가 교체되어 한 화면에 두 프레임이 섞여 보이는 현상입니다. 타이밍 문제가 아니라 교체 시점 문제입니다.

세션이 끝에서 다루는 문제는 정확히 저더입니다. 프레임 드랍이 0이어도 남는 현상이기 때문입니다.

입력에서 광자까지

한 프레임 안에서 해야 하는 일

기초 다지기

click-to-photon과 PC Latency는 다른 값입니다

지연을 이야기할 때 어느 구간을 재는 것인지 먼저 합의해야 합니다. 벤더 문서는 이 구분을 명시적으로 정의해 두었습니다. NVIDIA의 기술 문서는 “주변기기 지연 + PCL + 디스플레이 지연을 합치면 엔드투엔드 시스템 지연의 전체 그림이 된다”고 적고, PC Latency(PCL)를 “입력에서 프레임 시작까지(I2FS), 프레임 시작에서 Present까지(FS2P), Present에서 표시까지(P2D)의 평균 합”으로 정의합니다.

즉 흔히 말하는 click-to-photon은 마우스 스위치부터 픽셀이 실제로 색을 바꿀 때까지를 재는 물리 측정이고, PC Latency는 그중 PC가 책임지는 구간입니다. 게임 개발자가 개선할 수 있는 것은 후자이고, 유저가 체감하고 리뷰어가 측정하는 것은 전자입니다. 같은 게임에서 두 숫자가 다르게 나오는 이유가 여기 있습니다.

프론트 버퍼와 백 버퍼

• 게임은 그림을 그릴 서피스(버퍼)를 가집니다. 렌더 타겟 텍스처, 혹은 아티스트가 그리는 캔버스라고 생각하면 됩니다.
• GPU는 이 버퍼를 스캔해 디스플레이로 보냅니다. 지금 스캔되고 있는 버퍼가 프론트 버퍼입니다.
• 프론트 버퍼에 직접 그리지 않습니다. 그리는 도중의 그림이 화면에 나타나면 곤란하기 때문입니다. 그래서 백 버퍼에 그린 뒤 교체합니다.

기초 다지기

Flip Model — 버퍼 2장이 하한선인 이유

PC에서 이 버퍼 배열을 실제로 정의하는 것은 DXGI 스왑 체인입니다. 마이크로소프트 문서는 플립 모델 스왑 체인의 요구사항 첫 항목으로 “버퍼 개수는 최소 2 이상이어야 한다”를 들고, 성능 저하를 피하려면 BufferCount를 2에서 16 사이로 두라고 안내합니다. 같은 문서의 예제 코드는 BufferCount = 2 옆에 “지연을 최소화하려면 더블 버퍼링을 사용한다”는 주석을 달아둡니다.

즉 “콘솔은 2장, PC는 3장”이라는 세션의 설명은 API가 강제하는 값이 아니라 플랫폼별 기본 선택입니다. 그리고 그 선택이 곧 파이프라인 깊이의 하한과 상한을 정합니다.

VSync — 교체 시점을 수직 동기 신호에 맞추기

수직 동기(VSync)를 기다린 뒤 버퍼를 교체하면 전환이 매끄럽습니다. VSync 신호는 한 프레임의 스캔이 끝나는 시점에 발생합니다. 기다리지 않고 아무 때나 교체할 수도 있지만, 그러면 스캔 도중에 교체되어 화면이 찢어집니다(테어링, tearing).

r.VSync
  0 : VSync is disabled. (default)
  1 : VSync is enabled.

rhi.SyncInterval
  0 : Unlocked (present immediately)
  1 : Present every vblank interval
  2 : Present every 2 vblank intervals
  3 : etc...

위 설명문은 에픽 공식 콘솔 변수 레퍼런스의 표기를 그대로 옮긴 것입니다. rhi.SyncInterval은 “지원되는 RHI에서 VSync의 주기를 결정하며, 60Hz 디스플레이에서는 16.66ms의 배수”로 정의됩니다.

Unreal Insights에서 flip을 눈으로 확인하기

관련 콘솔 변수를 켜면 Insights에 flip 마커가 표시되어, 어느 프레임 번호가 프론트 버퍼로 교체됐고 어느 프레임이 miss였는지를 확인할 수 있습니다. 게임 프레임 번호와 같은 번호를 쓰기 때문에 파이프라인 전체를 하나의 번호로 추적할 수 있고, 전용 트랙도 추가 예정이라고 밝혔습니다.^[1]

어떻게 건너뛰는가 — 과거와 현재

과거에는 Exclusive Fullscreen(전체 화면 독점)밖에 방법이 없었습니다. 모드 전환 때 화면이 검게 깜빡이고, Alt+Tab을 하면 다시 전환 과정을 거쳐야 했습니다.

현재는 Windows 10 이상 + DirectX 12 + Flip Model 스왑 체인(기본값) 조합이면 Borderless Fullscreen 모드만으로도 자동으로 컴포지터를 건너뜁니다. 윈도우가 “화면에 이 게임밖에 없으니 합성할 필요가 없다”를 감지하면 활성화됩니다.

MPO — 창모드에서도 OS 합성을 건너뛰는 하드웨어 경로

추가로 MPO(Multiplane Overlay)라는 하드웨어 기능이 있습니다. 게임이 창모드여도 활성화될 수 있고, GPU가 합성을 대신 처리하므로 OS 쪽 단계를 항상 건너뜁니다. 마이크로소프트 문서는 이 경로를 “DWM이 애플리케이션을 위해 전용 하드웨어 스캔아웃 플레인을 예약할 수 있다”고 설명합니다. MPO 자체는 Windows 8.1(WDDM 1.3)에 도입된 정식 기능으로 드라이버 문서에 명시되어 있습니다.

확인 방법 — PresentMon의 Present Mode 컬럼

지금 내 게임이 합성을 거치고 있는지는 추측이 아니라 측정으로 알 수 있습니다. 인텔의 PresentMon이 Present Mode 컬럼으로 그 값을 그대로 보여줍니다. 아래 문구는 인텔 저장소의 문서 표기입니다.

사진 · 자료

PresentMon 오버레이 — Frame Time과 GPU Busy를 분리해서 본다

발표자 권장 — Exclusive Fullscreen을 제공할 거라면 대신 Secondary Upscale을 쓸 것. 더 잘 보이고 성능은 동등하다.

언리얼의 2단계 업스케일

r.ScreenPercentage                        ; 1차(내부) 해상도 비율
r.SecondaryScreenPercentage.GameViewport  ; 2차 해상도 비율 (0 = DPI 스케일로 자동)
r.Upscale.Quality
  0 : Nearest filtering
  1 : Simple Bilinear
  2 : Directional blur with unsharp mask upsample
  3 : 5-tap Catmull-Rom bicubic, approximating Lanczos 2 (default)
  4 : 13-tap Lanczos 3
  5 : 36-tap Gaussian-filtered unsharp mask (very expensive)

값 목록은 에픽 공식 문서 「Screen Percentage with Temporal Upscale」의 표기 그대로입니다. 같은 문서가 r.SecondaryScreenPercentage.GameViewport를 “게임 뷰포트의 2차 스크린 퍼센티지를 덮어쓴다. 0이면 100 / DPI 스케일 팩터로 자동 계산(기본값)”으로 정의합니다.

동기화가 깨지면 — “파이프라인의 브레이크”

게임을 일시정지하거나, 메뉴로 들어가거나, 게임 스레드가 갑자기 빨라지면 게임 스레드가 혼자 앞으로 계속 달려나갑니다. 그래서 파이프라인의 각 부분이 나머지보다 너무 앞서지 않도록 기다릴 수 있어야 합니다. 발표자는 이를 “파이프라인의 브레이크”라고 불렀습니다.

이 대기 관계를 실제로 정의하는 것이 r.OneFrameThreadLag입니다. 공식 레퍼런스의 정의는 “렌더링 스레드가 게임 스레드보다 한 프레임 뒤처지는 것을 허용할지 여부(0이면 비활성, 그 외에는 활성)”이고, 기본값은 1입니다. 저지연 프레임 싱크 문서는 여기에 배경을 덧붙입니다 — “이 CVar가 켜져 있으면(기본값) 게임 스레드가 렌더링 스레드보다 온전한 한 프레임 이상 앞서가지 않도록 보장된다”.

Oversubscription — 대기 중인 코어를 놀리지 않기

질문이 가장 많이 들어오는 항목이라고 소개된 개념입니다. 시스템에 하드웨어 스레드가 여러 개 있는데 워커 스레드가 무언가(예: GPU)를 기다리는 동안 그 코어는 아무것도 하지 않고 낭비됩니다. Oversubscription은 엔진에게 “지금 블록됐으니 스레드를 하나 더 띄워 다른 일을 시켜라”고 알려주는 방식입니다. 결과적으로 워커 스레드가 유휴 상태가 되어도 컴퓨터의 모든 코어를 계속 활용할 수 있습니다.^[4]

여기서 기다리는 대상이 “큐(Queue)”가 아니라 “디큐(Dequeue)”라는 점을 발표에서 강조했습니다 — 커맨드를 넣는 것이 막히는 게 아니라, 앞의 것이 빠져나가기를 기다리는 것입니다.

언리얼이 “입력 지연”이라고 부르는 구간

Hitch Resiliency — 지연의 대가로 받는 것

파이프라인이 가득 차 있으면 작은 히치를 흡수하는 버퍼 역할을 합니다. 비용은 두 가지입니다.

1. 입력 지연.
2. 게임 스레드 CPU 예산. 파이프라인을 다시 채우려면 따라잡을 여력이 있어야 하기 때문입니다.

파이프라인에 프레임 1~8이 동시에 존재
프레임 9가 오래 걸림  →  1프레임 미스, 2프레임 미스, 3프레임 미스
디스플레이는 지금 프레임 4를 그리는 중  →  앞에 큰 공백이 다가온다
  → 프레임을 드랍할까?
아니다. 이후 빠르게 달려서 프레임 6, 7, 8을 처리
  → 유저가 단 한 프레임의 드랍도 눈치채기 전에 파이프라인을 다시 채운다

방법 ① — 프레임레이트를 올린다

히치 내성과 병렬성을 그대로 유지하면서 지연만 줄이는 유일한 방법이기도 합니다.^[6]

반대로 프레임레이트에 상한을 씌우는 쪽도 지연에 영향을 줍니다. 공식 레퍼런스의 t.MaxFPS 정의는 “주어진 값으로 FPS를 제한한다. 0 이하로 두면 제한하지 않는다”입니다.

방법 ② — 게임 스레드 시작을 늦춘다 (스로틀링)

게임 시뮬레이션이 화면 표시보다 너무 일찍 일어나서 지연이 커지는 것이므로, 작업량은 그대로 두고 시작 시점만 뒤로 밀면 지연이 줄어듭니다. 이상적으로는 매 VSync마다, 프레임의 전체 작업이 VSync 직전에 끝나도록 배치하는 것입니다.

r.GTSyncType — 공식 정의와 값

r.GTSyncType
  0 : Sync the game thread with the render thread (default)
  1 : Sync the game thread with the RHI thread
  2 : Sync the game thread with the GPU swap chain flip (only on supported platforms)

rhi.SyncSlackMS
  "Increases input latency by this many milliseconds, to help performance
   (trade-off tunable). Gamethread will be kicked off this many milliseconds
   before the vsync"

두 인용문 모두 에픽 공식 콘솔 변수 레퍼런스의 표기입니다. 저지연 프레임 싱크 문서는 “지원하지 않는 플랫폼에서 r.GTSyncType 2는 모드 1로 폴백된다”고 명시합니다.

PC의 적응형 경로 — 벤더 SDK

PC에서는 하드웨어를 알 수 없으므로 슬랙을 상수로 둘 수 없습니다. 그래서 이전 프레임들을 보고 지연을 자동 조정하는 벤더 SDK를 쓰게 됩니다. 세 벤더 모두 같은 아이디어를 각자의 이름으로 제공합니다.

사진 · 자료

적응형 스로틀링이 “보고” 있는 것 — 프레임 ID가 붙은 마커

방법 ③ — 파이프라인 자체를 짧게 (권장되지 않음)

더 깊이

구현이 어려운 진짜 이유

Q&A에서 나온 답이 이 작업의 난점을 정확히 짚습니다. 언리얼이 OS와 타이밍을 조율하는 통로는 전부 스왑 체인입니다. 그래서 GPU에 프레임 타이밍을 직접 물어볼 수 없고, 반드시 그래픽스 API를 거쳐야 합니다. DirectX는 비교적 최근에야 지원하기 시작했고, VRR이나 VSync 상태에 따라 동작이 달라지며, Vulkan도 부분적으로만 지원합니다.

참고로 모바일 쪽에는 이미 별도의 프레임 페이싱 계층이 문서화되어 있습니다. 공식 문서는 프레임 페이싱을 “애플리케이션이 기기의 네이티브 리프레시 레이트보다 낮은 프레임레이트로 렌더하도록 제한하는 시스템”으로 정의하고, 안드로이드에서는 Swappy(Android Game SDK)를 사용하며 r.setframepace로 목표를 지정할 수 있다고 안내합니다. 데스크톱·콘솔용 새 모드가 노리는 지점도 결국 같은 종류의 계층입니다.

기초 다지기

“붙잡아둘 수 있는 시간의 한계”가 무슨 뜻인가

VRR 디스플레이에는 동작 범위가 있습니다. AMD 문서는 “FreeSync 지원 그래픽 카드는 디스플레이가 보고한 능력에 따라 적절한 최대·최소 리프레시 레이트를 감지해 설정한다”고 설명합니다. 문제는 프레임레이트가 그 최소값 아래로 떨어질 때입니다. 모니터는 프레임을 무한정 붙잡고 있을 수 없습니다.

그래서 벤더들은 같은 대응을 합니다 — 프레임을 복제해 여러 번 표시하는 것입니다. AMD는 이를 LFC(Low Framerate Compensation)로 이름 붙이고 “60–144Hz 디스플레이라면 40FPS로 도는 게임의 프레임을 두 배로 늘려 80Hz로 동기화할 수 있다”는 예시까지 적어두었습니다. NVIDIA의 공식 안내 역시 “드라이버는 최소 리프레시 레이트 아래의 프레임을 배수로 늘린다”고 서술합니다.

즉 VRR 아래쪽 경계에서는 같은 프레임이 두 번 표시됩니다. 정수 배로 고르게 반복하고 리프레시 레이트도 그에 맞추므로 복제 자체가 3:2 풀다운 같은 저더를 만들지는 않습니다. 하지만 VRR은 10장에서 다루는 델타 타임 문제(히치 뒤 진행량이 요동치는 것)는 건드리지 않습니다. VRR이 “프레임 드랍을 막아주는 장치”이지 “부드러움을 보장하는 장치”가 아닌 이유입니다.

델타 타임의 성질

• 델타 타임은 물리 · 시퀀스 · 애니메이션 등 게임 안의 모든 것을 얼마나 진행시킬지의 양입니다.
• 현재 프레임의 델타 타임은 문자 그대로 “직전에 렌더된 프레임에 걸린 시간”입니다 → 항상 한 프레임 뒤처져 있습니다.
• VSync를 놓치면 델타 타임이 증가합니다.

저더는 정확히 무엇이 어긋난 것인가

시뮬레이션한 델타 타임과, 그 프레임이 실제로 화면에 표시되는 간격이 어긋날 때 발생합니다. 이 어긋남은 다음 세 사실이 동시에 성립하기 때문에 생깁니다.

1. 표시 프레임 사이의 간격은 (프레임을 놓치지 않는 한) 일정하다.
2. 그런데 델타 타임 값은 히치 직후에 크게 요동친다.
3. 애니메이션과 카메라는 델타 타임을 그대로 적용한다 → “얼마나 진행시켰는지”와 “실제로 몇 ms가 흘렀는지”가 불일치한다.

히치의 해부 — 세 단계

사진 · 자료

델타 타임의 요동을 실제로 읽는 화면

회전 바퀴 실험 — 저더를 눈에 보이게 만들기

발표자는 이 주제를 다룬 다른 발표들의 화면에서 저더가 잘 보이지 않았다는 문제의식에서, 회전을 이용해 재현 가능한 실험을 만들었습니다.

고정 델타 타임이 답이 아닌 이유

일부 게임에서는 잘 작동하기도 하지만 권장되지 않습니다. 이유가 두 가지 있습니다.

세션이 제시한 임시 방편 — 델타 타임 보정 플러그인

대상은 r.GTSyncType 2를 쓰지 않는 게임, 즉 기본값 r.GTSyncType 0 환경입니다. 세 가지 모드가 소개됐습니다.^[10]

프레임 생성(Frame Generation)은 스왑 체인과 어떻게 상호작용하나

프레임젠은 기본적으로 스왑 체인을 가로챕니다(hijack). 더 이상 게임이 스왑 체인과 직접 상호작용하지 않고, 해당 프레임워크에 프레임을 넘기면 그 이후의 프레젠테이션은 그쪽이 처리합니다.

리워크된 CVar들이 블루프린트 노드로 노출되나

모든 CVar는 이미 블루프린트에서 변경할 수 있습니다. Execute Console Command 노드에 CVar 이름과 값을 넘기면 됩니다. 전용 노드가 있는 것은 아니지만 매우 간단하며, 어떤 CVar든 어떤 값으로든 설정할 수 있습니다.

60Hz / 120Hz / 144Hz, VRR 유무에 따라 권장이 달라지나

달라지지 않습니다. 콘솔은 r.GTSyncType 2, PC는 벤더 저지연 솔루션, 모바일은 r.GTSyncType 1이라는 권장은 어떤 리프레시 레이트를 노리든, VRR이 켜져 있든 아니든 동일하게 유효합니다.

다만 180Hz · 240Hz처럼 매우 높은 리프레시 레이트에서는 지연 자체가 워낙 낮아서, 오히려 히치 내성을 더 챙기는 쪽으로 갈 여유가 생깁니다 → r.GTSyncType 0으로 돌아가도 괜찮습니다.

게임 스레드가 잠든 원인을 구분할 수 있나

가능합니다. 앞의 설명을 다 제쳐두고 말하면 게임 스레드는 언제나 “이전 렌더 스레드”를 기다립니다. 기본값을 바꾸지 않는 한 그것이 항상 게임 스레드가 기다리는 대상입니다.

세션에서 직접 안내한 원문

에픽 공식 문서

플랫폼 · 벤더 1차 자료

각주

1. Insights의 flip 마커를 켜는 콘솔 변수 — 이 문서는 변수 이름을 특정하지 않았습니다. 에픽 공식 콘솔 변수 레퍼런스와 Unreal Insights 레퍼런스의 트레이스 채널 목록에는 flip · present · vsync를 이름에 가진 항목이 없습니다. 프레임 경계를 다루는 공식 채널은 Frame(“Game and Rendering frames.”)이며, 발표에서 언급된 전용 트랙도 정리 시점 기준으로 공식 문서에 없습니다. 정확한 변수 이름은 세션 원문 아티클에서 확인하는 것이 확실합니다. ↩
2. MPO가 주 모니터에서만 활성화된다는 제약 — 마이크로소프트의 WDDM MPO 문서와 DXGI 문서, 그리고 NVIDIA의 공개 문서 어디에서도 “MPO가 주 디스플레이를 요구한다”는 서술을 확인하지 못했습니다. MPO 자체가 정식 기능이라는 점과, DWM이 전용 하드웨어 스캔아웃 플레인을 예약할 수 있다는 점은 공식 문서로 확인됩니다. 주 모니터 조건은 드라이버 구현이나 특정 세대의 동작일 가능성이 있으므로, 실제 환경에서는 PresentMon의 Present Mode 값으로 직접 확인하는 것이 안전합니다. ↩
3. 게임 스레드가 “2프레임 전”을 기다린다는 서술 — 공식 레퍼런스는 r.GTSyncType 0을 “게임 스레드를 렌더 스레드에 동기화(기본값)”로만 정의하고, 두 프레임 전을 함께 확인한다는 서술은 담고 있지 않습니다. 게임 스레드와 렌더 스레드가 함께 앞서나가는 것을 막기 위한 두 번째 체크라는 설명은 발표 내용이며, 공식 문서로는 “게임 스레드가 렌더링 스레드보다 온전한 한 프레임 이상 앞서가지 않도록 보장한다”까지만 확인됩니다. ↩
4. Oversubscription — 이 이름으로 동작을 설명하는 에픽 공식 문서를 확인하지 못했습니다. 대기 중인 워커 스레드를 대신할 스레드를 추가로 띄운다는 개념 자체는 태스크 그래프의 일반적인 기법이지만, CVar 이름이나 API 표기는 확정하지 않았습니다. ↩
5. stat unit의 Input 줄 — 공식 Stat Commands 문서는 stat unit이 표시하는 항목을 Frame · Game · Draw · GPU · RHIT · DynRes로만 명시하며, Input 줄은 문서화되어 있지 않습니다. “입력 샘플링 시점부터 백 버퍼가 프론트로 flip될 때까지”라는 측정 구간의 정의는 발표 내용이며, 이 문서는 그대로 옮기되 공식 문서에 없는 항목임을 밝혀둡니다. ↩
6. “파이프라인 6프레임” 기준의 200 / 100 / 50ms — 파이프라인 깊이 6프레임이라는 숫자와 그로부터 계산한 프레임레이트별 지연은 공식 문서에서 확인되지 않습니다. 공식 문서가 제시하는 숫자는 다른 조건의 것입니다 — rhi.SyncInterval 2인 30Hz 타이틀의 최악 130ms, 그리고 r.GTSyncType 2 + rhi.SyncSlackMS 0에서의 최선 약 66ms. 파이프라인 깊이는 버퍼 개수와 CVar 설정에 따라 달라지므로, 위 표는 “깊이가 고정일 때 프레임 시간이 줄면 총 지연도 줄어든다”는 관계를 보여주는 예시로 읽는 것이 정확합니다. ↩
7. rhi.SyncSlackMS의 기본값 — 발표에서는 10ms로 안내됐습니다. 공식 문서에서 확인되는 것은 “0에서 한 프레임 분량까지 설정할 수 있다”는 범위와, 이 값을 10으로 올렸을 때 최선 지연이 약 66ms에서 약 76ms로 늘어난다는 예시입니다. 기본값 자체는 엔진 버전과 플랫폼 설정에 따라 달라질 수 있으므로 프로젝트에서 직접 확인하는 편이 안전합니다. ↩
8. 새 프레임 페이싱 모드의 버전— 어느 버전에 들어갈지는 발표 시점에 확정되지 않았고, 공식 릴리스 노트에서도 해당 모드를 확인하지 못했습니다. Q&A에서는 특정 마이너 버전에 넣고 싶었으나 확실하지 않으며 다음 메이저의 main 브랜치에 올라갈 가능성이 크고 1년 이내를 희망하지만 약속할 수는 없다는 답변이 있었습니다. ↩
9. 회전 바퀴 실험에 주입한 히치 크기 — 이 문서는 “파이프라인이 완전히 흡수할 수 있는 최대 크기”라는 성질만 적었습니다. 발표에서 언급된 구체적인 밀리초 값은 특정 빌드와 특정 설정에서의 실측치이며, 공식 문서로 검증할 수 있는 수치가 아닙니다. 세션 원문 아티클에는 약 90ms 수준의 값이 제시되어 있습니다. ↩
10. 델타 타임 보정 플러그인의 이름과 모드 명칭 — 세 모드의 명칭(Hitch Absorb / Mitigation / Hitch Pass)은 발표에서 소개된 표기이며 공식 엔진 문서에서 확인되지 않습니다. 세션 원문 아티클에서는 DeltaTimeSmoother라는 이름의 플러그인과 그 배포 위치를 안내하고 있으므로, 실제로 도입할 때는 원문의 링크와 문서를 기준으로 삼는 것이 정확합니다. ↩