Poglavlje 33: Temporal Super Resolution (TSR)

Poglavlje 33: Temporal Super Resolution (TSR)


Uvod

Zamislite sledecu situaciju: pravite igru koja treba da izgleda apsolutno fantasticno na 4K rezoluciji, ali vam graficka kartica jedva izvlaci stabilan framerate na 1080p. Zvuci kao neresiv problem, zar ne? E pa, upravo za ovakve situacije postoji Temporal Super Resolution, ili skraceno TSR -- Unreal Engine 5 ugradjeno resenje za temporalni upscaling koje vam omogucava da renderujete scenu na nizoj rezoluciji, a zatim rekonstruisete sliku na visoj, prikaznoj rezoluciji. Rezultat? Slika koja izgleda gotovo identicno kao da ste renderovali na punoj rezoluciji, ali uz drasticno bolji performans.

U ovom poglavlju detaljno cemo proci kroz sve aspekte TSR-a: kako radi ispod haube, zasto je zamenio TAA kao primarni anti-aliasing metod u UE5, kako se poredi sa konkurentskim resenjima poput DLSS-a i FSR-a, koji artefakti mogu nastati i kako ih izbegazati, i naravno -- sve best practices koje trebate znati da biste izvukli maksimum iz ovog sistema.

Ako ste procitali Poglavlje 15 o anti-aliasing tehnikama i TAA-u, vec imate solidnu osnovu. Ako niste -- ne brinite, objasnicu sve sto vam treba. Ali svakako preporucujem da se vratite na to poglavlje nakon sto zavrsimo ovde, jer ce vam mnoge stvari postati jos jasnije.


33.1 Sta je TSR?

33.1.1 Definicija i osnovna ideja

Temporal Super Resolution (TSR) je Unreal Engine 5 ugradjeni sistem za temporalni upscaling -- tehnologija koja renderuje scenu na nizoj internoj rezoluciji (na primer 1080p), a zatim koristi podatke iz trenutnog i prethodnih frame-ova da rekonstruise sliku na visoj, prikaznoj rezoluciji (na primer 4K).

Kljucna rec ovde je temporalni. Za razliku od obicnog upscaling-a koji jednostavno "razvlaci" sliku (kao kada biste zumirali fotografiju na telefonu i dobili mutnu sliku), TSR koristi informacije akumulirane tokom vise frame-ova da bi rekonstruisao detalje koji u pojedinacnom frame-u na nizoj rezoluciji jednostavno ne postoje.

Razmislite o tome na sledeci nacin: kada kamera ili objekti u sceni miruju, TSR ima priliku da "sakupi" informacije iz vise uzastopnih frame-ova, gde svaki frame uzorkuje blago razlicite sub-pixel pozicije. Vremenom, akumulirani podaci sadrze dovoljno informacija da se rekonstruise slika koja je znacajno ostrija i detaljnija od bilo kog pojedinacnog frame-a renderovanog na nizoj rezoluciji.

33.1.2 TSR kao zamena za TAA

U Unreal Engine 4, primarni anti-aliasing metod bio je Temporal Anti-Aliasing (TAA). TAA je radio sjajan posao u eliminaciji aliasing-a (onih "nazubljenih ivica" o kojima smo pricali u Poglavlju 15), ali je imao jedan fundamentalni problem: zamucivanje slike. TAA je tezio da "omeksa" sliku, sto je bilo posebno primetno na tankim geometrijskim detaljima, tekstu u igri i teksturama sa visokom frekvencijom detalja.

Sa UE5, Epic Games je napravio fundamentalnu promenu: TSR zamenjuje TAA kao primarni anti-aliasing i upscaling metod. To znaci da kada pokrenete UE5 projekat, TSR je podrazumevano aktivan. On obavlja dve funkcije istovremeno:

  1. Anti-aliasing -- uklanja aliasing artefakte (nazubljene ivice)
  2. Upscaling -- rekonstruise sliku sa nize na visu rezoluciju

Ova dva zadatka su prirodno povezana u temporalnom pristupu, jer oba koriste istu akumuliranu istoriju frame-ova. To je elegantno resenje koje eliminise potrebu za odvojenim AA i upscaling pass-ovima.

33.1.3 Zasto je TSR vazan?

Hajde da stavimo stvari u perspektivu sa konkretnim brojevima.

Renderovanje na 4K rezoluciji (3840 x 2160) znaci da GPU mora da obradi 8.294.400 piksela po frame-u. Na 1080p (1920 x 1080), to je 2.073.600 piksela -- tacno cetiri puta manje.

Ako koristite TSR sa screen percentage-om od 50% (sto znaci da je interna rezolucija 50% prikazne rezolucije u svakoj dimenziji), vi renderujete samo jednu cetvrtinu ukupnog broja piksela. To je ogromna usteda u performansu. Naravno, GPU ne trosi tacno cetiri puta manje vremena jer postoje i drugi troskovi (TSR rekonstrukcija, post-processing, itd.), ali dobitak je svejedno znacajan.

Za moderne AAA igre, gde svaki milisekund frametime-a moze da napravi razliku izmedju 30 i 60 FPS-a, TSR je bukvalno game-changer. Omogucava vam da:


33.2 Kako TSR radi

Sada dolazimo do najzanimljivijeg dela -- tehnickog objasnjenja kako TSR zapravo funkcionise. Objasnicemo svaki korak pipeline-a, od renderovanja na nizoj rezoluciji do finalne rekonstruisane slike.

33.2.1 Pregled pipeline-a

TSR pipeline se moze podeliti na sledece glavne korake:

  1. Renderovanje na nizoj internoj rezoluciji sa jittered sampling-om
  2. Generisanje motion vector-a i depth buffer-a
  3. Reprojection -- mapiranje prethodnog frame-a na trenutnu poziciju kamere
  4. Neighborhood clamping/clipping -- ogranicavanje history vrednosti
  5. Rejection -- odbacivanje nevazece istorije
  6. Blending -- mesanje trenutnog frame-a sa validiranom istorijom
  7. Output -- konacna rekonstruisana slika na prikaznoj rezoluciji

Hajde da prodjemo kroz svaki korak detaljno.

33.2.2 Renderovanje na nizoj internoj rezoluciji

Prvi korak je najjednostavniji za razumevanje: umesto da renderujete scenu na punoj prikaznoj rezoluciji (recimo 4K), vi je renderujete na nizoj internoj rezoluciji.

Ova interna rezolucija se kontrolise parametrom koji se zove Screen Percentage (procenat ekrana). Ako je vas display 4K (3840 x 2160) i postavite screen percentage na 50%, interna rezolucija ce biti:

Interna sirina  = 3840 * 0.50 = 1920 piksela
Interna visina  = 2160 * 0.50 = 1080 piksela

Dakle, scena se renderuje na 1920 x 1080, a TSR zatim rekonstruise sliku na 3840 x 2160.

Vazno je razumeti sta se sve renderuje na internoj rezoluciji:

33.2.3 Jittered sampling -- kljuc celokupnog sistema

Evo gde magija pocinje. Jittered sampling je tehnika koja je apsolutno kljucna za rad TSR-a (i TAA-a pre njega).

Sta je jittering?

Normalno, kada rasterizer odlucuje koji piksel pripada kojem trouglu, on uzorkuje tacno u centru svakog piksela. Ovo je konzistentno, ali znaci da svaki frame "vidi" tacno iste sub-pixel pozicije, i zato nikada ne moze uhvatiti detalje koji padaju izmedju centara piksela.

Sa jittered sampling-om, pozicija uzorkovanja za svaki piksel se pomera (jitter) za mali, kontrolisani offset u svakom frame-u. Ovaj offset se menja iz frame-a u frame prema unapred definisanom obrascu (pattern).

Frame 1:  Uzorkovanje na poziciji (x + 0.125, y + 0.375)
Frame 2:  Uzorkovanje na poziciji (x - 0.250, y + 0.125)
Frame 3:  Uzorkovanje na poziciji (x + 0.375, y - 0.250)
Frame 4:  Uzorkovanje na poziciji (x - 0.125, y - 0.375)
...itd.

UE5 koristi Halton sekvence (bazne 2 i 3) za generisanje ovih offset-a. Halton sekvence imaju odlicno svojstvo da ravnomerno pokrivaju prostor uzorkovanja tokom vremena, sto znaci da ce svaki deo sub-pixel prostora biti uzorkovan nakon dovoljnog broja frame-ova.

Zasto je ovo bitno za upscaling?

Evo kljucnog uvida: ako renderujete na 1080p sa jittered sampling-om i akumulirate podatke iz, recimo, 8 uzastopnih frame-ova, vi ste efektivno uzorkovali scenu na mnogo vise tacaka nego sto je jedan 1080p frame mogao da pruzi. Te akumulirane informacije sadrze dovoljno podataka da se rekonstruise slika na rezoluciji koja je visa od originalne render rezolucije.

Zamislite to kao mozaik: svaki frame vam daje komadice mozaika koji su blago pomereni u odnosu na prethodni frame. Kada sastavite sve komadice, dobijate mnogo detaljniju sliku nego sto je bilo koji pojedinacni frame mogao da pruzi.

Vizuelno:

Piksel na nizoj rezoluciji:   [     ]
                                  ^
                                centar

Frame 1 uzorkuje ovde:         [  x  ]     (x je blago levo od centra)
Frame 2 uzorkuje ovde:         [    x]     (x je desno)
Frame 3 uzorkuje ovde:         [ x   ]     (x je dalje levo)
Frame 4 uzorkuje ovde:         [   x ]     (x je blago desno od centra)

Akumulirani podaci:            [xxxx ]     (4 razlicita uzorka za isti piksel!)

Ovo je fundamentalni princip na kojem pocivaju sve temporalne upscaling tehnologije, ukljucujuci TSR, DLSS i FSR 2.

33.2.4 History buffer -- memorija sistema

History buffer je mozda najvaznija komponenta celokupnog TSR sistema. To je buffer koji cuva akumulirane high-resolution podatke iz prethodnih frame-ova.

Struktura history buffer-a

History buffer radi na prikaznoj rezoluciji (ne na internoj rezoluciji). Dakle, ako je vas display 4K, history buffer je 4K. Ovo je kljucno -- akumulirani podaci se cuvaju na punoj rezoluciji, sto omogucava rekonstrukciju detalja.

History buffer tipicno sadrzi:

Kako se history koristi

U svakom novom frame-u, TSR radi sledece:

  1. Uzima history buffer iz prethodnog frame-a
  2. Koristi motion vector-e da "reprojektuje" history na trenutnu poziciju kamere
  3. Validira reprojektovane podatke (da li su jos uvek relevantni)
  4. Mesha validirani history sa novim podacima iz trenutnog frame-a
  5. Cuva rezultat kao novi history buffer za sledeci frame

Ovaj proces se neprekidno ponavlja, frame za frame-om, sto znaci da TSR konstantno akumulira i azurira informacije o sceni.

33.2.5 Motion vectors -- pracenje kretanja

Da bi TSR mogao da koristi podatke iz prethodnih frame-ova, mora da zna kako se svaki piksel pomerio izmedju frame-ova. Tu ulaze motion vectors (vektori kretanja).

Sta su motion vectors?

Motion vector za svaki piksel na ekranu govori koliko se taj piksel pomerio u odnosu na prethodni frame. Izrazava se kao 2D vektor (dx, dy) u screen-space koordinatama.

Na primer, ako se objekat pomera ulevo, motion vectors za piksel tog objekta ce pokazivati udesno (jer nam govore gde je taj piksel bio u prethodnom frame-u).

Tipovi motion vector-a u UE5

UE5 generise motion vectors iz dva izvora:

  1. Camera motion vectors -- rezultat pomeranja kamere. Izracunavaju se iz razlike izmedju trenutne i prethodne view-projection matrice i primenjuju se na celu scenu na osnovu dubine piksela.

  2. Per-object motion vectors -- rezultat kretanja pojedinacnih objekata (skeletal mesh animacije, world position offset u materijalima, itd.). Ovi se renderuju odvojeno za objekte koji se krecu nezavisno od kamere.

Kombinovani motion vectors su kljucni za reprojection korak TSR-a.

Zasto su tacni motion vectors kriticni

Ovo ne mogu dovoljno da naglasim: kvalitet motion vector-a direktno odredjuje kvalitet TSR-a. Ako motion vectors nisu tacni, TSR ce reprojektovati history na pogresne pozicije, sto rezultuje:

Ovo je posebno problematicno za efekte koji ne generisu tacne motion vectors, poput:

Ako koristite World Position Offset u materijalima, morate aktivirati opciju Output Velocity na materijalu da bi motion vectors bili tacni. Bez toga, TSR nece znati za te pomake i ghosting ce biti neizbezan. Vracamo se na ovo u sekciji o best practices.

33.2.6 Reprojection -- mapiranje istorije na trenutni frame

Kada TSR ima motion vectors, moze da izvrsi reprojection -- proces mapiranja history buffer-a iz prethodnog frame-a na poziciju koja odgovara trenutnom frame-u.

Kako radi reprojection

Za svaki piksel u trenutnom frame-u:

  1. Procitaj motion vector za taj piksel
  2. Koristi motion vector da izracunas gde se taj piksel nalazio u prethodnom frame-u
  3. Uzorkuj history buffer na toj poziciji (uz bilinearnu ili viseg reda interpolaciju)
  4. Rezultat je "reprojektovani history" -- procena sta bi trenutni piksel trebalo da izgleda na osnovu prethodnog frame-a
Trenutni frame (piksel na poziciji [100, 200]):
  Motion vector = (-5, +3)
  
  Pozicija u prethodnom frame-u = [100 - (-5), 200 - 3] = [105, 197]
  
  Uzorkuj history buffer na poziciji [105, 197]
  -> Reprojektovana vrednost = history[105][197]

Problem sa reprojection-om

Reprojection nije savren. Postoji nekoliko situacija gde moze da otkaze:

  1. Disocclusion -- piksel koji je bio zaklonjen u prethodnom frame-u postaje vidljiv u trenutnom. Za taj piksel ne postoji validan history jer ga prethodni frame jednostavno nije "video".

  2. Brzo kretanje -- kada se objekti ili kamera krecu veoma brzo, motion vectors mogu biti nedovoljno precizni, posebno na ivicama objekata.

  3. Deformacija objekta -- ako se objekat deformise (npr. skeletal mesh animacija), motion vectors pokrivaju samo translaciju, ne i promenu oblika.

Ovi problemi se resavaju u sledecim koracima: neighborhood clamping i rejection.

33.2.7 Neighborhood clamping/clipping -- borba protiv ghosting-a

Ovo je jedan od najvaznijih koraka u celokupnom TSR pipeline-u. Neighborhood clamping (ili clipping) je tehnika koja sprecava ghosting tako sto ogranicava reprojektovane history vrednosti na opseg koji je "validan" prema trenutnom frame-u.

Princip rada

Ideja je sledeca: za svaki piksel, pogledajte njegove susede u trenutnom frame-u (tipicno 3x3 ili 5x5 okolina). Izracunajte minimum i maksimum boja u toj okolini. Zatim ogranicite (clamp) reprojektovanu history vrednost tako da upada u taj opseg.

Trenutni frame, okolina 3x3 piksela:
  [0.2] [0.3] [0.2]
  [0.3] [0.4] [0.3]     <- centralni piksel ima vrednost 0.4
  [0.2] [0.3] [0.2]

  Min = 0.2,  Max = 0.4

Reprojektovana history vrednost: 0.8

  0.8 je izvan opsega [0.2, 0.4]
  -> Clamp na 0.4

Rezultat: history vrednost je ogranicena na 0.4

Zasto je ovo bitno?

Bez neighborhood clamping-a, stari, nevazeci podaci iz history-ja bi se "zadrzali" i pojavljivali kao duhovi (ghosting). Na primer, ako se objekat pomeri, piksel gde je objekat bio u prethodnom frame-u i dalje sadrzi boju tog objekta u history-ju. Bez clamping-a, ta boja bi se nastavila prikazivati, stvarajuci efekat "duha" iza pokretnog objekta.

Clamping resava ovo tako sto kaze: "ako history vrednost drasticno odstupa od onoga sto trenutni frame vidi u toj okolini, onda je history verovatno nevazeci i treba ga korigovati."

Clamping vs. Clipping

TSR u praksi koristi sofisticiraniju varijantu zvanu clipping umesto prostog clamping-a. Razlika:

TSR tipicno radi clipping u YCoCg color space-u umesto u RGB-u, jer YCoCg bolje razdvaja luminancu (svetlost) od hrominance (boja), sto daje perceptualno bolje rezultate.

33.2.8 Rejection -- odbacivanje nevazece istorije

Pored neighborhood clamping-a, TSR ima i eksplicitne mehanizme za rejection (odbacivanje) nevazece istorije. Ovo je posebno vazno u situacijama gde clamping sam po sebi nije dovoljan.

Disocclusion rejection

Kada se piksel pojavi na ekranu koji je u prethodnom frame-u bio zaklonjen (disocclusion), history za taj piksel ne postoji ili je potpuno pogresan. TSR detektuje ovo poredjenjem dubine (depth) iz reprojektovanog history-ja sa dubinom u trenutnom frame-u.

Reprojektovana dubina iz history-ja: 50.0 (daleko)
Dubina u trenutnom frame-u:          5.0  (blizu)

Razlika je prevelika -> ovaj piksel je disoccluded
-> Odbaci history, koristi samo trenutni frame za ovaj piksel

Fast motion rejection

Kada su motion vectors veoma veliki (brzo kretanje), TSR smanjuje tezinu history-ja jer je reprojection manje pouzdan pri brzom kretanju. Ovo rezultuje time da brzo pokretni delovi slike imaju manji benefit od temporalne akumulacije (manje upscaling kvaliteta), ali takodje manje ghosting-a.

Confidence-based rejection

TSR interno prati "confidence" (pouzdanost) za svaki piksel u history-ju. Pikseli koji su nedavno bili azurirani sa pouzdanim podacima imaju visu confidence. Pikseli koji su prosli kroz vise clipping operacija ili koji nisu bili adekvatno azurirani duze vreme imaju nizu confidence. Niska confidence dovodi do vece tezine trenutnog frame-a u blending-u.

33.2.9 Blending -- finalno mesanje

Poslednji korak je blending -- mesanje validiranog, clamp-ovanog history-ja sa trenutnim frame-om da bi se dobio finalni rezultat.

Finalni piksel = alpha * trenutni_frame + (1 - alpha) * history

gde je alpha faktor mesanja koji zavisi od:
  - Pouzdanosti history-ja (confidence)
  - Kolicine kretanja (magnitude of motion vectors)
  - Da li je doslo do disocclusion-a
  - Koliko je history prosao kroz clamping

Tipicno, alpha je nizak (npr. 0.05 -- 0.1) kada je history pouzdan, sto znaci da se vecina informacija uzima iz akumuliranog history-ja. Ovo daje stabilnu, ostru sliku. Kada je history nepouzdan, alpha raste (prema 1.0), sto znaci da se vise oslanja na trenutni frame.

Rezultat blending-a se zapisuje nazad u history buffer za koriscenje u sledecem frame-u, i takodje se salje dalje u rendering pipeline kao finalna rekonstruisana slika na punoj prikaznoj rezoluciji.

33.2.10 Sumarni dijagram pipeline-a

Evo kompletnog pregleda TSR pipeline-a u pojednostavljenom obliku:

+----------------------------------------------------------+
|                                                          |
|  1. Render scena na internoj rezoluciji (nizoj)          |
|     - sa jittered sampling-om                            |
|     - generisi depth buffer i motion vectors             |
|                                                          |
+---------------------------+------------------------------+
                            |
                            v
+---------------------------+------------------------------+
|                                                          |
|  2. Reprojection                                         |
|     - Ucitaj history buffer iz prethodnog frame-a        |
|     - Koristi motion vectors da mapiras history na        |
|       trenutnu poziciju kamere                           |
|                                                          |
+---------------------------+------------------------------+
                            |
                            v
+---------------------------+------------------------------+
|                                                          |
|  3. Neighborhood clamping / clipping                     |
|     - Analiziraj okolinu u trenutnom frame-u             |
|     - Ogranici reprojektovane history vrednosti na        |
|       validan opseg                                      |
|                                                          |
+---------------------------+------------------------------+
                            |
                            v
+---------------------------+------------------------------+
|                                                          |
|  4. Rejection                                            |
|     - Detektuj disocclusion (depth test)                 |
|     - Detektuj brzo kretanje                             |
|     - Smanj confidence za problematicne piksele          |
|                                                          |
+---------------------------+------------------------------+
                            |
                            v
+---------------------------+------------------------------+
|                                                          |
|  5. Blending                                             |
|     - Pomesaj validirani history sa trenutnim frame-om   |
|     - alpha zavisi od confidence, kretanja, itd.         |
|     - Sacuvaj rezultat u history buffer                  |
|     - Outputuj finalnu sliku na prikaznoj rezoluciji     |
|                                                          |
+----------------------------------------------------------+

33.3 Quality vs Performance -- kompromisi

Jedan od najvaznijih aspekata TSR-a je razumevanje kompromisa izmedju kvaliteta slike i performansa. Ovo je direktno kontrolisano kroz Screen Percentage i quality mode podesavanja.

33.3.1 Screen Percentage -- srce kompromisa

Screen Percentage kontrolise na kojoj rezoluciji se scena interno renderuje, izrazeno kao procenat prikazne rezolucije u svakoj dimenziji. Ovo je jedini najvazniji parametar koji utice i na kvalitet i na performans.

Hajde da vidimo konkretno sta razliciti screen percentage-i znace za 4K display (3840 x 2160):

Screen Percentage Interna rezolucija Ukupno piksela % piksela od 4K Tipican opis
100% 3840 x 2160 8.294.400 100% Puna rezolucija (samo AA, bez upscaling-a)
75% 2880 x 1620 4.665.600 56.25% Odlican kvalitet, umeren dobitak
67% 2573 x 1447 3.723.131 44.89% Dobar kvalitet, solidan dobitak
50% 1920 x 1080 2.073.600 25% Prihvatljiv kvalitet, ogromni dobitak

Primetite nesto interesantno: screen percentage od 50% ne znaci da renderujete 50% piksela -- znaci da renderujete 25% piksela (jer se procenat primenjuje na obe dimenzije: 0.5 * 0.5 = 0.25). Ovo znaci da je performansni dobitak na nizim screen percentage-ovima enorman.

Kako se ovo odrazava na performans

Hajde da budemo konkretni. Renderovanje na nizoj rezoluciji utice na sve sto se desava pre TSR-a u pipeline-u:

Medjutim, neke stvari se ne smanjuju sa screen percentage-om:

Ovo znaci da je dobitak od smanjenja screen percentage-a veci na scenama koje su pixel-shader bound (kompleksni materijali, mnogo osvetljenja) nego na scenama koje su vertex ili CPU bound.

Prakticni primeri performansa

Evo nekih tipicnih scenarija (vrednosti su ilustrativne, zavise od specificne scene i hardware-a):

Scena: Kompleksna outdoor scena sa mnogo vegetacije
Hardware: NVIDIA RTX 3070
Prikazna rezolucija: 4K (3840 x 2160)

Screen Percentage 100%: 18 FPS  (previse za igru)
Screen Percentage  75%: 28 FPS  (bolje, ali i dalje nedovoljno)
Screen Percentage  67%: 34 FPS  (blizu cilja od 30 FPS)
Screen Percentage  50%: 48 FPS  (odlicno za 30 FPS cilj, blizu 60)

33.3.2 Quality modes u UE5

UE5 nudi nekoliko unapred definisanih quality mode-ova za TSR koji interno podesavaju razlicite parametre. Ovi mode-ovi se mogu podesiti kroz konzolnu komandu ili projekt podesavanja.

TSR Quality Presets

Razliciti quality preset-i u UE5 kontrolisu interno ponasanje TSR algoritma:

Preset Opis Tipicna upotreba
Low Minimalna rekonstrukcija, najbrzi Mobilni uredjaji, najslabiji hardware
Medium Osnovna rekonstrukcija Nizak-do-srednji hardware
High Dobra rekonstrukcija, podrazumevano Vecina desktop konfiguracija
Epic Maksimalna rekonstrukcija Visoki-end hardware

Ovi preset-i uticu na:

Vise interne kvalitete znaci bolju rekonstrukciju, ali i veci GPU trosak za sam TSR pass. U praksi, razlika u performansu izmedju Low i Epic TSR kvalitete je obicno 0.5-2ms na modernom GPU-u, sto je relativno malo u poredjenju sa ukupnim frame time-om.

Podesavanje kvaliteta kroz konzolu

TSR se moze fino podesiti kroz nekoliko konzolnih varijabli:

r.ScreenPercentage 67                -- Postavlja screen percentage na 67%
r.TSR.Quality 3                      -- 0=Low, 1=Medium, 2=High, 3=Epic
r.TSR.History.SampleCount 16         -- Broj uzoraka u history filteru

Takodje, iz Blueprinta ili C++ koda mozete dinamicki menjati screen percentage tokom igre, sto omogucava dynamic resolution -- automatsko prilagodjavanje rezolucije da bi se odrzao cilj framerate-a. O tome vise u nastavku.

33.3.3 Dynamic Resolution sa TSR-om

Dynamic Resolution je sistem koji automatski prilagodjava screen percentage tokom igre da bi odrzao ciljani framerate. U kombinaciji sa TSR-om, ovo je izuzetno mocno jer TSR obezbedjuje da promene rezolucije budu vizuelno manje primetne nego sto bi bile bez upscaling-a.

Kako radi:

  1. Engine meri frametime u svakom frame-u
  2. Ako frametime prekoraci cilj (npr. 16.67ms za 60 FPS), smanjuje screen percentage
  3. Ako je frametime ispod cilja, povecava screen percentage (do maksimuma)
  4. TSR obezbedjuje da promene rezolucije budu glatke i manje vidljive

Podesavanje:

r.DynamicRes.OperationMode 2         -- 2 = automatski rezim
r.DynamicRes.MinScreenPercentage 50  -- Minimalni screen percentage
r.DynamicRes.MaxScreenPercentage 100 -- Maksimalni screen percentage
r.DynamicRes.TargetedMs 16.67       -- Cilj frametime (60 FPS)

Ovo je posebno korisno za konzolne igre gde morate garantovati stabilan framerate, ali zelite maksimalan vizuelni kvalitet u svakom trenutku.

33.3.4 Vizuelni kvalitet na razlicitim screen percentage-ovima

Hajde da budemo iskreni o tome sta mozete ocekivati na razlicitim podesavanjima:

100% Screen Percentage:

75% Screen Percentage:

67% Screen Percentage:

50% Screen Percentage:

Ispod 50%:


33.4 Razlika izmedju TSR-a i TAA upscaling-a

U poglavlju 15 detaljno smo opisali TAA (Temporal Anti-Aliasing). TAA upscaling je starija tehnika koja je bila dostupna u UE4 i koja takodje koristi temporalne podatke za upscaling. Medjutim, postoje fundamentalne razlike izmedju TSR-a i TAA upscaling-a.

33.4.1 TAA Upscaling -- kako radi

TAA upscaling u UE4 je bio relativno jednostavan proces:

  1. Renderuj scenu na nizoj rezoluciji sa jittered sampling-om (isto kao TSR)
  2. Primeni standardni TAA algoritam za anti-aliasing na internoj rezoluciji
  3. Na kraju, uradi jednostavan spatial upscale (bilinearni ili Lanczos filter) na prikaznu rezoluciju

Kljucna razlika je u koraku 3: TAA upscaling ne vrsi sofisticiranu temporalnu rekonstrukciju na visoj rezoluciji. On samo primeni TAA na nizoj rezoluciji i zatim "razvuce" rezultat na visu rezoluciju prostim prostornim filtriranjem.

33.4.2 TSR -- sta radi drugacije

TSR fundamentalno menja pristup:

  1. Renderuj scenu na nizoj rezoluciji sa jittered sampling-om
  2. Rekonstruisi sliku na prikaznoj rezoluciji koristeci temporalne podatke, motion vectors, dubinu i sofisticirane algoritme za validaciju istorije
  3. History buffer vec radi na prikaznoj rezoluciji, sto znaci da akumulirani detalji zaista postoje na toj visoj rezoluciji

Razlika je subtilna ali fundamentalna: TAA upscaling akumulira podatke na nizoj rezoluciji i zatim ih upscale-uje, dok TSR akumulira podatke direktno na visoj rezoluciji.

33.4.3 Poredjenje kvaliteta

Aspekt TAA Upscaling TSR
Ostrina Cesto mutna slika, posebno na nizim screen % Znacajno ostrija, bolje ocuvani detalji
Stabilnost Umerena, moze da shimmer-uje Bolja temporalna stabilnost
Ghosting Cesce, manje sofisticirano odbacivanje Rede, bolja validacija istorije
Tanki detalji Cesto se gube Bolje ocuvani zahvaljujuci high-res history-ju
Performance overhead Minimalan (prost upscale) Veci (sofisticiraniji algoritam)
Podrzane platforme Sve Sve (ali zahteva moderniji GPU za optimalan rad)

33.4.4 Vizuelne razlike u praksi

Hajde da pogledamo kako se razlike manifestuju u praksi na konkretnim primerima:

Tekst i UI elementi renderovani u 3D svetu:

Tanka geometrija (zice, ograde, antene):

Teksture sa visokom frekvencijom detalja (cigle, krov crepovi):

Vegetacija (lisce, trava):

33.4.5 Kada koristiti TAA umesto TSR-a?

U vecini slucajeva, TSR je superioran izbor. Medjutim, postoje retke situacije gde biste mogli da razmotrite TAA:

Za sve ostale slucajeve, koristite TSR. To je podrazumevani i preporuceni izbor u UE5.


33.5 Poredjenje sa DLSS-om i FSR-om

TSR nije jedina upscaling tehnologija na trzistu. NVIDIA DLSS i AMD FSR su dva konkurentska resenja koja takodje nude temporalni upscaling. Razumevanje razlika i kompromisa izmedju ovih tehnologija pomoci ce vam da donesete informisanu odluku za vas projekat.

33.5.1 NVIDIA DLSS (Deep Learning Super Sampling)

Sta je DLSS?

DLSS je NVIDIA-ino resenje za upscaling koje koristi vestacku inteligenciju -- konkretno, duboke neuronske mreze -- za rekonstrukciju slike. DLSS model je treniran na ogromnom broju parova slika (niska rezolucija -> visoka rezolucija) koristeci NVIDIA-ine superracunare.

Kako radi DLSS?

  1. Scena se renderuje na nizoj rezoluciji (slicno TSR-u)
  2. Engine generise motion vectors i depth buffer
  3. Ovi podaci, zajedno sa prethodnim frame-ovima, salju se neuronskoj mrezi
  4. Neuronska mreza inferira (predvidja) kako bi slika izgledala na punoj rezoluciji
  5. Rezultat je rekonstruisana slika na prikaznoj rezoluciji

Kljucna razlika: DLSS ne koristi rucno napisane algoritme za rekonstrukciju (kao TSR), vec naucene obrasce iz treninga na milionima slika.

Hardware zahtevi

Ovo je kljucno ogranicenje DLSS-a: zahteva NVIDIA GPU sa Tensor jezgrima. To u praksi znaci:

GTX kartice, AMD kartice i Intel kartice ne podrzavaju DLSS. Ovo je najznacajniji nedostatak DLSS-a -- ogranicen je na jedan segment trzista.

DLSS Quality Presets

Preset Screen Percentage (priblizno) Opis
Quality ~67% Najbolji kvalitet, najmanji dobitak
Balanced ~58% Dobar balans
Performance ~50% Veci dobitak, dobar kvalitet
Ultra Performance ~33% Maksimalan dobitak, primetan gubitak kvaliteta

33.5.2 AMD FSR (FidelityFX Super Resolution)

FSR 1.0 vs FSR 2.0+

Vazno je razlikovati dve generacije FSR-a jer se fundamentalno razlikuju:

FSR 1.0 je bio cisto prostorni (spatial) upscaler -- nije koristio temporalne podatke, prethodne frame-ove ni motion vectors. Bio je u sustini napredan filter za upscaling slike, slican Lanczos filteru ali sa dodatnim sharpening-om. Funkcionisao je kao post-process efekat koji se mogao primeniti na bilo koju igru.

FSR 2.0+ je temporalni upscaler, slican TSR-u po pristupu. Koristi motion vectors, prethodne frame-ove i sofisticirane algoritme za rekonstrukciju. Ovo je verzija koju poredimo sa TSR-om.

Kako radi FSR 2.0+

FSR 2.0+ radi na slican nacin kao TSR:

  1. Renderuje scenu na nizoj rezoluciji
  2. Koristi motion vectors, depth i prethodne frame-ove
  3. Primenjuje temporalnu rekonstrukciju za upscaling

Kljucna razlika u odnosu na DLSS: FSR koristi algoritamski pristup (rucno napisani algoritmi), ne vestacku inteligenciju. Ovo mu daje prednost u kompatibilnosti -- radi na bilo kom GPU-u koji podrzava Vulkan ili DirectX 12.

Hardware zahtevi

FSR 2.0+ radi na:

33.5.3 TSR -- pozicija u ekosistemu

Prednosti TSR-a

  1. Engine integracija -- TSR je duboko integrisan u UE5 rendering pipeline. Ne zahteva eksterni plugin ili SDK.

  2. Platformska nezavisnost -- radi na svakom GPU-u koji moze da pokrene UE5, ukljucujuci:

    • Windows (DirectX 11, DirectX 12, Vulkan)
    • macOS (Metal)
    • Linux (Vulkan)
    • Konzole (PlayStation 5, Xbox Series X|S)
    • Mobilne platforme (sa ogranicenjima)
  3. Konzistentnost -- posto je deo engine-a, TSR se ponasa identicno na svim platformama. Ne morate da brinete o razlicitom ponasanju na AMD vs. NVIDIA hardware-u.

  4. Optimizovan za UE5 -- TSR je dizajniran specifično za UE5 rendering pipeline i ima pristup internim podacima engine-a kojima eksterni upscaleri nemaju pristup (ili im je pristup ogranicen).

  5. Nema zavisnosti od vendor-a -- ne zavisnice od NVIDIA ili AMD SDK-a, sto pojednostavljuje build process i distribuciju.

Mane TSR-a

  1. Kvalitet nije uvek na nivou DLSS-a -- DLSS, zahvaljujuci neuronskim mrezama, cesto produkuje ostrije i detaljnije rezultate na istom screen percentage-u, posebno na veoma niskim rezolucijama.

  2. Performans overhead -- TSR moze biti nesto skuplji od DLSS-a jer ne koristi specijalizovani hardware (Tensor jezgra) za inferiranje.

  3. Ogranicen na UE5 -- ne mozete koristiti TSR u drugim engine-ima ili standalone aplikacijama.

33.5.4 Detaljno poredjenje

Aspekt TSR DLSS FSR 2.0+
Pristup Algoritamski, temporalni AI/neuronska mreza, temporalni Algoritamski, temporalni
Hardware zahtevi Bilo koji GPU NVIDIA RTX (Tensor jezgra) Bilo koji GPU
Engine integracija Nativna (UE5) Plugin Plugin
Kvalitet na ~67% SP Veoma dobar Odlican Dobar do veoma dobar
Kvalitet na ~50% SP Dobar Veoma dobar Dobar
Kvalitet na ~33% SP Primetan pad Dobar (Ultra Perf.) Primetan pad
Ghosting Redak Redak Povremeno
Ostrina Dobra Najbolja Dobra
Shimmer Povremeno Minimalan Povremeno
Performance overhead Umeren Nizak (Tensor jezgra) Umeren
Platforme Sve UE5 platforme Samo NVIDIA RTX Sve
Konzole Da Ne Da (PS5, Xbox)

33.5.5 Kada koristiti TSR vs DLSS vs FSR?

Koristite TSR kada:

Koristite DLSS (pored TSR-a) kada:

Koristite FSR (pored TSR-a) kada:

Kombinovani pristup (preporuka za vecinu projekata):

Mnoge moderne igre nude sve tri opcije kao izbor u grafickim podesavanjima:

Anti-Aliasing / Upscaling:
  [x] TSR (podrazumevano)
  [ ] NVIDIA DLSS (zahteva RTX GPU)
  [ ] AMD FSR 2
  [ ] TAA (legacy)
  [ ] Bez upscaling-a

Ovo je idealan pristup jer daje igracima slobodu izbora, ali zahteva testiranje i odrzavanje svih opcija.


33.6 Artefakti i ogranicenja

Nijedna tehnologija nije savrsena, i TSR nije izuzetak. Razumevanje mogucih artefakata i ogranicenja je kljucno za pravilno koriscenje TSR-a i za znanje kako ih minimizovati ili izbegazati.

33.6.1 Ghosting

Ghosting je najpoznatiji i najcesci artefakt temporalnih upscaling sistema. Manifestuje se kao "duhovi" -- ostaci prethodnih frame-ova koji se pojavljuju na pogresnim mestima ili se zadrzavaju predugo.

Kako izgleda ghosting?

Uzroci ghosting-a

  1. Netacni motion vectors -- ako motion vectors ne predstavljaju tacno kretanje piksela, reprojection ce biti pogresan i stari podaci se nece pravilno odbaciti.

  2. Nedovoljan rejection -- neighborhood clamping nije uvek dovoljno agresivan da potpuno eliminise nevazece history podatke, posebno kada se boje blago menjaju.

  3. Nagla promena osvetljenja -- ako svetlo naglo upalite ili ugasite, history buffer sadrzi stare vrednosti osvetljenja koje se nece odmah odbaciti.

  4. Prozirni objekti -- transparentni objekti cesto ne generisu motion vectors, sto TSR-u onemogucava pravilnu reprojection.

Kako minimizovati ghosting

33.6.2 Shimmering

Shimmering (treperenje) se pojavljuje na tankoj geometriji i detaljima sa visokom prostornom frekvencijom. Manifestuje se kao nestabilno treperenje piksela, posebno pri laganom kretanju kamere.

Sta uzrokuje shimmering?

Shimmering nastaje kada detalji scene imaju prostornu frekvenciju koja je visa od one koju interna rezolucija moze da uhvati. Na primer, tanka zica debljine jednog piksela na punoj rezoluciji bice debljine pola piksela na 50% screen percentage-u. To znaci da ce je jedan frame uhvatiti, a drugi nece, sto dovodi do treperenja.

Puna rezolucija (100%):  zica zauzima 1 piksel   -> uvek vidljiva
Screen percentage 50%:   zica zauzima 0.5 piksela -> ponekad vidljiva

Frame 1: jitter pomera uzorkovanje levo  -> zica uhvacena  (vidljiva)
Frame 2: jitter pomera uzorkovanje desno -> zica promasena (nevidljiva)
Frame 3: jitter ponovo levo             -> zica uhvacena  (vidljiva)

Rezultat: zica treperi izmedju vidljive i nevidljive -> shimmering

Kako smanjiti shimmering

  1. Koristite visi screen percentage -- vise piksela = manje problema sa sub-pixel detaljima
  2. Prilagodite LOD podesavanja -- na nizim screen percentage-ovima, LOD treba da bude agresivniji da bi se uklonili previse tanki detalji
  3. Mip bias podesavanje -- podignite mip bias da koristite ostrije mipmap nivoe (vise o ovome u sekciji o best practices)
  4. Izbegavajte previse tanku geometriju -- ako pravite ograde, zice ili slicne objekte, pokusajte da im date minimalnu debljinu od 2 piksela na najnizem planiranom screen percentage-u

33.6.3 Interakcija sa Motion Blur-om

Motion blur i TSR imaju interesantan odnos. Oba sistema koriste motion vectors, ali na razlicite nacine.

Problem

Motion blur se primenjuje pre TSR-a u rendering pipeline-u, na internoj rezoluciji. To znaci:

Resenje

U praksi, mnogi developeri biraju jedan od dva pristupa:

  1. Smanjite intenzitet motion blur-a kada koristite TSR na nizim screen percentage-ovima
  2. Potpuno iskljucite per-object motion blur i zadrzite samo camera motion blur, koji je manje problematican

UE5 konzolne varijable za podesavanje:

r.MotionBlur.Amount 0.5          -- Smanjuje intenzitet motion blur-a
r.MotionBlur.Max 0               -- Potpuno iskljucuje motion blur
r.MotionBlurQuality 4            -- Povecava kvalitet (ako koristite blur)

33.6.4 Cestice i VFX na nizoj rezoluciji

Ovo je jedan od najproblematicnijih aspekata TSR-a za VFX umetnika. Particle effects i drugi vizuelni efekti se renderuju na internoj rezoluciji, sto znaci da na nizim screen percentage-ovima gube detalje.

Problemi sa cesticama

  1. Niagara particles se renderuju na internoj rezoluciji

    • Na 50% SP, cestice imaju cetvrtinu piksela
    • Tanke, detaljne cestice (iskre, dim sa finim detaljima) gube kvalitet
  2. Sprite-based particles cesto nemaju motion vectors

    • TSR ne moze pravilno da reprojektuje cestice bez motion vector-a
    • Rezultat: ghosting, smearing ili popping na cesticama
  3. Soft particles (koje se mesaju sa dubinom scene) mogu imati artefakte na ivicama gde se srecu sa geometrijom

Resenja za VFX

UE5 nudi opciju da se odredjeni efekti renderuju na punoj rezoluciji umesto na internoj:

// U Niagara sistemu, mozete podesiti render rezoluciju
// za specificne emittere

// Takodje mozete koristiti:
r.TSR.VFX.FullResolution 1     -- Renderuj VFX na punoj rezoluciji

Medjutim, renderovanje VFX-ova na punoj rezoluciji ponistava deo performansnog dobitka TSR-a, pa treba biti selektivan -- samo kriticne, prominentne efekte renderujte na punoj rezoluciji.

33.6.5 Transparency (prozirnost) i TSR

Prozirni objekti predstavljaju poseban izazov za TSR iz vise razloga.

Problem sa transparency

  1. Motion vectors -- prozirni objekti se renderuju u odvojenom translucency pass-u koji tipicno ne generise per-pixel motion vectors. TSR nema informacije o kretanju prozirnih objekata.

  2. Dubina -- prozirni objekti cesto ne zapisuju u depth buffer, sto znaci da TSR ne moze da koristi dubinu za validaciju.

  3. Blending -- prozirni objekti se mesaju sa pozadinom, sto znaci da jedan piksel sadrzi kombinovanu informaciju i objekta i pozadine. Ovo komplikuje temporalnu rekonstrukciju.

Tipicni artefakti na transparentnim objektima

Kako ruckovati transparency sa TSR-om

  1. Koristite Masked materijale umesto Translucent kada je moguce -- Masked materijali generisu motion vectors i zapisuju dubinu, sto TSR-u omogucava pravilnu rekonstrukciju. Za lisce, ograde i slicne objekte, Masked je gotovo uvek bolji izbor.

  2. Separate Translucency -- UE5 ima opciju za renderovanje prozirnih objekata u odvojenom pass-u koji se primenjuje posle TSR-a, na punoj rezoluciji. Ovo eliminise TSR artefakte na tim objektima, ali po cenu performansa.

  3. Responsive AA -- na materijalima mozete aktivirati opciju koja kaze TSR-u da koristi manje history-ja za te piksele, sto smanjuje ghosting ali i smanjuje kvalitet rekonstrukcije.

Material Editor:
  -> Translucency
     -> Separate Translucency: Enabled
     
  -> ili na samom materijalu:
     -> Responsive AA: Enabled (smanjuje ghosting na prozirnim objektima)

33.6.6 Drugi artefakti

Smearing na ivicama ekrana

Kada se kamera brzo rotira, pikseli na ivicama ekrana imaju veoma velike motion vectors. History za piksele koji dolaze "spolja" ne postoji (jer nisu bili na ekranu u prethodnom frame-u). Ovo moze dovesti do kratkotrajnog zamucenja ili artefakata na ivicama ekrana tokom brze rotacije kamere.

Disocclusion artifacts

Kada se objekat pomeri i otkrije deo scene koji je bio zaklonjen, TSR nema history za te novootkrivene piksele. Na jedan ili dva frame-a, ti pikseli mogu izgledati zamuceno ili imati vidljive artefakte dok TSR ne akumulira dovoljno podataka.

Subpixel jitter visibility

Na veoma niskim screen percentage-ovima (ispod 50%), jitter obrasci mogu postati vidljivi kao blago "drhtanje" na staticnim scenama. Ovo je rede na visim screen percentage-ovima.


33.7 Best practices

Sada kada razumete kako TSR radi i koji su mogući problemi, hajde da prodjemo kroz konkretne preporuke i best practices za razlicite scenarije.

33.7.1 Preporuceni screen percentage-i za razlicite ciljeve

Za desktop PC igre (60 FPS cilj)

Visoki kvalitet (High/Epic grafike):   Screen Percentage = 75%
Srednji kvalitet (Medium grafike):     Screen Percentage = 67%
Niski kvalitet (Low grafike):          Screen Percentage = 50%

Za konzolne igre

Quality mode (30 FPS):                 Screen Percentage = 67% - 75%
Performance mode (60 FPS):             Screen Percentage = 50% - 67%

Za VR projekte

VR zahteva veoma visok framerate (90+ FPS) i ima specificne zahteve:

Preporuceno:                           Screen Percentage = 70% - 80%
Napomena: TSR u VR-u moze uzrokovati dodatnu latenciju
          i artefakte zbog razlicitih perspektiva za svako oko

Za archviz i filmske projekte

Interaktivni pregled:                  Screen Percentage = 67% - 75%
Finalni render (Sequencer):            Screen Percentage = 100%
Napomena: Za statitcne scene, TSR na 75% moze izgledati
          gotovo identicno kao 100% nakon konvergencije

33.7.2 Mip bias podesavanje -- kriticno za kvalitet

Ovo je jedna od najvaznijih i najcesce zanemarenih best practice-a za TSR. Ako ne podesite mip bias, vasa slika ce izgledati znacajno losije nego sto bi trebalo.

Sta je problem?

Kada renderujete na nizoj rezoluciji, engine bira mipmap nivoe tekstura na osnovu te nize rezolucije. To znaci da ce teksture biti zamucene jer engine misli da su dalje od kamere ili da zauzimaju manje piksela nego sto zapravo zauzimaju na finalnoj, rekonstruisanoj slici.

Setite se Poglavlja 5 gde smo detaljno objasnili mipmaps: engine bira mipmap nivo na osnovu toga koliko piksela tekstura zauzima na ekranu. Na nizoj internoj rezoluciji, tekstura zauzima manje piksela, pa engine bira mutnji mipmap nivo.

Resenje: negativan mip bias

Da biste kompenzovali ovo, treba primeniti negativan mip bias koji gura engine da koristi ostrije (detaljnije) mipmap nivoe.

Formula za izracunavanje mip bias-a:

MipBias = log2(ScreenPercentage / 100)

Primeri:
  Screen Percentage 100%:  log2(1.0)    =  0.0  (bez promene)
  Screen Percentage  75%:  log2(0.75)   = -0.41
  Screen Percentage  67%:  log2(0.67)   = -0.58
  Screen Percentage  50%:  log2(0.5)    = -1.0

Kako primeniti mip bias u UE5

Dobra vest: UE5 automatski primenjuje mip bias za TSR na osnovu screen percentage-a. Ne morate ga rucno podesavati u vecini slucajeva.

Medjutim, ako koristite custom Texture Samplers u materijalima ili ako imate specificne potrebe, mozete rucno podesiti:

// Konzolna varijabla za globalni mip bias:
r.MipBias.Global -0.5

// U materijalu, Texture Sample node ima opciju za Mip Bias
// koja se moze koristiti za fino podesavanje per-tekstura

Upozorenje: previse negativan mip bias

Pazite da ne preterajete sa negativnim mip bias-om. Previse ostri mipmap nivoi mogu uzrokovati:

Zlatno pravilo: drzite se automatskog UE5 podesavanja osim ako imate konkretan razlog da ga promenite.

33.7.3 VFX razmatranja

Opste preporuke za VFX sa TSR-om

  1. Testirajte efekte na najnizem planiranom screen percentage-u

    • Ako vas minimum screen percentage je 50%, testirajte sve efekte na toj rezoluciji
    • Efekti koji izgledaju dobro na 100% mogu potpuno da se raspadnu na 50%
  2. Koristite Niagara umesto Cascade-a

    • Niagara ima bolju integraciju sa TSR-om
    • Nudi vise kontrole nad renderovanjem na razlicitim rezolucijama
  3. Dajte cesticama minimalnu velicinu

    • Cestice manje od 2x2 piksela na internoj rezoluciji ce imati problema
    • Za screen percentage 50%, to znaci da cestice treba da budu barem 4x4 piksela na prikaznoj rezoluciji
  4. Razmotreni separate translucency za kriticne efekte

    • Za velike, prominentne efekte (eksplozije, magija), koristite Separate Translucency da ih renderujete na punoj rezoluciji
    • Za ambijentalne efekte (dim u daljini, prasina), renderujte na internoj rezoluciji
  5. Motion vectors za cestice

    • Gde god je moguce, obezbedite motion vectors za cestice
    • U Niagara-i, aktivirajte velocity rendering za emittere koji se brzo krecu

Primer: Podesavanje Niagara emitera za TSR

Niagara Emitter Settings:
  -> Renderer
     -> Sort Mode: View Distance (umesto View Depth za bolje rezultate sa TSR)
     -> Sub UV Blending: Enabled (glatke animacije cestica)
     -> Motion Vector Generation: Accurate (vazno za TSR!)

33.7.4 Materijal best practices

World Position Offset i Output Velocity

Ako koristite World Position Offset (WPO) za animaciju geometrije (vegetacija koja se klati na vetru, voda, zastave), obavezno aktivirajte Output Velocity na materijalu:

Material Editor:
  -> Details panel
     -> Material
        -> Output Velocity: Enabled

Bez ovoga, TSR nema motion vectors za WPO animaciju i rezultat ce biti ghosting na svim animiranim objektima. Ovo je verovatno najcesci uzrok ghosting artefakata u UE5 projektima.

Responsive AA na problematicnim materijalima

Za materijale koji konstantno imaju problem sa ghosting-om (npr. automatska vrata, displej ekrani koji brzo menjaju sadrzaj), mozete aktivirati Responsive AA:

Material Editor:
  -> Details panel
     -> Translucency ili Post Process
        -> Responsive AA: Enabled

Ovo govori TSR-u da koristi manje history-ja za te piksele. Smanjuje ghosting, ali takodje smanjuje kvalitet upscaling-a na tim pikselima (vise noise-a, manje stabilnosti).

Dithered Opacity Mask

Za materijale koji koriste opacity mask (lisce, ograde), razmislite o koriscenju Dithered Opacity Mask sa TSR-om. Dithered masking stvara pattern koji se dobro ponasa sa temporalnom akumulacijom:

Material Editor:
  -> Details panel
     -> Material
        -> Dithered LOD Transition: Enabled

33.7.5 Podesavanje scene za optimalne TSR rezultate

Osvetljenje

Geometrija

Camera podesavanja

Project Settings:
  -> Engine
     -> Rendering
        -> Default Settings
           -> Anti-Aliasing Method: TSR

33.7.6 Debugging TSR artefakata

Kada naidjete na artefakte, evo sistematicnog pristupa za debugging:

Korak 1: Izolirajte problem

1. Postavite Screen Percentage na 100% 
   -> Ako artefakt nestane, problem je vezan za upscaling
   -> Ako artefakt ostane, problem je drugde (materijal, osvetljenje, itd.)

2. Iskljucite TSR i ukljucite TAA
   r.AntiAliasingMethod 2  (TAA)
   -> Ako artefakt nestane, problem je specifican za TSR
   -> Ako artefakt ostane, problem je u TAA sistemu generalno

Korak 2: Proverite motion vectors

// Vizualizujte motion vectors:
ShowFlag.MotionVectors 1
// ili
vis MotionVectors

// Proverite da li pokretni objekti imaju ispravne motion vectors
// Ako objekat nema motion vectors (crn), to je uzrok ghosting-a

Korak 3: Proverite specifican materijal

// Ako je problem na specificnom materijalu:
1. Da li materijal koristi WPO? -> Ukljucite Output Velocity
2. Da li je materijal Translucent? -> Razmislite o Separate Translucency
3. Da li materijal ima screen-space efekte? -> Testirajte bez njih

Korak 4: Proverite TSR quality podesavanja

// Pokusajte sa visim kvalitetom:
r.TSR.Quality 3

// Proverite history:
r.TSR.History.SampleCount 32  // Povecajte za bolju akumulaciju

// Ako nista ne pomaze, mozda je artefakt inherentan 
// za vas screen percentage i treba ga povecati

33.7.7 Profilisanje TSR performansa

Da biste razumeli koliko TSR kosta u vasem projektu:

// Koristite GPU profiler:
stat GPU

// TSR pass ce se pojaviti kao "TSR" ili "TemporalSuperResolution"
// Tipicni troskovi:
//   Low quality:   0.3 - 0.8 ms
//   Medium:        0.5 - 1.2 ms
//   High:          0.7 - 1.5 ms
//   Epic:          1.0 - 2.5 ms
// (zavisi od rezolucije i GPU-a)

// Uporedite sa ustedom od nizeg screen percentage-a:
// Tipicno, usteda je 3-8 ms na kompleksnim scenama
// Dakle, neto dobitak je uvek pozitivan

33.8 Napredne teme

33.8.1 TSR i Nanite

Nanite, UE5 sistem za virtualizovanu geometriju, ima zanimljivu interakciju sa TSR-om. Nanite automatski upravlja nivoom geometrijskog detalja na osnovu broja piksela koje trougao zauzima na ekranu. Kada koristite TSR sa nizim screen percentage-om, Nanite "vidi" nizu internu rezoluciju i prilagodjava geometriju tome.

To znaci da na nizem screen percentage-u, Nanite koristi manje trouglova, sto dodatno ubrzava renderovanje. Ovo je pozitivna sinergija -- TSR i Nanite se medjusobno nadopunjuju za optimalan performans.

33.8.2 TSR i Lumen

Lumen, UE5 sistem za globalno osvetljenje, takodje radi na internoj rezoluciji kada se koristi sa TSR-om. Ovo znaci da su Lumen tracing i final gather jeftiniji na nizem screen percentage-u.

Medjutim, nize rezolucija Lumen rezultata moze dovesti do vidljivih artefakata u globalnom osvetljenju. UE5 ima interne mehanizme koji kompenzuju ovo, ali na veoma niskim screen percentage-ovima (ispod 50%), Lumen artefakti mogu postati primetni.

33.8.3 TSR sa Movie Render Queue

Kada renderujete cinematics ili filmove koristeci Movie Render Queue, TSR se moze koristiti za poboljsanje anti-aliasing-a cak i na punom screen percentage-u (100%). Temporal akumulacija tokom vise frame-ova daje veoma cist, stabilan rezultat.

Za filmski render, preporucujem:

Screen Percentage: 100%
TSR Quality: Epic
// TSR ce raditi samo kao visokokvalitetni AA
// Temporal akumulacija daje odlicne rezultate za statitcne scene

Za real-time preview tokom rada na cinematics-ima:

Screen Percentage: 67%
TSR Quality: High
// Dobijate brzi feedback sa pristojnim kvalitetom

33.8.4 Buducnost TSR-a

Epic Games kontinuirano unapredjuje TSR sa svakim UE5 update-om. Neka ocekivana poboljsanja ukljucuju:


33.9 Prakticni primeri podesavanja

33.9.1 Primer: Open-world igra, PC + konzole

// DefaultEngine.ini

[/Script/Engine.RendererSettings]
r.AntiAliasingMethod=4                    // TSR
r.ScreenPercentage=67                     // Podrazumevano 67%
r.TSR.Quality=2                           // High quality

// Dinamicka rezolucija
r.DynamicRes.OperationMode=2              // Automatski
r.DynamicRes.MinScreenPercentage=50       // Minimum 50%
r.DynamicRes.MaxScreenPercentage=100      // Maksimum 100%

// Mip bias (automatski za TSR, ali eksplicitno za sigurnost)
r.MipBias.Global=0                        // Nula jer TSR sam upravlja

// VFX
r.TSR.VFX.FullResolution=0               // VFX na internoj rezoluciji
                                          // (individualno podesiti za
                                          //  kriticne efekte)

33.9.2 Primer: Konkurentan FPS, cilj 144 FPS

// Za competitivne igre gde je framerate prioritet

[/Script/Engine.RendererSettings]
r.AntiAliasingMethod=4                    // TSR
r.ScreenPercentage=50                     // Agresivan upscaling za FPS
r.TSR.Quality=1                           // Medium (minimalan overhead)

// Nema dinamicke rezolucije -- fiksan screen %
r.DynamicRes.OperationMode=0

// Motion blur iskljucen (kompetitivne igre)
r.MotionBlur.Amount=0

33.9.3 Primer: Archviz, cilj vizuelni kvalitet

// Za arhitektonske vizualizacije

[/Script/Engine.RendererSettings]
r.AntiAliasingMethod=4                    // TSR
r.ScreenPercentage=75                     // Visok kvalitet
r.TSR.Quality=3                           // Epic quality

// Nema dinamicke rezolucije
r.DynamicRes.OperationMode=0

// Separate translucency za staklo
r.SeparateTranslucency=1

33.9.4 Primer: Graficki meni u igri (Blueprint/C++)

Evo primera kako da napravite graficki meni koji dozvoljava igracu da bira upscaling metod i screen percentage:

// C++ primer za menjanje TSR podesavanja u runtime-u

#include "Engine/RendererSettings.h"

void UGraphicsSettingsWidget::SetUpscalingMethod(EUpscalingMethod Method)
{
    switch (Method)
    {
    case EUpscalingMethod::TSR:
        // Postavi TSR kao anti-aliasing metod
        IConsoleVariable* AntiAliasing = IConsoleManager::Get()
            .FindConsoleVariable(TEXT("r.AntiAliasingMethod"));
        if (AntiAliasing)
        {
            AntiAliasing->Set(4); // 4 = TSR
        }
        break;
        
    case EUpscalingMethod::TAA:
        // Fallback na TAA
        IConsoleVariable* AntiAliasing = IConsoleManager::Get()
            .FindConsoleVariable(TEXT("r.AntiAliasingMethod"));
        if (AntiAliasing)
        {
            AntiAliasing->Set(2); // 2 = TAA
        }
        break;
    }
}

void UGraphicsSettingsWidget::SetScreenPercentage(float Percentage)
{
    // Clamp izmedju 25% i 100%
    Percentage = FMath::Clamp(Percentage, 25.0f, 100.0f);
    
    IConsoleVariable* ScreenPct = IConsoleManager::Get()
        .FindConsoleVariable(TEXT("r.ScreenPercentage"));
    if (ScreenPct)
    {
        ScreenPct->Set(Percentage);
    }
}

33.10 Rezime poglavlja

TSR je jedna od onih tehnologija koje fundamentalno menjaju nacin na koji pristupamo renderovanju u realnom vremenu. Umesto da se borimo sa ogranicenjima hardware-a pokusavajuci da renderujemo svaki piksel na punoj rezoluciji, TSR nam omogucava da pametno koristimo temporalne podatke za rekonstrukciju slike koja izgleda gotovo jednako dobro uz drasticno manji racunarski trosak.

Evo kljucnih poruka koje treba da ponesete iz ovog poglavlja:

  1. TSR renderuje na nizoj rezoluciji i rekonstruise na visoj koristeci temporalne podatke, motion vectors i sofisticirane algoritme za validaciju.

  2. Screen Percentage je najvazniji parametar -- 67% je odlicna polazna tacka za vecinu projekata. Na tom procentu, renderujete manje od polovine piksela uz minimalan gubitak kvaliteta.

  3. Jittered sampling i history buffer su srce sistema -- akumuliranjem podataka iz vise frame-ova, TSR moze da rekonstruise detalje koji na pojedinacnom frame-u nisu vidljivi.

  4. Ghosting i shimmering su glavni artefakti -- resavaju se pravilnim motion vector-ima (Output Velocity na materijalima!), razumnim screen percentage-om i pazljivim dizajnom scene.

  5. TSR je platformski nezavisan -- za razliku od DLSS-a koji zahteva NVIDIA RTX hardware, TSR radi svuda gde radi UE5.

  6. Mip bias se automatski podesava, ali razumevanje zasto je vazan pomaze u debug-ovanju problema sa ostrinom tekstura.

  7. VFX zahtevaju posebnu paznju -- testirajte na najnizem planiranom screen percentage-u i koristite Separate Translucency za kriticne efekte.


Tabela kljucnih pojmova

Termin Objasnjenje
TSR (Temporal Super Resolution) UE5 ugradjeni sistem za temporalni upscaling koji renderuje na nizoj rezoluciji i rekonstruise sliku na visoj koristeci podatke iz vise frame-ova
Screen Percentage Procenat prikazne rezolucije na kojem se scena interno renderuje (npr. 50% = polovina u svakoj dimenziji = cetvrtina piksela)
Jittered Sampling Tehnika pomeranja pozicije uzorkovanja za svaki piksel u svakom frame-u, omogucava akumulaciju sub-pixel detalja
History Buffer Buffer na prikaznoj rezoluciji koji cuva akumulirane podatke iz prethodnih frame-ova
Motion Vectors 2D vektori koji za svaki piksel govore koliko se pomerio izmedju frame-ova
Reprojection Proces mapiranja podataka iz prethodnog frame-a na poziciju u trenutnom frame-u koristeci motion vectors
Neighborhood Clamping/Clipping Tehnika ogranicavanja reprojektovanih history vrednosti na opseg validan prema trenutnom frame-u
Rejection Odbacivanje nevazece istorije na osnovu dubine, kretanja ili confidence-a
Disocclusion Pojava piksela koji je bio zaklonjen u prethodnom frame-u -- nema validnog history-ja
Ghosting Artefakt gde se ostaci prethodnih frame-ova pojavljuju kao "duhovi" na pogresnim pozicijama
Shimmering Treperenje tankih detalja ili visoko-frekventnih tekstura uzrokovano sub-pixel aliasing-om
Mip Bias Pomeranje izbora mipmap nivoa teksture -- negativan bias bira ostrije nivoe, kompenzuje nizu internu rezoluciju
DLSS NVIDIA-in upscaling sistem zasnovan na vestackoj inteligenciji, zahteva RTX GPU sa Tensor jezgrima
FSR AMD-ov algoritmicki upscaling sistem koji radi na svim GPU-ovima
Dynamic Resolution Sistem koji automatski prilagodjava screen percentage tokom igre da bi odrzao ciljani framerate
Separate Translucency Tehnika renderovanja prozirnih objekata u odvojenom pass-u na punoj rezoluciji, zaobilazeci TSR upscaling
Responsive AA Materijal opcija koja smanjuje tezinu history-ja za specificne piksele, smanjuje ghosting ali i kvalitet rekonstrukcije
Output Velocity Materijal opcija koja omogucava generisanje tacnih motion vector-a za World Position Offset animacije
Halton Sequence Kvazi-nasumicna sekvenca koja se koristi za generisanje jitter offset-a sa dobrim pokrivanjem prostora uzorkovanja

Reference i dodatno citanje

Unreal Engine dokumentacija

Tehnicke prezentacije

Poredjenje sa DLSS i FSR

Poglavlja u ovoj knjizi


U sledecem poglavlju prelazimo na temu koja je usko povezana sa TSR-om -- Dynamic Resolution i adaptivno upravljanje kvalitetom u realnom vremenu. Videcemo kako mozete kombinovati TSR sa dinamickim podesavanjima da biste garantovali stabilan framerate bez zrtvovanja vizuelnog kvaliteta.