Poglavlje 43: Overdraw i Fill Rate

U prethodnom poglavlju smo se borili sa draw call-ovima -- CPU problemom gde procesor ne moze dovoljno brzo da pripremi komande za GPU. Sada prelazimo na drugu stranu medalje: situacije gde GPU sam postaje usko grlo jer mora da obradi previse piksela. Overdraw i fill rate su dva usko povezana koncepta koja direktno odredjuju koliko vasa scena kosta GPU-u. U ovom poglavlju cete nauciti sta su, kako ih prepoznati, kako ih meriti u UE5, i -- najvaznije -- kako ih drzati pod kontrolom kroz prakticne strategije optimizacije.

Uvod: Zasto je ovo poglavlje neophodno posle poglavlja 42

U poglavlju 42 smo videli tipican scenario: scena sa 8.000+ draw call-ova gde se CPU gusi, a GPU jedva radi na 25% kapaciteta. Resenje je bilo smanjiti draw call-ove, i scena je proradila.

Ali postoji i suprotan scenario, koji je jednako cest i jednako destruktivan:

stat unit:
  Frame: 32.1 ms
  Game:   2.4 ms
  Draw:   4.1 ms    <-- CPU strana renderinga -- sasvim OK
  GPU:   28.7 ms    <-- GPU je ZAGUSLJEN

CPU ceka GPU! GPU ne stize da zavrsi posao.

Vidite razliku? Ovde CPU nema problem. Draw call-ovi su pod kontrolom. Ali GPU se gusi. Nesto ga tera da radi enormnu kolicinu posla, i ne stize da zavrsi u 16.67 ms koliko je potrebno za 60 FPS.

Jedan od najcescih uzroka ovog scenarija je overdraw -- situacija gde GPU crta iste piksele vise puta, troseci dragoceni fill rate na posao koji ce na kraju biti prepisan ili koji je nepotrebno skup.

Ako ste procitali poglavlje 09 (Rasterizacija), vec ste upoznati sa overdraw-om na teoretskom nivou. Ako ste procitali poglavlje 08 (GPU Arhitektura), razumete sta je fill rate i zasto je ogranicen. A iz poglavlja 35 (Niagara) znate da su cestice jedan od najgorih krivaca.

Ovo poglavlje spaja sve te delove u celovitu pricu i daje vam prakticne alate za borbu.

Krenimo.

43.1 Sta je Overdraw -- Detaljno Objasnjenje

Definicija

Overdraw je situacija kada se isti piksel na ekranu procesira kroz pixel shader vise od jedanput u istom frejmu.

To je to. Jednostavna definicija sa enormnim posledicama.

Svaki put kada GPU pokrene pixel shader za fragment koji pokriva odredjenu poziciju na ekranu, on trosi resurse: ALU cikluse (za izracunavanje materijala), memorijski bandwidth (za citanje tekstura), ROP throughput (za pisanje u framebuffer). Ako na istoj poziciji pokrene pixel shader tri puta -- jer tri razlicita trougla pokrivaju taj piksel -- potrosio je triput vise resursa nego sto bi potrosio da je obradio samo onaj fragment koji ce zaista biti vidljiv.

Vizuelna analogija

Zamislite da ste slikar koji slika zid. Trebate da ga farbate u crveno. Umesto da odmah nanesete crvenu boju, vi:

1. Prvo ofarbate ceo zid u belo (base coat)
2. Zatim ofarbate pola zida u plavo (jer mozda bude plav?)
3. Zatim ofarbate ceo zid u zeleno (promenili ste misljenje)
4. Na kraju ofarbate ceo zid u crveno (konacna odluka)

Na kraju vidite samo crvenu boju. Ali potrosili ste cetiri puta vise boje, cetiri puta vise vremena, cetiri puta vise energije -- na posao koji je mogao biti zavrsen u jednom potezu. To je overdraw faktor od 4.0x.

GPU radi tacno to: crta piksel, pa ga precrta, pa ga opet precrta. I svako od tih crtanja kosta.

Overdraw faktor

Overdraw se kvantifikuje kao faktor -- odnos ukupnog broja obradenih fragmenata prema ukupnom broju piksela na ekranu:

Overdraw faktor = Ukupan broj obradenih fragmenata / Ukupan broj piksela na ekranu

Nekoliko primera:

Primer 1: Minimalan overdraw
  Ekran: 1920 x 1080 = 2,073,600 piksela
  Obradeni fragmenti: 2,073,600 (tacno koliko i piksela)
  Overdraw = 2,073,600 / 2,073,600 = 1.0x
  
  Savrsen rezultat! Svaki piksel obraden tacno jednom.
  (U praksi gotovo nemoguci za netrivijalnu scenu.)

Primer 2: Tipicna igra
  Ekran: 1920 x 1080 = 2,073,600 piksela
  Obradeni fragmenti: 6,220,800
  Overdraw = 6,220,800 / 2,073,600 = 3.0x
  
  Svaki piksel je u proseku obraden 3 puta. Tipicno za modernu igru.

Primer 3: Problematicna scena
  Ekran: 1920 x 1080 = 2,073,600 piksela
  Obradeni fragmenti: 16,588,800
  Overdraw = 16,588,800 / 2,073,600 = 8.0x
  
  Svaki piksel obraden 8 puta u proseku! Definitivno treba optimizovati.

U praksi, overdraw od 2-3x je normalan za modernu igru. Overdraw od 4-5x zahteva paznju. Overdraw iznad 6x je gotovo sigurno problem koji treba resiti.

Vazno: Overdraw faktor je prosek -- neki pikseli mogu imati overdraw od 1x (npr. nebo koje se crta jednom), dok drugi mogu imati overdraw od 20x ili vise (npr. centar particle efekta). Prosek moze biti 3x a da ipak imate ozbiljan problem u specificnim delovima ekrana.

Zasto je overdraw vazan -- GPU perspektiva

Da bismo razumeli zasto je overdraw skup, podsetimo se sta GPU radi za svaki fragment (detaljno objasnjeno u poglavljima 08 i 09):

1. Rasterizer generise fragment iz trougla
2. Early-Z test (ako je dostupan) proverava da li je fragment vidljiv
3. Pixel shader se pokrece -- cita teksture, izracunava materijal, racuna osvetljenje
4. Late-Z test proverava dubinu (ako Early-Z nije bio moguc)
5. Blending kombinuje rezultat sa framebuffer-om
6. ROP pise konacnu boju u framebuffer

Svaki od ovih koraka trosi resurse. Koraci 3 i 6 su posebno skupi:

• Pixel shader je programabilni korak koji moze imati od 10 do 1.000+ instrukcija, i svaka instrukcija trosi ALU cikluse
• Texture fetch-ovi unutar pixel shader-a zahtevaju pristup VRAM-u koji je spor (stotine ciklusa latencije -- poglavlje 08, sekcija o latency hiding)
• ROP write zahteva memorijski bandwidth za pisanje u framebuffer

Kada imate overdraw od 3x, GPU mora da uradi triput vise svega ovoga. I to na ogranicenoj kolicini hardvera.

43.2 Uzroci Overdraw-a

Overdraw ne nastaje spontano -- postoje konkretni uzroci koje mozete identifikovati i adresirati. Hajde da ih prodjemo sistematski.

43.2.1 Preklapanje neprovidnih objekata (Opaque Overlap)

Najjednostavniji oblik overdraw-a: dva neprozirna objekta pokrivaju isti piksel.

Scenario: Kamera gleda na zid, a iza zida je drugi zid.

Bez sortiranja:
  1. GPU crta DALJI zid → pixel shader se pokrece → boja se pise u framebuffer
  2. GPU crta BLIZI zid → pixel shader se ponovo pokrece → 
     boja PREPISUJE prethodnu
  
  Piksel je obraden 2 puta. Rad za dalji zid je bio UZALUDAN.

Sa front-to-back sortiranjem + Early-Z:
  1. GPU crta BLIZI zid → pixel shader se pokrece → boja + dubina se pisu
  2. GPU pokusava dalji zid → Early-Z test odbacuje fragment! 
     Pixel shader se NE pokrece.
  
  Piksel je obraden samo 1 put. Efikasno!

UE5 automatski sortira opaque objekte front-to-back i koristi depth prepass, tako da je ovaj tip overdraw-a uglavnom dobro kontrolisan za neprozirnu geometriju. Ali nije eliminisan u potpunosti -- sortiranje je po objektu (ne po trouglu), pa unutar jednog mesh-a mogu postojati trouglovi koji se medjusobno preklapaju.

43.2.2 Transparentni objekti (Translucent Objects)

Ovo je najgori krivac za overdraw. Transparentni objekti imaju fundamentalne karakteristike koje ih cine izuzetno skupim:

1. Ne pisu u depth buffer -- jer su prozirni, moraju da dozvole da se vide objekti iza njih. To znaci da ne mogu da koriste Early-Z optimizaciju.

2. Moraju se crtati back-to-front -- redosled crtanja je bitan za korektan alpha blending. GPU mora da zna sta je "iza" transparentnog objekta da bi mogao da izracuna mesavinu boja. To znaci da ne mozemo koristiti front-to-back sortiranje za eliminaciju overdraw-a.

3. Cesto se znacajno preklapaju -- transparentni objekti su cesto slojevi (slojevi stakla, vodena povrsina sa cesticama, UI overlays), sto prirodno dovodi do visokog overdraw-a.

Primer: Staklo na zgradi

Scena: Zgrada sa 5 prozora, kamera gleda ka njima.
Svaki prozor je translucent materijal sa Fresnel efektom.

Za svaki piksel koji pokriva prozor:
  1. Pixel shader za zid iza prozora (opaque) -- 1x
  2. Pixel shader za staklo prozora (translucent) -- 1x
  = Overdraw 2x za piksele prozora

Ovo zvuci razumno. Ali sta ako imate 3 sloja stakla (duplo staklo + unutrasnji zid)?
  1. Zid iza (opaque) -- 1x
  2. Unutrasnje staklo (translucent) -- 1x
  3. Spoljasnye staklo (translucent) -- 1x
  4. Reflektivni overlay (translucent) -- 1x
  = Overdraw 4x samo za prozorski region!

43.2.3 Particle sistemi (Cestice)

Particle sistemi su specijalan slucaj transparentnih objekata, i zasluzuju posebnu paznju jer mogu da generisu ekstremne nivoe overdraw-a. Ovo je detaljno pokriveno u poglavlju 35 (Niagara), ali hajde da sumiramo kljucne tacke.

Tipican particle efekat (npr. dim od vatre) se sastoji od desetina ili stotina poluprozirnih sprite-ova (billboard quad-ova) koji se medjusobno preklapaju:

Dim od vatre -- pogled sa strane:

      ┌──────────┐
     ┌┤──────────┤┐
    ┌┤┤──────────┤┤┐
   ┌┤┤┤──────────┤┤┤┐
  ┌┤┤┤┤──────────┤┤┤┤┐
  │││││  CENTAR  │││││   ← U centru se preklapaju SVI slojevi!
  └┤┤┤┤──────────┤┤┤┤┘
   └┤┤┤──────────┤┤┤┘
    └┤┤──────────┤┤┘
     └┤──────────┤┘
      └──────────┘
  
  Svaki pravougaonik je jedan sprite/particle.
  U centru: overdraw = broj particla koji se preklapaju
  Sa 30 particla dima: overdraw 20-30x u centru!

Zasto je ovo posebno problematicno:

• Svaki particle je translucent -- nema Early-Z
• Svaki particle pokriva potencijalno veliki deo ekrana (veliki sprite-ovi)
• Particle-i se po prirodi masovno preklapaju (to je kako stvaraju gustinu efekta)
• Svaki particle zahteva blend operaciju sa framebuffer-om

Kvantifikacija:
  30 particla dima
  Svaki pokriva 200x200 piksela na ekranu
  Prosecno preklapanje: ~15 particla na istom pikselu
  
  Ukupno fragmenata za particle sistem:
    30 × 200 × 200 = 1,200,000 fragmenata
    
  Za 1080p ekran (2,073,600 piksela), samo ovaj jedan efekat
  doprinosi overdraw-u od:
    1,200,000 / 2,073,600 = ~0.58x DODATNOG overdraw-a na prosecnom nivou
    
  Ali u centru efekta, lokalni overdraw je 15-30x!

I to je samo jedan particle efekat. Zamislite scenu bitke sa 20 aktivnih efekata (eksplozije, dim, iskre, magija) -- fill rate zahtevi mogu eksplodirati.

43.2.4 Vegetacija (Foliage)

Vegetacija je drugi veliki krivac, i to iz specificnog razloga koji se razlikuje od transparentnih objekata.

Listovi drveca se u igrama obicno realizuju kao quad-ovi sa alpha mask-om -- cetvorougaoni sa teksturom lista i alpha kanalom koji definise oblik lista. Sve sto je van oblika lista se odbacuje (discard). Ovi materijali koriste Masked blend mode u UE5.

Problem je sledeci:

1. Masked materijali ne mogu da koriste Early-Z (barem ne u svom standardnom obliku). GPU ne zna unapred koji pikseli ce biti discard-ovani dok ne pokrene pixel shader i ne procita alpha teksturu. To znaci da se pixel shader pokrece za svaki fragment, ukljucujuci i one koji ce biti odbaceni.

2. Listovi se masovno preklapaju. Pogledajte krunu drveta -- stotine listova jedan preko drugog. Svaki list je quad koji pokriva i piksele van oblika lista, ali pixel shader se pokrece za ceo quad.

3. Oblast van maske je "bacen" rad. Quad lista pokriva, recimo, 100x100 piksela. Sam list zauzima mozda 40% tog prostora. Pixel shader se pokrece za svih 10.000 piksela, ali 6.000 ce biti discard-ovano. Tih 6.000 pokretanja pixel shader-a je potpuno uzaludan rad.

Anatomija jednog lista:

  ┌─────────────────┐
  │   ░░░░░░░░░     │  ░ = pikseli LISTA (vidljivi)
  │  ░░░░░░░░░░░    │  · = pikseli QUAD-a van maske (discarded)
  │ ░░░░░░░░░░░░░   │
  │░░░░░░░░░░░░░░░  │  Quad pokriva celu povrsinu.
  │ ░░░░░░░░░░░░░   │  Pixel shader se pokrece za SVE piksele.
  │  ░░░░░░░░░░░    │  60% piksela se discard-uje -- uzaludan rad!
  │   ░░░░░░░░░     │
  │    ░░░░░░░      │
  └─────────────────┘
  
  GPU procesira 10.000 fragmenata, ali samo ~4.000 zavrsi na ekranu.

Sada zamislite krunu drveta sa 200 takvih listova koji se medjusobno preklapaju:

Kruna drveta -- overdraw analiza:

  Prosecno preklapanje: 8 listova na istom pikselu
  Svaki list: pixel shader se pokrece (ukljucujuci discard)
  
  Za region od 500x500 piksela (oblast krosnje na ekranu):
    500 × 500 × 8 = 2,000,000 pixel shader poziva
    
  Ali stvarno vidljivih piksela: 500 × 500 = 250,000
  
  Efektivni overdraw: 8.0x!

Ovo je razlog zasto je vegetacija (posebno drvece sa gustim krosnjama) jedan od najskupljih elemenata u igrama u smislu pixel shader rada. LOD sistemi za vegetaciju su kriticni -- na daljini, drvo moze da se zameni billboard-om (jedan quad umesto stotina listova), drasticno smanjujuci overdraw.

43.2.5 Preklapajuca geometrija (Overlapping Geometry)

Cest problem u praksi: objekti koji su postavljeni tako da se geometrija fizicki preklapa.

Primeri preklapajuce geometrije:
  
  1. Dva zida postavljena na istoj poziciji (greska u level dizajnu)
     → Overdraw 2x na celoj povrsini zida
     
  2. Pod koji prolazi kroz zid (neuredan BSP)
     → Overdraw na liniji kontakta
     
  3. Dekorativni objekat koji je "uguran" u zid (namerno, za vizuelni efekat)
     → Overdraw na preklapajucem regionu
     
  4. Decali (dekalji) -- teksture koje se projketuju na povrsine
     → Svaki dekal dodaje 1x overdraw na povrsinu koju pokriva
     → 10 dekala na istom zidu = 10x DODATNOG overdraw-a!

Decali zasluzuju posebnu napomenu: u igrama je uobicajeno da se tokom gameplay-a generise mnogo dekala (rupe od metaka, mrlje krvi, tragovi pneumatika). Ako ne ogranicite broj dekala na istoj povrsini, overdraw moze da eskalira brzo.

43.2.6 Post-processing efekti

Post-processing efekti (bloom, depth of field, motion blur, tone mapping) su fullscreen pass-ovi koji pokrivaju svaki piksel na ekranu. Svaki fullscreen pass dodaje overdraw od 1.0x. Ako imate 5 post-processing pass-ova, to je dodatnih 5x overdraw-a na nivou celog ekrana.

Post-processing lanac u UE5 (tipican):

  1. Bloom                  → fullscreen pass  (+1x)
  2. Ambient Occlusion      → fullscreen pass  (+1x)
  3. Depth of Field         → fullscreen pass  (+1x)
  4. Motion Blur            → fullscreen pass  (+1x)
  5. Tone Mapping           → fullscreen pass  (+1x)
  6. Anti-aliasing (TSR)    → fullscreen pass  (+1x)
  
  = 6 dodatnih fullscreen pass-ova

Medjutim, post-processing overdraw je uglavnom neizbezen i relativno jeftin (shaderi su obicno jednostavni). Fokus optimizacije treba da bude na scene overdraw-u -- geometriji, particlima i transparentnim objektima.

43.3 Quad Overdraw -- Specijalan Slucaj za Male Trouglove

Overdraw koji smo do sada opisivali nastaje kada se razliciti objekti preklapaju na istom pikselu. Ali postoji i drugaciji tip "overdraw-a" koji nastaje zbog same arhitekture GPU-a -- i on se zove quad overdraw.

Kako GPU procesira piksele -- podsetnik iz poglavlja 09

Kao sto smo detaljno objasnili u poglavlju 09 (sekcija 9.11), GPU ne procesira piksele pojedinacno. Umesto toga, procesira ih u grupama od 2x2 piksela koje se zovu quad-ovi. Ovo je fundamentalna hardverska odluka, i postoji dobar razlog za nju.

Zasto 2x2 grupe? Zato sto su pixel shader-u potrebni derivativi (ddx, ddy) za izracunavanje MIP nivoa tekstura. Da bi GPU znao koliko se UV koordinate menjaju izmedju susednih piksela (i time odredio koji MIP nivo da koristi), mora da procesira susedne piksele istovremeno. Najmanji blok koji to omogucava je 2x2.

Quad (2x2 pixel group):

  ┌────┬────┐
  │ P0 │ P1 │    GPU procesira sva 4 piksela ISTOVREMENO
  ├────┼────┤    da bi mogao da izracuna ddx i ddy
  │ P2 │ P3 │    za texture MIP level selekciju
  └────┴────┘
  
  ddx = P1 - P0 (horizontalna promena)
  ddy = P2 - P0 (vertikalna promena)

Problem: Helper Lanes

Sta se desava kada trougao pokriva samo deo quad-a? Na primer, mali trougao koji pokriva samo 1 piksel u quad-u od 4?

Mali trougao koji pokriva samo jedan piksel u quad-u:

  ┌────┬────┐
  │ ██ │    │    ██ = piksel koji trougao zapravo pokriva
  ├────┼────┤        = "helper lane" -- GPU ga procesira
  │    │    │         ali rezultat se ODBACUJE
  └────┴────┘
  
  GPU mora da pokrene pixel shader za SVA 4 piksela
  ali samo 1 od 4 ce zapravo biti zapisan u framebuffer!
  
  Quad utilization: 1/4 = 25%
  Efektivni "overdraw": 4x za ovaj quad!

Ova tri "prazna" piksela se zovu helper lanes (ili helper pixels). GPU pokrece pixel shader za njih jer mu trebaju za izracunavanje derivativa, ali njihov rezultat se nikada ne pise u framebuffer. To je cist gubitak -- rad koji ne proizvodi nikakav vidljiv rezultat.

Kada je quad overdraw problem?

Quad overdraw postaje ozbiljan problem kada imate mnogo malih trouglova -- trouglova koji su manji od 2x2 piksela na ekranu, ili koji su toliko tanki/izduzeni da pokrivaju samo mali deo svakog quad-a kroz koji prolaze.

Scenariji sa losim quad utilization-om:

1. SUB-PIXEL TROUGLOVI (manji od jednog piksela):
   Trougao pokriva 1 piksel → GPU aktivira ceo quad (4 piksela)
   Utilization: 25%  |  3/4 rada je baceno!

2. TANKI/IZDUZENI TROUGLOVI:
   Dugacak, uzak trougao (npr. ivica mesh-a):
   
   ┌──┬──┬──┬──┬──┬──┬──┬──┐
   │██│  │██│  │██│  │██│  │   Trougao pokriva 1 piksel po quad-u
   ├──┼──┼──┼──┼──┼──┼──┼──┤   ali "dodiruje" 4 quad-a
   │  │  │  │  │  │  │  │  │   
   └──┴──┴──┴──┴──┴──┴──┴──┘
   
   4 piksela pokrivena, ali 16 piksela procesiranih (4 quad-a × 4 piksela)
   Utilization: 4/16 = 25%

3. MNOGO SITNIH TROUGLOVA NA DALJINU:
   Mesh sa 100.000 trouglova na daljini od 100m.
   Mnogi trouglovi su manji od 1 piksela.
   Svaki mali trougao troši ceo quad.
   
   Ako je 50.000 trouglova sub-pixel:
     50.000 quad-ova × 4 piksela = 200.000 pixel shader poziva
     Ali samo 50.000 piksela je zaista vidljivo
     Quad overhead: 4x na tim trouglovima!

Veza sa LOD-om i Nanite-om

Ovo je jedan od kljucnih razloga zasto su LOD (Level of Detail) sistemi vazni (pored smanjenja vertex processing troska). Na daljini, mesh sa mnogo malih trouglova postaje quad-inefficient. Jednostavniji LOD nivo sa manje, vecih trouglova je efikasniji za pixel shader jer svaki trougao pokriva vise piksela po quad-u.

Nanite (poglavlje 30) resava ovaj problem na fundamentalno drugaciji nacin. Umesto da crta trouglove kroz standardni rasterizer (koji koristi quad-ove), Nanite koristi software rasterizaciju za male trouglove i visibility buffer pristup:

1. Za trouglove koji su manji od ~32 piksela, Nanite koristi software rasterizer koji ne pati od quad overhead-a -- procesira svaki piksel pojedinacno, bez helper lane-ova
2. Za vece trouglove, koristi standardni hardware rasterizer (koji je efikasniji za vece trouglove)
3. Nakon rasterizacije, Nanite pokrece materijal evaluaciju tacno jednom po pikselu kroz visibility buffer -- potpuno eliminisijuci overdraw za opaque materijale

Ovo je jedan od razloga zasto su Nanite scene dramaticno efikasnije -- nema ni klasicnog overdraw-a (jer visibility buffer garantuje jedan pixel shader poziv po pikselu), ni quad overdraw-a (jer software rasterizer obradjuje piksele pojedinacno).

Kako meriti quad overdraw u UE5

UE5 ima ugradjeni Quad Overdraw vizualizacioni mod:

1. U editoru: View Mode > Optimization Viewmodes > Quad Overdraw
2. Ili u konzoli: viewmode QuadOverdraw

Ovaj mod prikazuje piksele obojene prema broju puta koliko je svaki quad procesiran:

• Tamno zeleno/crno: Niska quad redundancija (efikasno)
• Svetlo zeleno/zuto: Umerena redundancija
• Narandzasto/crveno: Visoka redundancija -- previise malih trouglova

Sta traziti u Quad Overdraw vizualizaciji:

  ┌─────────────────────────────────────────────┐
  │                                             │
  │    ▓▓▓▓▓▓▓▓▓▓                              │
  │   ▓▓▓▓▓▓▓▓▓▓▓▓    <-- Daleko drvo: CRVENO  │
  │   ▓▓▓▓▓▓▓▓▓▓▓▓         (mnogo malih         │
  │    ▓▓▓▓▓▓▓▓▓▓           trouglova)          │
  │       ████                                  │
  │       ████                                  │
  │                                             │
  │  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  │
  │  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  │
  │  <-- Pod: TAMNO ZELENO (veliki trouglovi,   │
  │       dobra quad utilizacija)               │
  └─────────────────────────────────────────────┘

Ako vidite crvene oblasti, to znaci da imate mesh-eve sa previse trouglova za tu udaljenost. Resenja:

• LOD: Koristite jednostavnije modele na daljini
• Nanite: Konvertujte mesh u Nanite koji automatski upravlja nivoom detalja
• Mesh optimization: Smanjite broj trouglova u modelima gde je to vizuelno prihvatljivo

43.4 Fill Rate -- Sta Je i Zasto Je Vazan

Definicija

Fill rate je brzina kojom GPU moze da "popuni" piksele na ekranu -- koliko piksela po sekundi moze da procesira kroz pixel shader i zapise u framebuffer.

Termin "fill rate" dolazi iz ranih dana 3D grafike kada je GPU bukvalno "punio" (filled) piksele bojom. Danas je pixel shader neuporedivo kompleksniji od prostog "punjenja bojom", ali termin je ostao.

Dva tipa fill rate-a

Postoje dva razlicita merenja fill rate-a, i vazno je razumeti razliku (ovo je detaljno objasnjeno u poglavlju 08, sekcija o fill rate-u):

1. Pixel fill rate (teoretski)

Broj piksela koje ROP (Render Output Unit) moze da zapise u framebuffer po sekundi. Ovo je cisto hardversko ogranicenje.

Pixel fill rate = Broj ROP-ova × GPU clock speed

Primer (RTX 4080):
  112 ROP-ova × 2.505 GHz = ~280 Gpixels/s (teoretski)

2. Texture fill rate

Broj texela (texture pixels) koje TMU (Texture Mapping Unit) moze da procita po sekundi.

Texture fill rate = Broj TMU-ova × GPU clock speed

Primer (RTX 4080):
  304 TMU-ova × 2.505 GHz = ~761 Gtexels/s (teoretski)

Fill rate u praksi -- sta zapravo limitira

U praksi, efektivni fill rate je mnogo manji od teoretskog jer zavisi od toga sta pixel shader zapravo radi. Fill rate je ogranicen onim sto je najsporije od sledeceg:

1. Pixel shader throughput (ALU) -- koliko brzo SM-ovi (Streaming Multiprocessors) mogu da izvrse pixel shader. Sto je shader kompleksniji (vise instrukcija), to je throughput manji.

2. Texture throughput -- koliko brzo TMU-ovi mogu da citaju teksture. Svaki Sample() poziv u shader-u trosi TMU bandwidth. Materijal sa 8 tekstura trosi 8x vise TMU bandwidth-a od materijala sa jednom teksturom.

3. ROP throughput -- koliko brzo ROP-ovi mogu da obave depth/stencil testove i zapisu u framebuffer. Blending (za transparentne objekte) je skuplji od prostog write-a.

4. Memory bandwidth -- koliko brzo se podaci mogu citati iz i pisati u VRAM. Ovo je cesto primarni bottleneck jer texture fetch-ovi i framebuffer write-ovi zahtevaju enormne kolicine bandwidth-a.

Fill rate bottleneck analiza:

Scena na 4K (3840 x 2160 = 8,294,400 piksela), target 60 FPS:

  Piksela po frejmu: 8,294,400
  Sa overdraw 3x: 24,883,200 fragmenata po frejmu
  
  Pixel shader: 200 instrukcija (kompleksan PBR materijal)
  Teksture po pikselu: 6 (diffuse, normal, roughness, metallic, AO, emissive)
  
  Potreban ALU throughput:
    24,883,200 × 200 = ~5 G instrukcija po frejmu
    × 60 FPS = 300 G instrukcija/s
    
  Potreban texture throughput:
    24,883,200 × 6 = ~149 M texture fetch-ova po frejmu
    × 60 FPS = ~8.9 G texels/s
    (sa trilinear filtering: × 8 = ~71.6 G texels/s)
    
  Potreban ROP throughput:
    24,883,200 × 60 = ~1.49 G pixels/s
    (plus depth buffer reads/writes)
    
  Potreban memory bandwidth:
    Framebuffer write: 8,294,400 × 16 bytes (RGBA16F) × 60 = ~7.6 GB/s
    Depth buffer: 8,294,400 × 4 bytes × 60 = ~1.9 GB/s
    Texture reads: enormna kolicina (zavisi od cache hit rate-a)

Vidite kako se brojke brzo gomilaju. I to je samo za jedan rendering pass. UE5 renderuje scenu u vise pass-ova (depth prepass, G-buffer, lighting, refleksije, post-processing...).

Overdraw direktno multipluje fill rate zahteve

Ovo je kljucna veza izmedju overdraw-a i fill rate-a: svaki dodatni nivo overdraw-a zahteva proporcionalno vise fill rate-a. Ako vasa scena zahteva fill rate od X pri overdraw-u 1.0, sa overdraw-om 3.0 zahteva fill rate od 3X.

Fill rate zahtevi pri razlicitom overdraw-u:

  Ekran: 4K, Target: 60 FPS
  Pixel shader: 200 instrukcija
  
  Overdraw 1.0x: ~100 G instrukcija/s   → GPU je u redu
  Overdraw 2.0x: ~200 G instrukcija/s   → GPU se pomalo napreze
  Overdraw 3.0x: ~300 G instrukcija/s   → GPU blizu limita
  Overdraw 5.0x: ~500 G instrukcija/s   → GPU ne stize!
  Overdraw 8.0x: ~800 G instrukcija/s   → Katastrofa. 15 FPS.

43.5 Fill Rate Bottleneck -- Kako ga Prepoznati

Simptomi fill rate bottleneck-a

Fill rate bottleneck se manifestuje na sledeci nacin:

1. GPU je na visokom opterecenju -- u profajleru, GPU vreme je dominantno (stat unit pokazuje da je GPU vreme vece od Draw vremena)
2. FPS se dramaticno poboljsava kada smanjite rezoluciju -- ovo je kljucni test (vise o ovome ispod)
3. Shader Complexity vizualizacija pokazuje crvene/bele oblasti -- znaci da imate skupe pixel shader-e ili visok overdraw
4. Problem se pogorsava na visim rezolucijama -- 1080p radi ok, ali 4K je neigriva

Kljucni test: Smanjite rezoluciju

Ovo je najjednostavniji i najpouzdaniji test za identifikaciju fill rate bottleneck-a. Ideja je prosta: ako smanjite rezoluciju renderovanja (tj. broj piksela koje GPU mora da obradi), a FPS se dramaticno poboljsa -- tada ste fill rate bound.

Test procedura:

1. Pokrenite igru u normalnoj rezoluciji (npr. 1920x1080)
   → Izmerite FPS: 28 FPS

2. Smanjite rezoluciju na pola u svakoj dimenziji (960x540)
   Komanda u UE5 konzoli: r.ScreenPercentage 50
   → Izmerite FPS: 95 FPS

3. Analiza:
   Rezolucija smanjena 4x (polovina u obe dimenzije = 1/4 piksela)
   FPS porastao ~3.4x (sa 28 na 95)
   
   ZAKLJUCAK: Jasno fill rate bound!
   (Smanjenje broja piksela je direktno poboljsalo performanse)

Zasto ovo radi? Zato sto fill rate bottleneck znaci da GPU ne moze da procesira sve piksele na vreme. Kada smanjite rezoluciju, smanjujete broj piksela -- a samim tim i kolicinu posla za pixel shader, texture fetch-ove, ROP write-ove i memory bandwidth. Ako je to bilo usko grlo, FPS skoci.

Obrnuto: Ako smanjite rezoluciju a FPS se jedva promeni, problem nije fill rate. Mozda je vertex processing (previse trouglova), ili CPU bound (previse draw call-ova ili gameplay logike), ili nesto sasvim drugo.

Razliciti ishodi testa rezolucije:

Scenario A: Fill rate bound
  1080p: 28 FPS  →  540p: 90 FPS  →  FILL RATE BOTTLENECK
  (4x manje piksela → ~3.2x vise FPS-a)

Scenario B: Vertex bound
  1080p: 28 FPS  →  540p: 31 FPS  →  NIJE fill rate
  (4x manje piksela → skoro nikakva promena)
  Uzrok je verovatno previse trouglova (vertex processing)

Scenario C: CPU bound
  1080p: 28 FPS  →  540p: 29 FPS  →  NIJE fill rate
  (4x manje piksela → nikakva promena)
  Uzrok je verovatno CPU (draw calls, gameplay logika, fizika)

Konzolne komande za dijagnostiku u UE5

UE5 nudi niz konzolnih komandi za detaljnu dijagnostiku:

r.ScreenPercentage 50       -- Smanjuje rezoluciju renderovanja na 50%
                               (4x manje piksela)
                               Koristite za fill rate test

r.ScreenPercentage 100      -- Vraca na normalnu rezoluciju

stat unit                   -- Prikazuje Frame/Game/Draw/GPU vreme
                               Ako je GPU >> Draw, GPU je bottleneck

stat gpu                    -- Detaljno GPU vreme po rendering pass-u
                               Pokazuje koji pass trosi najvise vremena

stat scenerendering         -- Prikazuje broj draw call-ova, trouglova,
                               i vremena za razlicite rendering faze

ProfileGPU                  -- Jednofrejmski GPU profiling snapshot
                               (Alt+Shift+, precica)
                               Detaljno razbijanje GPU vremena

Interpretacija stat gpu rezultata

stat gpu komanda vam daje razbijanje GPU vremena po rendering pass-u. Ovo je izuzetno korisno za identifikaciju gde tacno se fill rate trosi:

stat gpu primer izlaza:

  PrePass (depth):        0.8 ms    -- Depth prepass
  BasePass:               8.2 ms    -- Glavni pass za opaque objekte
  Translucency:           6.1 ms    -- Transparentni objekti ← PODOZRIVO!
  PostProcessing:         2.4 ms    -- Post-processing efekti
  Shadows:                3.1 ms    -- Shadow mape
  Reflections:            1.5 ms    -- Screen-space refleksije
  ...
  TOTAL:                 24.3 ms

Analiza:
  "Translucency" trosi 6.1 ms -- to je ~25% ukupnog GPU vremena!
  Za transparentne objekte koji su obicno mali deo scene, ovo je previse.
  Verovatni uzrok: prevelik overdraw od particle sistema i/ili
  transparentnih materijala.

Shader Complexity vizualizacija

Shader Complexity vizualizacioni mod u UE5 je vizuelni alat koji prikazuje "trosak" svakog piksela na ekranu. Pristupa mu se na sledeci nacin:

1. U editoru: View Mode > Optimization Viewmodes > Shader Complexity
2. Ili u konzoli: viewmode ShaderComplexity

Shader Complexity boja:

  ZELENO        → Niska slozenost / nizak overdraw
                  Pixel shader je jednostavan i nema mnogo preklapanja.
                  
  ZUTO          → Srednji nivo
                  Moderan shader ili umereno preklapanje.
                  
  NARANDZASTO   → Visoka slozenost
                  Skup shader ili znacajno preklapanje. Treba paznja.
                  
  CRVENO        → Vrlo visoka slozenost
                  Veoma skup shader i/ili visok overdraw. 
                  Treba optimizovati.
                  
  BELO / PINK   → Kritican nivo
                  Izuzetno skup region. Gotovo sigurno fill rate
                  bottleneck. Hitno optimizovati.

Vazna napomena: Shader Complexity mod prikazuje kombinaciju slozenosti shader-a i overdraw-a. Piksel moze biti crven jer je shader kompleksan (mnogo instrukcija) ili zato sto je pixel shader pokrenut mnogo puta na tom pikselu (overdraw) ili kombinacija oba. Da biste razlikovali ova dva uzroka, koristite i Quad Overdraw vizualizacioni mod koji prikazuje samo overdraw bez shader slozenosti.

Dijagnosticki workflow:

1. Otvorite Shader Complexity
   → Pronadjite CRVENE/BELE oblasti

2. Otvorite Quad Overdraw 
   → Proverite da li su iste oblasti crvene
   
3. Interpretacija:
   - Crveno u OBA moda: Problem je OVERDRAW
   - Crveno u Shader Complexity, zeleno u Quad Overdraw: 
     Problem je SHADER KOMPLEKSNOST (materijal je previse skup)
   - Zeleno u Shader Complexity, crveno u Quad Overdraw:
     Problem je QUAD UTILIZATION (previse malih trouglova)

43.6 Depth Prepass -- Prva Linija Odbrane Protiv Overdraw-a

Sta je depth prepass?

Depth prepass (ili Z-prepass) je rendering tehnika gde se pre glavnog rendering pass-a (base pass) napravi dodatni pass koji samo popunjava depth buffer -- bez pokretanja punog pixel shader-a, bez citanja tekstura, bez izracunavanja materijala.

Ideja je sledeca: ako depth buffer vec sadrzi dubine svih vidljivih objekata pre nego sto pocne glavni pass, onda tokom glavnog pass-a Early-Z test moze da odbaci sve nevidljive fragmente pre nego sto pixel shader uopste pocne da radi. Rezultat: samo vidljivi pikseli prolaze kroz skupi pixel shader.

Rendering BEZ depth prepass-a:

  Base Pass:
    Objekat A (dalji):  Pixel shader se pokrece → Pise u framebuffer
    Objekat B (blizi):  Pixel shader se pokrece → PREPISUJE objekat A
    
    Objekat A je obraden UZALUD. Pixel shader je pokrenuo
    citanje tekstura, izracunavanje osvetljenja -- sve za nista.

Rendering SA depth prepass-om:

  Depth Prepass:
    Objekat A: Samo dubina → pise u depth buffer (BRZO! Nema pixel shader-a)
    Objekat B: Samo dubina → pise u depth buffer (BRZO!)
    
  Depth buffer sada ima korektne dubine za celu scenu.
    
  Base Pass:
    Objekat A: Early-Z test → FAIL! (Objekat B je blizi) → SKIP!
    Objekat B: Early-Z test → PASS → Pixel shader se pokrece → OK
    
    Objekat A NIKADA ne pokrece pixel shader!
    Ustedeli smo sav rad za nevidljive piksele.

Depth prepass u UE5

UE5 koristi depth prepass po default-u za opaque objekte. Ovo je podrazumevano ponasanje i ne morate ga eksplicitno ukljucivati. Engine automatski:

1. Renderuje depth prepass za opaque geometriju
2. Koristi rezultujuci depth buffer za Early-Z test u base pass-u
3. Rezultat: minimalan overdraw za opaque objekte

Mozete proveriti da li je depth prepass aktivan koristeci stat gpu -- trebalo bi da vidite "PrePass" sa nekim vremenskim troskom. Ako je 0 ili ne postoji, depth prepass mozda nije aktivan (sto je neuobicajeno u podrazumevanim podesavanjima).

stat gpu sa depth prepass-om:

  PrePass (depth):  0.8 ms   ← Ovo je depth prepass. Troši neko vreme,
                                ali ustedi mnogo vise u base pass-u.
  BasePass:         5.2 ms   ← Bi bio 8-12 ms BEZ depth prepass-a!

Cena depth prepass-a

Depth prepass nije besplatan. On zahteva:

• Duplo prolazenje geometrije kroz vertex shader -- svi trouglovi se procesiraju dva puta (jednom u prepass-u, jednom u base pass-u)
• Duplo rasterizovanje -- svaki trougao se rasterizuje dva puta
• Dodatni bandwidth za depth buffer -- pisanje i citanje depth buffer-a

Ovo se isplati kada je pixel shader dovoljno skup i kada ima dovoljno overdraw-a. Za jednostavne scene sa malo overdraw-a, depth prepass moze da bude kontraprodutivan (overhead prepass-a je veci od ustede od smanjenog overdraw-a).

Kada se depth prepass isplati:

  Cena prepass-a: C_prepass (vertex processing + rasterizacija + depth write)
  Usteda u base pass-u: S_basepass (izbegnuti pixel shader pozivi)
  
  Isplati se ako: S_basepass > C_prepass
  
  Faktori koji cine prepass isplativim:
  ✓ Skup pixel shader (mnogo tekstura, kompleksni materijali)
  ✓ Visok overdraw (mnogo preklapajuce geometrije)
  ✓ Visoka rezolucija (vise piksela = veca usteda)
  
  Faktori koji cine prepass neisplativim:
  ✗ Jednostavan pixel shader (jeftino da se pokrene vise puta)
  ✗ Malo overdraw-a (malo preklapanja, malo sto bi se ustedelo)
  ✗ Niska rezolucija (manje piksela = manja usteda)
  ✗ Vertex-heavy scena (vertex processing je vec bottleneck)

Ogranicenja depth prepass-a

Depth prepass pomaze samo za opaque objekte. Za transparentne objekte i masked materijale (koji su glavni uzrocnici overdraw-a!), depth prepass ima ogranicenja:

1. Translucent objekti: Ne pisu u depth buffer uopste. Depth prepass ih ne moze ukljuciti.

2. Masked materijali: Depth prepass za masked materijale zahteva pokretanje pixel shader-a cak i u prepass-u (jer mora da procita alpha teksturu da bi odlucio da li da discard-uje fragment). Ovo smanjuje korist prepass-a jer se pixel shader svejedno pokrece dva puta.

3. Animirani mesh-evi: Mesh-evi sa vertex animacijom (skeletal mesh-evi) zahtevaju dodatni posao u prepass-u jer vertex shader mora da izracuna animiranu poziciju.

Depth prepass efikasnost po tipu materijala:

  Opaque materijal:     ████████████  (velika korist -- full Early-Z)
  Masked materijal:     ████████░░░░  (umerena korist -- pixel shader 
                                       radi u prepass-u)
  Translucent materijal: ░░░░░░░░░░░░  (nema koristi -- ne ucestvuje 
                                         u depth prepass-u)

43.7 Strategije za Smanjenje Overdraw-a

Sada dolazimo do prakticnog dela -- konkretne strategije koje mozete primeniti u vasim UE5 projektima za smanjenje overdraw-a.

43.7.1 Strategija 1: Smanjite broj i velicinu transparentnih objekata

Ovo je najdirektnija strategija. Transparentni objekti su najveci uzrocnik overdraw-a, pa ih smanjite gde god mozete.

Konkretne akcije:

1. Preispitajte da li objekat mora da bude transparentan. Mnogi objekti koji su translucent mogu da izgledaju dovoljno dobro sa Masked blend mode-om ili cak sa Opaque materijalom uz dithered transparency.

2. Koristite Masked umesto Translucent gde je vizuelno prihvatljivo. Masked materijali koriste alpha test (discard) umesto alpha blending. Prednosti:

   • Pisu u depth buffer → mogu koristiti Early-Z (sa nekim ogranicenjima)
   • Ne zahtevaju back-to-front sortiranje
   • Manje overdraw-a jer se fragmenti kompletno odbacuju ili prihvataju

3. Dithered opacity kao alternativa. UE5 podrzava dithered opacity za opaque materijale -- umesto prave transparentnosti, koristi pattern od piksela koji su nacrtani ili preskoceni. Na daljini, ljudsko oko percipira ovo kao poluprozirnost. Prednost: materijal ostaje opaque, pise u depth buffer, koristi Early-Z.

Poredjenje blend modova po overdraw trosku:

  Opaque:        Nema overdraw-a (Early-Z eliminise nevidljive piksele)
  Masked:        Minimalan overdraw (discard eliminise, ali quad 
                 se procesira ceo)
  Dithered:      Nema overdraw-a (opaque sa vizuelnim "trikom")
  Translucent:   PUNI overdraw (nema Early-Z, back-to-front sort, blending)
  Additive:      PUNI overdraw (slicno translucent, ali bez sort zahteva)

43.7.2 Strategija 2: Optimizujte particle sisteme

Particle sistemi su najcesci uzrok fill rate problema. Evo konkretnih tehnika iz poglavlja 35 (Niagara), sumiraniranih i prosirenih:

A. Smanjite velicinu particla

Veci particle = vise piksela pokrivenih = vise fill rate-a potrosenog. Umesto 10 ogromnih particle-a dima, koristite 30 manjih. Vizuelno moze izgledati cak i bolje (detaljnije), a fill rate trosak je dramaticno manji.

Primer: Dim od vatre

Opcija A: 10 velikih particla
  Svaki pokriva 300x300 piksela = 90,000 piksela po particle-u
  Ukupno: 10 × 90,000 = 900,000 piksela
  Sa prosecnim overdraw-om ~5x medjusobno: 
    ~4,500,000 fragment operacija

Opcija B: 30 manjih particla
  Svaki pokriva 90x90 piksela = 8,100 piksela po particle-u
  Ukupno: 30 × 8,100 = 243,000 piksela
  Sa prosecnim overdraw-om ~3x (manje preklapanja):
    ~729,000 fragment operacija

Opcija B trosi ~6x manje fill rate-a!
I vizuelno moze biti bolja jer je detaljnija.

B. Smanjite broj particla na daljini

Particle efekat koji je daleko od kamere zauzima manje piksela na ekranu. Ali ako i dalje emituje 100 particla, svi ti particli se renderuju cak i ako pokrivaju ukupno samo 50x50 piksela. Svaki particle i dalje ima draw overhead.

Koristite Niagara Scalability sistem da smanjite spawn rate na daljini:

Niagara Scalability podesavanja za Smoke emitter:

  Distance 0-20m:     Spawn Rate = 30/s,   Max Particles = 100
  Distance 20-50m:    Spawn Rate = 15/s,   Max Particles = 50
  Distance 50-100m:   Spawn Rate = 5/s,    Max Particles = 20
  Distance 100m+:     Spawn Rate = 0/s     (efekat se ne vidi)

C. Koristite Sub UV / Flipbook animacije umesto mnogo particla

Umesto 50 overlapping particla za simuliranje kompleksnog efekta, koristite jedan quad sa flipbook animacijom (niz frejmova na jednoj teksturi). Ovo smanjuje overdraw na 1x za taj efekat.

D. Koristite Additive blending umesto Translucent gde je moguce

Additive blending (Source + Destination) ne zahteva back-to-front sortiranje jer je operacija komutativna (redosled ne menja rezultat). Ovo ne smanjuje sam overdraw, ali eliminise sort overhead i moze smanjiti artefakte.

Vizuelno, additive blending izgleda drugacije od translucent blending-a -- boje se "dodaju" umesto da se mesaju, sto dovodi do "glow" efekta. Za vatru, iskre i magiju, ovo je cesto upravo ono sto zelite. Za dim, additive nece raditi (dim treba da zaklanja pozadinu, ne da svetli).

E. Opacity masking za particle-e

Gde je vizuelno prihvatljivo, koristite Masked blend mode za particle-e umesto Translucent. Ovo eliminise overdraw za te particle-e (fragmenti su ili potpuno vidljivi ili potpuno odbaceni). Gubitak: ostar "cutoff" umesto glatkog alpha blend-a.

43.7.3 Strategija 3: Front-to-Back sortiranje za Opaque objekte

UE5 ovo radi automatski, ali vredi razumeti mehanizam.

Opaque objekti se sortiraju po udaljenosti od kamere, od najblizeg do najdaljeg. Ovo maksimizira efikasnost Early-Z testa -- prvi nacrtani objekat popunjava depth buffer, i svi kasniji (dalji) objekti koji pokrivaju iste piksele se odbacuju pre pixel shader-a.

Front-to-back sortiranje + Early-Z:

  1. Nacrtaj najbliži objekat → depth buffer popunjen za te piksele
  2. Nacrtaj srednji objekat → Early-Z odbacuje piksele iza #1, 
                                crta samo vidljive
  3. Nacrtaj dalji objekat   → Early-Z odbacuje skoro sve piksele
  
  Overdraw: ~1.0x za opaque objekte!
  (uz neizbezno malo overhead-a za trouglove unutar istog mesh-a)

43.7.4 Strategija 4: Koristite Masked umesto Translucent za vegetaciju

Vegetacija (trava, drvece, busenje) se tradicionalno radi sa Masked blend mode-om (alpha test). Ali mnogi artisti pokusaju da koriste Translucent za "lepsе" ivice listova. Ovo je ogromna greska za performanse.

Poredenje za drvo sa 200 listova:

Masked blend mode:
  - Svaki list: pixel shader se pokrece, alpha test, discard
  - Early-Z *delimicno* radi (za opaque delove lista)
  - Overdraw: ~5-8x (od preklapanja, ali nema transparentnog layeringa)
  
Translucent blend mode:
  - Svaki list: pixel shader se pokrece, blending sa framebuffer-om
  - Early-Z NE RADI (translucent ne pise u depth buffer)
  - Mora back-to-front sort (skupo za 200 listova)
  - Overdraw: ~15-25x (svaki list dodaje overdraw bez ikakve eliminacije)
  
Razlika: Translucent drvo moze biti 2-3x skuplje od Masked drveta!

Za lepe ivice na Masked materijalima, UE5 nudi Dithered Opacity Mask koji simulira meke ivice koristeci dithering pattern. Ovo je mnogo jeftinije od prave transparentnosti.

43.7.5 Strategija 5: LOD za vegetaciju i particle-e na daljini

Na daljini, detalji vegetacije i particle efekata nisu vidljivi. Koristite agresivne LOD strategije:

LOD strategija za drvo:

  LOD 0 (0-30m):    Pun model sa 200 listova, svaki kao quad
  LOD 1 (30-60m):   Pojednostavljen model sa 80 listova
  LOD 2 (60-120m):  Kruna kao nekoliko velikih polygona + billboard tekstura
  LOD 3 (120m+):    Jedan billboard/imposter (1-2 quad-a)
  
  Overdraw na LOD 0: ~8x
  Overdraw na LOD 3: ~1-2x
  
  Usteda na daljini: enormna!

Za particle sisteme, koristite Niagara Scalability (vec pomenuto u 43.7.2-B) da smanjite i broj i velicinu particla na daljini.

43.7.6 Strategija 6: Ogranicite dekale

Dekali (decals) su cest izvor skrivenog overdraw-a. Svaki dekal dodaje minimalno 1x overdraw na povrsinu koju pokriva. Kada igrac ispuca 50 metaka u isti zid, imate potencijalno 50 dekala na istom regionu -- 50x overdraw-a samo za dekale!

Konkretne akcije:

1. Postavite maksimalan broj dekala po lokaciji. Recimo, maksimalno 5 dekala na istih 1m2.
2. Koristite "merging" dekala -- umesto novih dekala, modifikujte postojece.
3. Fade out dekale na daljini -- dekali koji su daleko od kamere ne moraju da budu vidljivi.
4. Koristite deferred decals (UE5 default) umesto forward decals gde je moguce -- deferred decali imaju konzistentniji trosak.

43.7.7 Strategija 7: Occlusion Culling

Ne crtajte objekte koje igrac ne moze da vidi. Ovo ne smanjuje overdraw po sebi (jer ne menja preklapanje vidljivih objekata), ali smanjuje ukupan broj obradenih fragmenata.

UE5 automatski koristi:

• Frustum culling -- ne crta objekte van vidnog polja kamere
• Hardware occlusion queries -- koristi GPU da testira da li je objekat sakriven iza drugog
• Software occlusion (Hi-Z based) -- koristi depth buffer za brzu proveru vidljivosti
• Precomputed Visibility Volumes -- unapred izracunata vidljivost za staticke scene

Occlusion culling efekat na overdraw:

Scena bez culling-a:
  500 objekata × prosecno 1000 piksela = 500,000 fragmenata
  Sa prosecnim overdraw-om 3x = 1,500,000 pixel shader poziva

Scena sa frustum + occlusion culling-om:
  120 vidljivih objekata × prosecno 1200 piksela = 144,000 fragmenata
  Sa prosecnim overdraw-om 2.5x = 360,000 pixel shader poziva
  
  Smanjenje: 76%!

43.7.8 Strategija 8: Koristite Nanite za opaque geometriju

Kao sto smo objasnili u sekciji 43.3, Nanite fundamentalno eliminise overdraw za opaque materijale koristeci visibility buffer. Svaki piksel se materijalno evaluira tacno jednom, bez obzira na kompleksnost scene.

Tradicionalni rendering:
  Objekat A pokriva piksel → pixel shader se pokrece
  Objekat B pokriva isti piksel → pixel shader se ponovo pokrece
  Early-Z pomaze, ali nije savrsen (sortiranje je po objektu, ne po pikselu)
  
Nanite rendering:
  Visibility buffer pass: Odredjuje koji trougao je vidljiv na SVAKOM pikselu
  Material pass: Pixel shader se pokrece TACNO JEDNOM po pikselu
  
  Overdraw za materijal evaluaciju: 1.0x (savrsen)

Ogranicenje: Nanite radi samo sa statickim mesh-evima i opaque/masked materijalima. Transparentni objekti, skeletal mesh-evi i particle sistemi i dalje koriste tradicionalni rendering pipeline i podlozni su overdraw-u.

43.8 Prakticni Primeri Overdraw Redukcije u UE5

Hajde da prodjemo kroz nekoliko realnih scenarija koje cete sresti u praksi.

43.8.1 Primer 1: Sumska scena sa previše vegetacije

Problem:

Pravite otvoreni svet sa gustom sumom. Scena izgleda fantasticno u editoru. Pokrenete na target hardveru -- 18 FPS.

Profiling rezultati:

  stat unit:
    Frame: 55.2 ms
    Game:   3.1 ms
    Draw:   5.8 ms
    GPU:   51.4 ms     ← GPU je jasno bottleneck!

  Test rezolucije:
    1080p: 18 FPS → 540p: 62 FPS
    → Jasno fill rate bound!

  Shader Complexity vizualizacija:
    Krosnje drveca: BELO/PINK (katastrofa)
    Trava na podu:  CRVENO
    Nebo:           ZELENO (OK)
    Tlo:            ZUTO (OK)

Analiza:

Krosnje drveca su problem. Svako drvo ima 300+ listova, svaki list je quad sa masked materijalom. Krosnje se medjusobno preklapaju (drvece je gusto). U centru scene, overdraw za krosnje je 15-20x.

Trava na podu takodje doprinosi -- hiljade malih grass blade-ova sa masked materijalima.

Resenje, korak po korak:

Korak A: Agresivniji LOD za drvece

Pre optimizacije:
  LOD 0: 300 listova (koristi se do 100m)
  LOD 1: 150 listova (koristi se od 100-200m)
  
Posle optimizacije:
  LOD 0: 300 listova (koristi se do 30m)     ← Smanjeni LOD raspon
  LOD 1: 100 listova (koristi se od 30-60m)
  LOD 2: Billboard krosnje (koristi se od 60-150m)
  LOD 3: Imposter (koristi se od 150m+)

Korak B: Smanjite broj grass blade-ova na daljini

Koristite Foliage LOD / cull distance:
  0-15m: puna gustina
  15-30m: 50% gustine
  30-50m: 20% gustine  
  50m+: samo teren tekstura, bez individualnih blade-ova

Korak C: Proverite materijale -- Masked umesto Translucent

Proverite da li su svi listovi zaista Masked, a ne Translucent. Jedan Translucent materijal na drvetu moze da kosta 2-3x vise od Masked.

Korak D: Razmislite o Nanite za debla i grane

Debla i grane drveca mogu da budu Nanite mesh-evi (opaque). Samo listove ostavite kao tradicionalne mesh-eve sa masked materijalima.

Rezultat:

Posle optimizacije:

  stat unit:
    Frame: 14.8 ms
    Game:   3.1 ms  
    Draw:   5.2 ms
    GPU:   11.6 ms    ← GPU drasticno rasterecen!

  FPS: 67 (sa 18!)
  
  Shader Complexity:
    Krosnje: ZELENO/ZUTO (umesto BELO/PINK)
    Trava: ZELENO (umesto CRVENO)

43.8.2 Primer 2: Particle-heavy borbena scena

Problem:

Pravite RPG sa mnogo magicnih efekata. U borbenim scenama sa vise likova koji istovremeno koriste magiju, FPS pada na 12.

Profiling:

  stat unit:
    Frame: 83.1 ms
    Game:   8.2 ms
    Draw:   6.4 ms
    GPU:   78.3 ms     ← Ogroman GPU trosak!

  stat gpu:
    BasePass:      4.8 ms
    Translucency: 62.1 ms   ← UZAS! 62 ms samo za transparentne!
    PostProcessing: 3.2 ms

  Test rezolucije:
    1080p: 12 FPS → 540p: 45 FPS
    → Fill rate bound, specificno translucency

Analiza:

62 ms za Translucency! To je skoro 4 cela frejma na 60 FPS. Problem su particle efekti: svaki lik koristi magiju sa velikim, overlapping particle-ima.

Bliži pogled otkriva:

• 8 aktivnih magicnih efekata istovremeno
• Svaki efekat ima 3-4 Niagara emitera
• Svaki emiter proizvodi 50-100 particla
• Particli su veliki (pokrivaju 200-400 piksela u precniku)
• Particli koriste Translucent blend mode sa skupim materijalima (Fresnel, noise, distortion)

Resenje:

Korak A: Smanjite velicinu particla

Pre:  Particle scale = 200-400 piksela (na 1080p)
Posle: Particle scale = 80-150 piksela

Fill rate usteda: ~4-6x

Korak B: Smanjite broj particla po efektu

Pre:  50-100 particla po emiteru, 3-4 emitera po efektu
Posle: 20-40 particla po emiteru, 2-3 emitera po efektu

Ukupno particla smanjeno ~60%

Korak C: Pojednostavite particle materijale

Pre:  
  - 4 texture sample-a (base color, noise, distortion, mask)
  - Fresnel izracunavanje
  - Noise funkcija za animaciju
  - ~150 instrukcija pixel shader-a

Posle:
  - 2 texture sample-a (base color + kombiovan mask/noise atlas)
  - Pojednostavljen Fresnel (aproksimacija)
  - Noise prebacen u teksturu umesto real-time izracunavanja
  - ~60 instrukcija pixel shader-a

Korak D: Koristite Scalability za smanjenje efekata na slabijem hardveru

Niagara Scalability:
  Epic kvalitet:    100% particla, 100% velicina
  High kvalitet:     70% particla,  80% velicina
  Medium kvalitet:   40% particla,  60% velicina
  Low kvalitet:      20% particla,  40% velicina

Korak E: Flipbook za daleke efekte

Za efekte koji su daleko od kamere, zameni particulate sistem flipbook animacijom -- jedan quad sa nizom frejmova. Drasticno smanjenje overdraw-a.

Rezultat:

Posle optimizacije:

  stat unit:
    Frame: 14.2 ms
    Game:   8.2 ms
    Draw:   6.1 ms
    GPU:   10.8 ms

  stat gpu:
    BasePass:       4.8 ms
    Translucency:   3.2 ms   ← Sa 62 ms na 3.2 ms!
    PostProcessing: 3.2 ms

  FPS: 70 (sa 12!)

43.8.3 Primer 3: Urbana scena sa mnogo stakla i refleksija

Problem:

Gradska scena sa modernim zgradama -- mnogo staklenih povrsina, reflektivnih obloga, vodena fontana. FPS je 25 na target hardveru.

Profiling:

  stat unit:
    Frame: 40.1 ms
    Game:   2.8 ms
    Draw:   7.2 ms
    GPU:   36.3 ms

  stat gpu:
    PrePass:        0.9 ms
    BasePass:       8.2 ms
    Translucency:  14.8 ms   ← Staklo + voda
    Reflections:    6.1 ms
    PostProcessing: 3.8 ms

Analiza:

Translucency je opet glavni krivac (14.8 ms), ali ovaj put nije od particla -- vec od staklenih povrsina koje pokrivaju velike delove ekrana. Svaka staklena povrsina je translucent materijal sa refleksijama.

Resenje:

Korak A: Koristite Screen Space refleksije umesto per-surface refleksija za staklo

Pre:  Svaka staklena povrsina ima svoj planar reflection capture
Posle: Koristite SSR (Screen Space Reflections) ili Lumen refleksije
       koje rade na nivou celog ekrana, ne po objektu

Korak B: Zamislite staklo kao Opaque materijal sa "staklastim" izgledom

Za staklo koje nema nista vidljivo iza sebe (npr. tamna unutrasnjost zgrade), koristite Opaque materijal sa visokim metallic-om i glatkim roughness-om. Izgleda kao staklo (reflektuje okolinu), ali nema overdraw-a jer je opaque.

Tipovi stakla i preporuke:

  Staklo iza koga se nista ne vidi: → OPAQUE (metallic + smooth)
  Staklo iza koga se vide objekti: → TRANSLUCENT (neizbezno, 
                                      ali minimizujte velicinu)
  Staklo automobila:               → MASKED sa dithered opacity
  Vodena povrsina:                  → TRANSLUCENT, ali samo jedan sloj!

Korak C: Limitirajte slojeve transparentnosti

Izbegavajte visestruke slojeve transparentnih objekata. Ako imate staklo ispred stakla ispred vode -- to su 3 sloja transparentnosti na istom pikselu. Gde je moguce, eliminisite jedan sloj.

Rezultat:

Posle optimizacije:

  stat unit:
    Frame: 16.1 ms
    Game:   2.8 ms
    Draw:   7.0 ms
    GPU:   12.4 ms

  stat gpu:
    PrePass:        0.9 ms
    BasePass:       6.8 ms    ← Vise opaque objekata (bivse staklo)
    Translucency:   2.1 ms   ← Sa 14.8 ms na 2.1 ms!
    Reflections:    1.2 ms   ← SSR umesto planar refleksija
    PostProcessing: 3.8 ms

  FPS: 62 (sa 25!)

43.8.4 Primer 4: Dekal Overflow na pucackoj mapi

Problem:

Multiplayer pucacka igra. Na pocetku runde sve radi na 60 FPS. Posle 5 minuta intenzivne borbe -- 30 FPS. Profiling ne pokazuje nikakav ocigledan problem -- draw call-ovi su pod kontrolom, geometrija se nije promenila.

Analiza:

Svaki put kada metak pogodi zid, igra stvara dekal (rupa od metka). Posle 5 minuta, na najpopularnijim tackama borbe (hodnik, ugao, krevet-barikada) postoji 200+ dekala na istom mestu.

stat gpu na pocetku runde:
  BasePass: 6.2 ms
  Decals:   0.3 ms

stat gpu posle 5 minuta:
  BasePass: 6.4 ms
  Decals:   8.7 ms   ← Dekali su eksplodirali!

200 dekala na istom regionu znaci 200x overdraw za svaki piksel u tom regionu. Svaki dekal pokrece pixel shader, cita teksture, i pise u framebuffer.

Resenje:

1. Maksimalan broj dekala globalno: 50 (najstariji se brisu)
2. Maksimalan broj dekala po 1m2 podrucju: 5
3. Dekali se fade-out-uju i brisu nakon 30 sekundi
4. Na daljini (>20m), dekali se ne renderuju

Implementacija u UE5:
  - UDecalComponent sa max lifetime = 30s
  - Blueprint sistem koji broji dekale po zoni
  - Cull distance za dekal actor-e = 20m

Rezultat:

FPS ostaje stabilan na 55-60 FPS tokom cele runde.

43.9 Napredne Tehnike i Razmatranja

43.9.1 Stencil-based optimizacija za transparentne objekte

UE5 podrzava koriscenje stencil buffer-a za ogranicavanje oblasti u kojima se transparentni objekti renderuju. Na primer, ako imate staklo samo na jednom delu ekrana, mozete koristiti stencil da ogranicite rendering transparentnosti samo na tu oblast.

Ovo ne smanjuje overdraw po pikselu, ali smanjuje broj piksela koji ulaze u transparentni pass.

43.9.2 Order-Independent Transparency (OIT)

Order-Independent Transparency je tehnika koja pokusava da resi problem sortiranja transparentnih objekata. Umesto da zahteva back-to-front sortiranje (koje je CPU trosak i izvor artefakata), OIT koristi razlicite pristupe za korekciju redosleda na GPU-u.

UE5 nema out-of-the-box OIT, ali postoje OIT plugini i custom implementacije. Treba napomenuti da OIT ne smanjuje overdraw -- svaki transparentni fragment se i dalje procesira. OIT samo resava sortiranje, ne kolicinu posla.

43.9.3 Fill rate i rezolucija -- TSR kao parcijalno resenje

Ako imate fill rate bottleneck, jedno resenje je da renderujete na nizoj rezoluciji i zatim upscalujete na nativnu rezoluciju. UE5-ov TSR (Temporal Super Resolution) radi upravo ovo -- renderuje na, recimo, 50-75% nativne rezolucije i zatim koristi temporalne informacije da rekonstruise sliku blizu nativne rezolucije.

Ovo je direktna pomoc za fill rate jer smanjuje broj piksela koje GPU mora da obradi:

Primer:

  Nativno 4K (3840 × 2160): 8,294,400 piksela po frejmu
  
  TSR na 66% rezolucije: 
    Render: 2534 × 1426 = 3,613,484 piksela
    Upscale: 3840 × 2160 (TSR rekonstrukcija)
    
  Fill rate usteda: ~56%!
  Vizuelni kvalitet: blizu nativnom 4K zahvaljujuci TSR rekonstrukciji

TSR je detaljo obradjen u poglavlju 33 (Temporal Super Resolution).

43.9.4 Async Compute i overlapping

Moderan GPU (kao sto smo objasnili u poglavlju 08) moze da izvrsava razlicite tipove posla istovremeno koristeci async compute. Na primer, dok GPU ceka na framebuffer write-ove (ROP ogranicen), moze da radi compute shader posao (shadow maps, SSAO, Lumen proracune) na ALU jedinicama koje bi inace bile neiskoriscene.

Ovo ne smanjuje overdraw, ali moze da "sakrije" deo troska popunjavanjem "rupa" u GPU utilizaciji.

43.9.5 Half-Resolution Particles

Tehnika koja se koristi u nekim igrama (i koja se moze implementirati u UE5 sa custom code-om) je renderovanje particla na pola rezolucije:

1. Renderujte sve opaque objekte na punoj rezoluciji
2. Renderujte particle-e na pola rezolucije (4x manje piksela)
3. Kompozitirajte half-res particle buffer na full-res framebuffer

Ovo smanjuje fill rate trosak particla za 4x, uz cenu neznatnog gubitka ostrince na ivicama particla (sto je obicno neprimetno jer su particli ionako meki i zamagljeni).

UE5 nema ovo built-in na trivijalan nacin, ali se moze postici preko custom pass-ova i render target-a.

43.10 Kompletan Workflow za Dijagnostiku i Resavanje Overdraw Problema

Hajde da objedinimo sve sto smo naucili u sistematski workflow koji mozete pratiti svaki put kada posumnjate na overdraw/fill rate problem.

Korak 1: Potvrdite da je GPU bottleneck

Pokrenite: stat unit

Ako je GPU >> Draw → GPU je bottleneck → nastavite
Ako je Draw >> GPU → CPU je bottleneck → vidite poglavlje 42
Ako je Game >> Draw i GPU → CPU je bottleneck od gameplay-a → 
  optimizujte gameplay logiku

Korak 2: Potvrdite da je fill rate problem

Pokrenite: r.ScreenPercentage 50

Ako FPS poraste 2-3x+ → fill rate bound → nastavite
Ako FPS jedva poraste → NIJE fill rate → 
  mozda je vertex processing, compute, ili nesto drugo

Korak 3: Identifikujte gde se fill rate trosi

Pokrenite: stat gpu

Pronadjite pass sa najvecim vremenom:
  - BasePass veliko → overdraw opaque geometrije ili skupi opaque materijali
  - Translucency veliko → transparentni objekti / particli
  - Shadows veliko → previse shadow caster-a (vidite poglavlje 31 - VSM)
  - PostProcessing veliko → previse post-process efekata
  - Reflections veliko → preskupe refleksije

Korak 4: Vizuelno identifikujte problematicne oblasti

1. View Mode → Shader Complexity
   Pronadjite CRVENE/BELE regione na ekranu.

2. View Mode → Quad Overdraw
   Pronadjite regione sa visokim quad overdraw-om.

3. Selektivno sakrivajte objekte (H taster) i posmatrajte
   kako se stat gpu menja. Kada sakrijete objekat i GPU
   vreme dramaticno padne -- pronasli ste krivca.

Korak 5: Primenite odgovarajucu strategiju

Korak 6: Verifikujte rezultate

Ponovo pokrenite stat unit i stat gpu.
Uporedite brojke sa pocetnim stanjem.
Proverite da vizuelni kvalitet nije neprihvatljivo degradiran.

Iteriraje: ako rezultati nisu dovoljno dobri, 
ponovite od koraka 3 za sledeci najskuplji pass.

43.11 Ceste Greske

Greska 1: Ignorisanje overdraw-a jer "GPU je jak"

Zasto je greska: Cak i najjaci GPU ima ogranicen fill rate. Na 4K rezoluciji sa kompleksnim materijalima i visokim overdraw-om, cak i RTX 4090 moze da se zagusi. Takodje, vasa igra treba da radi na razlicitom hardveru, ne samo na najjacem.

Resenje: Uvek profajlirajte. Testirajte na target hardveru (najslabijem hardveru koji zelite da podrzite).

Greska 2: Koriscenje Translucent blend mode-a gde Masked radi posao

Zasto je greska: Translucent materijali su dramaticno skupi po pitanju overdraw-a u poredjenju sa Masked materijalima. Mnogi artisti koriste Translucent jer daje "lepse" meke ivice, ali cena je ogromna.

Resenje: Koristite Masked + Dithered Opacity za meke ivice. Rezervisite Translucent samo za objekte gde je prava transparentnost vizuelno neophodna (staklo, voda, hologrami).

Greska 3: Ogromne cestice "jer tako dim izgleda realisticnije"

Zasto je greska: Velike cestice pokrivaju vise piksela. Ako imate 20 velikih cestica dima koje pokrivaju 500x500 piksela svaka i medjusobno se preklapaju, potrosili ste enormnu kolicinu fill rate-a.

Resenje: Koristite vise manjih cestica umesto malo velikih. Vizuelno cesto izgleda jednako dobro (pa i bolje -- vise detalja), a fill rate trosak je dramaticno manji. Pogledajte primer u sekciji 43.7.2-A.

Greska 4: Ne postavljanje LOD-a za vegetaciju

Zasto je greska: Drvo sa 300 listova na udaljenosti od 200m zauzima mozda 100x100 piksela na ekranu, ali GPU i dalje procesira svih 300 quad-ova sa masked materijalima. Overdraw od 15-20x na regionu koji igrac jedva vidi.

Resenje: Billboard/imposter na daljini. LOD tranzicija treba da bude agresivna. Igrac na 200m udaljenosti ne moze da razlikuje 300 individualnih listova od jednog billboard-a.

Greska 5: Previise post-processing efekata

Zasto je greska: Svaki post-processing pass je fullscreen pass koji dodaje 1x overdraw na nivou celog ekrana. Pet custom post-process pass-ova sa kompleksnim shaderima moze da doda 5+ ms GPU vremena.

Resenje: Kombinujte post-process efekte gde je moguce (jedan pass za vise efekata). Iskljucite efekte koji nisu vizuelno znacajni. Koristite UE5-ove ugradjene PP efekte koji su vec optimizovani.

Greska 6: Ne koriscenje Nanite-a za opaque geometriju

Zasto je greska: Nanite eliminise overdraw za opaque materijale koristeci visibility buffer. Ne koristiti Nanite za pogodne mesh-eve znaci da propustate besplatnu overdraw redukciju.

Resenje: Konvertujte sve pogodne staticne opaque mesh-eve u Nanite (poglavlje 30 za detalje o ogranicenjima i best practices).

Rezime poglavlja

Overdraw i fill rate su fundamentalni koncepti koji odredjuju koliko vasa scena kosta GPU-u. Hajde da sumiramo kljucne poruke:

1. Overdraw je visestruko procesiranje istog piksela u istom frejmu. Overdraw od 2-3x je normalan; iznad 5x treba optimizovati.

2. Fill rate je brzina kojom GPU moze da procesira piksele. Ogranicen je pixel shader throughput-om, ROP-ovima, TMU-ovima i memory bandwidth-om.

3. Overdraw direktno multipluje fill rate zahteve. Overdraw od 3x znaci da vam treba 3x veci fill rate.

4. Kljucni test za fill rate bottleneck: Smanjite rezoluciju (r.ScreenPercentage 50). Ako FPS dramaticno poraste, fill rate je bottleneck.

5. Transparentni objekti su najveci uzrocnik overdraw-a jer ne pisu u depth buffer i ne mogu koristiti Early-Z. Koristite Masked ili Opaque gde je moguce.

6. Particle sistemi generisu enorman overdraw jer se poluprozirni sprite-ovi masovno preklapaju. Smanjite velicinu, broj i kompleksnost particla.

7. Vegetacija sa masked materijalima je skupa jer ima visok overdraw od preklapajucih listova. Koristite agresivne LOD strategije.

8. Depth prepass eliminise overdraw za opaque objekte popunjavanjem depth buffer-a pre glavnog pass-a. UE5 ga koristi po default-u.

9. Quad overdraw je gubitak efikasnosti uzrokovan malim trouglovima koji ne popunjavaju 2x2 quad-ove. Nanite i LOD sistemi resavaju ovaj problem.

10. Nanite fundamentalno eliminise overdraw za opaque geometriju koristeci visibility buffer -- svaki piksel se materijalno evaluira tacno jednom.

11. TSR (Temporal Super Resolution) pomaze sa fill rate-om renderovanjem na nizoj rezoluciji i upscaling-om.

12. Uvek profajlirajte -- stat unit, stat gpu, Shader Complexity i Quad Overdraw vizualizacioni modovi su vasi primarni alati.

Kljucni pojmovi

Veze sa drugim poglavljima

• Poglavlje 08 (GPU Arhitektura) -- Fundamentalno objasnjenje fill rate-a, ROP-ova, TMU-ova, memory bandwidth-a i kako GPU fizicki procesira piksele. Sekcija o fill rate-u i overdraw-u daje hardversku perspektivu na koncepte iz ovog poglavlja.

• Poglavlje 09 (Rasterizacija) -- Detaljno objasnjenje overdraw-a na nivou rasterizacije, Early-Z optimizacija, depth prepass, quad rendering (2x2) i fragment vs piksel razlika. Sekcije 9.9 (Overdraw), 9.6 (Early-Z), i 9.11 (Quad Rendering) su direktno relevantne.

• Poglavlje 21 (Shader Optimizacija) -- Tehnike za smanjenje kompleksnosti pixel shader-a, sto direktno smanjuje fill rate zahteve. Optimizovaniji shader znaci da GPU moze da podnese vise overdraw-a.

• Poglavlje 30 (Nanite) -- Nanite-ov visibility buffer pristup eliminise overdraw za opaque materijale. Software rasterizer eliminise quad overdraw za male trouglove. Kljucno za razumevanje sekcije 43.7.8 ovog poglavlja.

• Poglavlje 33 (TSR - Temporal Super Resolution) -- TSR kao resenje za fill rate bottleneck kroz upscaling sa nize rezolucije. Relevantno za sekciju 43.9.3.

• Poglavlje 35 (Niagara Particle System) -- Detaljno pokriva overdraw i fill rate probleme specificne za particle sisteme, ukljucujuci Scalability sistem i optimizacione strategije. Sekcije 35.6 i 35.10 su posebno relevantne.

• Poglavlje 40 (UE5 Profiling) -- Alati za profiling koji se koriste za dijagnostiku fill rate problema: stat unit, stat gpu, ProfileGPU, Shader Complexity vizualizacija. Koristite workflow iz poglavlja 40 zajedno sa dijagnostickim koracima iz sekcije 43.10.

• Poglavlje 42 (Draw Calls i Batching) -- Komplementarno poglavlje koje pokriva CPU-side bottleneck (draw calls), dok ovo poglavlje pokriva GPU-side bottleneck (fill rate). Zajedno cine celokupnu sliku rendering optimizacije.

Preporuceno citanje i resursi

1. "Real-Time Rendering, 4th Edition" (Akenine-Moller, Haines, Hoffman) -- Poglavlje 23 pokriva rendering pipeline optimization ukljucujuci fill rate analizu i overdraw redukciju. Biblija real-time grafike.

2. Epic Games dokumentacija: Shader Complexity View Mode -- Zvanicna dokumentacija o koriscenju Shader Complexity vizualizacije za identifikaciju skupih regiona.

3. "GPU Gems 2, Chapter 6: Hardware Occlusion Queries Made Useful" (Bartz, Staneker) -- Tehnicko objasnjenje occlusion culling-a koji smanjuje overdraw eliminisanjem nevidljivih objekata.

4. GDC 2021: "A Deep Dive into Nanite Virtualized Geometry" (Brian Karis, Epic Games) -- Objasnjava Nanite-ov visibility buffer pristup koji eliminise overdraw za opaque geometriju.

5. "Rendering the Hellscape of Doom Eternal" (GDC 2020) -- Prakticna prezentacija o overdraw optimizaciji i depth prepass strategijama u AAA produkciji. Izvrsni primeri iz prakse.

6. "Particle Trimming for Efficient GPU Rendering" (SIGGRAPH, razliciti autori) -- Tehnika za smanjenje fill rate troska particla trimovanjem transparentnih ivica sprite-ova.

7. UE5 dokumentacija: Profiling and Optimization -- Vodic za koriscenje svih UE5 profiling alata releventnih za fill rate dijagnostiku.

8. RenderDoc dokumentacija: renderdoc.org -- Besplatan GPU debugger koji vam omogucava da vidite pixel history (sve fragmente koji su se takmicili za svaki piksel) -- savrseno za vizuelnu analizu overdraw-a.

9. NVIDIA Nsight Graphics: developer.nvidia.com/nsight-graphics -- NVIDIA-in GPU profiler sa detaljnom pixel history analizom, fill rate metrikama i quad utilization statistikama.