Poglavlje 50: Studije Slucaja -- Primena Svega Naucenog

"Teorija bez prakse je prazna, praksa bez teorije je slepa." -- Immanuel Kant (slobodan prevod)

Uvod

Stigli smo do poslednjeg poglavlja ove knjige. Ako si dosao dovde -- cestitam. Prosao si kroz skoro pedeset poglavlja, od prvog pokretanja Unreal Engine 5 editora, pa sve do naprednih tehnika profilisanja, optimizacije memorije, i rada sa Nanite i Lumen sistemima. Ali znanje bez primene ostaje samo potencijal.

U ovom poglavlju necemo uvoditi nove koncepte. Umesto toga, uradicemo nesto mnogo vaznije: primeniti sve sto smo naucili na cetiri realisticna scenarija iz prakse. Svaka studija slucaja simulira situaciju u kojoj bi se mogao naci kao UE5 developer -- od archviz projekta do VR iskustva. Za svaku cemo proci kompletan proces: definisanje problema, profilisanje, identifikaciju uskih grla (bottleneck), primenu optimizacija korak po korak, i merenje rezultata.

Ovo je tvoj "zavrsni ispit", ali bez stresa. Sedi, procitaj, i posmatraj kako se svi delovi slagalice uklapaju.

Kako citati ove studije slucaja

Svaka studija slucaja prati istu strukturu:

1. Opis scene -- sta gradimo i koji su zahtevi
2. Pocetno stanje -- performanse pre optimizacije, sa konkretnim brojevima
3. Profilisanje -- identifikacija uskog grla pomocu alata koje smo naucili
4. Optimizacija -- korak po korak, sa referencama na prethodna poglavlja
5. Rezultat -- finalne performanse i kljucni zakljucci

Svaka referenca na prethodno poglavlje oznacena je u formatu (Poglavlje XX), tako da uvek mozes da se vratis i osvezis znanje o odredjenom konceptu.

Studija Slucaja 1: Archviz Enterijer -- Luksuzni Apartman

1.1 Opis scene i zahtevi

Nas prvi projekat je arhitektonska vizualizacija (archviz) luksuznog apartmana. Klijent je arhitektonski studio koji zeli interaktivnu prezentaciju za svoje kupce. Scena treba da se prikazuje u realnom vremenu na visokom kvalitetu.

Karakteristike scene:

• Prostrani dnevni boravak sa kuhinjom (open-plan, oko 120 m2)
• Veliki stakleni prozori (floor-to-ceiling) sa pogledom na grad
• Mnogo reflektivnih povrsina: mermerni pod, lakirani namestaj, ogledala, stakleni sto
• Dekorativno osvetljenje: 24 Point Light-a, 8 Spot Light-ova, 3 Rect Light-a, plus Directional Light za sunce
• Visoko detaljni modeli namestaja (sofa, stolice, kuhinjski elementi)
• Realisticni materijali sa visokom rezolucijom tekstura (4K za vecinu, neki 8K)
• Eksterijerni pogled kroz prozore: city skyline sa distant geometry

Zahtevi klijenta:

1.2 Pocetno stanje -- Houston, imamo problem

Pokrecemo build i odmah vidimo problem. Projekat se renderuje, izgleda fantasticno -- ali performanse su daleko ispod cilja.

Pocetni stat unit rezultati:

Frame:    40.0 ms  (25 FPS)
Game:      2.1 ms
Draw:      5.8 ms
GPU:      38.7 ms
RHI:       4.2 ms

Pocetni stat gpu rezultati (najskuplji renderovanje prolazi):

Lights                  12.4 ms
BasePass                 8.1 ms
PostProcessing           5.6 ms
Reflections              4.8 ms
Translucency             3.9 ms
Shadows                  2.8 ms
Lumen Scene              1.8 ms

Sa 25 FPS-a na 4K rezoluciji, daleko smo od ciljanih 60 FPS-a. Moramo smanjiti frame time sa 40 ms na ispod 16.67 ms.

1.3 Profilisanje -- Gde je usko grlo?

Kao sto smo naucili u Poglavlju 38 (Profilisanje i Dijagnostika), prvi korak je uvek identifikacija uskog grla. Pogledajmo sta nam brojevi govore:

• Game thread: 2.1 ms -- Logika igre je minimalna (ovo je archviz, nema gameplay-a). Nema problema.
• Draw thread: 5.8 ms -- Draw call-ovi su umereni. CPU strana renderovanja je OK.
• GPU: 38.7 ms -- Ovo je nas jasni bottleneck. GPU ne moze da zavrsi renderovanje jednog frame-a na vreme.

Zakljucak: Scena je GPU-bound.

Pogledajmo detaljnije GPU rezultate:

1. Lights (12.4 ms) -- Ovo je ubedljivo najskuplji pass. Sa 35 svetala u relativno maloj prostoriji, imamo ogroman broj overlapping lights (svetla ciji se radijusi preklapaju). Kao sto smo objasnili u Poglavlju 22 (Osvetljenje i Senke), svako dinamicko svetlo koje utice na piksel zahteva dodatni rendering pass za taj piksel. Kada se mnogo svetala preklapa, troskovi eksplodiraju.

2. BasePass (8.1 ms) -- Materijali su skupi. 4K i 8K teksture sa kompleksnim PBR shader-ima (visestruki UV layer-i, detail normal maps) trose bandwidth.

3. PostProcessing (5.6 ms) -- Post-process lanac je neoptimizovan. Bloom, Ambient Occlusion, Screen Space Reflections, Motion Blur, Tone Mapping -- sve je ukljuceno na highest settings.

4. Reflections (4.8 ms) -- Mnogo reflektivnih povrsina znaci mnogo ray-tracing ili screen-space reflection posla.

5. Translucency (3.9 ms) -- Stakleni prozori su najskuplji transparentni objekti. Kao sto smo videli u Poglavlju 26 (Transparentnost i Overdraw), transparentni materijali generisu overdraw jer se svaki piksel iza stakla mora renderovati, a zatim se i samo staklo renderuje preko.

1.4 Optimizacija -- Korak po korak

Korak 1: Smanjenje broja overlapping svetala

Problem: 35 dinamickih svetala u malom prostoru generise ogroman lighting cost.

Resenje:

Primenjujemo principe iz Poglavlja 22 (Osvetljenje i Senke) i Poglavlja 43 (Optimizacija Osvetljenja):

• Redukcija svetala: Od 24 Point Light-a, 12 su dekorativna svetla ispod kuhinjskih ormara i u policama. Zamenjujemo ih sa emissive materialima koji vizuelno simuliraju svetlo ali ne generisu stvarni lighting cost. Ovo smanjuje broj aktivnih svetala sa 35 na 23.

• Smanjenje attenuation radius-a: Preostalim svetlima smanjujemo radijus uticaja tako da se sto manje preklapaju. Umesto default-nog velikog radijusa, precizno podesavamo svaki Attenuation Radius da pokriva samo oblast koju treba da osvetli.

• Staticka svetla gde je moguce: 8 Spot Light-ova (za recessed ceiling lights) pretvaramo u Static umesto Movable. Posto se ova svetla nikada ne menjaju, mogu koristiti baked lightmaps. Klijent je potvrdio da nije potrebna dinamicka promena osvetljenja za ova svetla.

• Max Draw Distance na svetlima: Svetlima koja su manje vazna dodajemo Max Draw Distance tako da se gase kada kamera nije u blizini.

Rezultat posle Koraka 1:

stat gpu:
Lights                   5.1 ms  (bilo 12.4 ms, ustedeli 7.3 ms)

stat unit:
Frame:    30.2 ms  (33 FPS)
GPU:      28.9 ms

Odlicno! Samo ovim korakom smo dobili 8 FPS-a. Ali jos smo daleko od cilja.

Korak 2: Optimizacija staklenih materijala

Problem: Floor-to-ceiling prozori koriste kompleksan glass shader sa refrakcijom, koji generise znacajan overdraw.

Resenje:

Primenjujemo principe iz Poglavlja 26 (Transparentnost i Overdraw) i Poglavlja 25 (Material Optimizacija):

• Pojednostavljanje glass materijala: Umesto punog translucent materijala sa refrakcijom (koji zahteva renderovanje scene iza stakla), koristimo Translucent Blend Mode sa Surface ForwardShading umesto Surface TranslucencyVolume. Ovo je jeftinije jer ne zahteva visestruke prolaze.

• Dithered opacity za daleka stakla: Za staklene panele koji nisu u prvom planu, koristimo Dithered Opacity pristup -- opaque material sa dithered transparency efektom. Ovo eliminise overdraw u potpunosti za te panele jer se tretiraju kao opaque.

• Razdvajanje inner/outer glass: Umesto jednog mesh-a sa obe strane stakla, koristimo single-sided glass gde je to moguce, sto prepolovljava broj transparentnih piksela.

Rezultat posle Koraka 2:

stat gpu:
Translucency             1.2 ms  (bilo 3.9 ms, ustedeli 2.7 ms)
Reflections              3.8 ms  (bilo 4.8 ms, ustedeli 1.0 ms)

stat unit:
Frame:    26.1 ms  (38 FPS)
GPU:      24.8 ms

Korak 3: Lumen podesavanja

Problem: Lumen Global Illumination i Reflections su podrazumevano konfigurisani za opsti slucaj, ne za archviz enterijer.

Resenje:

Primenjujemo principe iz Poglavlja 44 (Lumen -- Dublje Razumevanje):

• Lumen Final Gather Quality: Smanjujemo sa 6.0 na 2.0. Za enterijersku scenu sa uglavnom difuznim povrsinskim, razlika u kvalitetu je minimalna, ali usteda u performansama je znacajna.

• Lumen Scene Lighting Quality: Smanjujemo sa 4.0 na 1.0 za Software Ray Tracing rezim. Za ovu velicinu scene, 1.0 daje dovoljno dobru aproksimaciju.

• Lumen Reflections: Umesto full Lumen reflections za sve povrsine, aktiviramo ih samo za podove i kljucne reflektivne povrsine putem Reflection Method override-a na materijalima. Za manje vazne refleksije, koristimo Screen Space Reflections (SSR) koje su jeftinije.

• Lumen Max Trace Distance: Smanjujemo sa default 200 metara na 30 metara. Enterijer je zatvoren prostor -- nema potrebe da Lumen prati zrake na velike udaljenosti.

Rezultat posle Koraka 3:

stat gpu:
Lumen Scene              0.8 ms  (bilo 1.8 ms, ustedeli 1.0 ms)
Reflections              2.1 ms  (bilo 3.8 ms, ustedeli 1.7 ms)

stat unit:
Frame:    22.5 ms  (44 FPS)
GPU:      21.2 ms

Napredujemo! Ali jos uvek nam fali oko 6 ms do naseg cilja od 16.67 ms.

Korak 4: Teksture i rezolucija materijala

Problem: Mnoge teksture su nepotrebno velike. 8K teksture za mermerni pod? Zid koji se nikad ne vidi izbliza ima 4K teksture?

Resenje:

Primenjujemo principe iz Poglavlja 24 (Teksture -- Formati, Streaming, i Memorija) i Poglavlja 46 (Memorija -- Budzetiranje i Upravljanje):

• Audit tekstura: Koristimo stat streaming i Texture Statistics u Content Browser-u da identifikujemo koje teksture trose najvise memorije i bandwidth-a.

• Smanjenje rezolucije:

  • 8K teksture za pod --> 4K (pod se vidi pod uglom, 8K je nepotreban)
  • 4K teksture za zidove koji se vide samo iz daljine --> 2K
  • 4K normal maps --> 2K (razlika je jedva primetna)

• Max Texture Size override: Za materijale koji su daleko od kamere (npr. eksterijer vidljiv kroz prozore), postavljamo Max In-Game Texture Size na 1024 u texture asset settings.

• Virtual Texture za pod: Mermerni pod konvertujemo u Runtime Virtual Texture (RVT) sistem, kao sto smo naucili u Poglavlju 34 (Virtual Textures). Ovo poboljsava streaming i smanjuje memorijsko opterecenje.

Rezultat posle Koraka 4:

stat gpu:
BasePass                 5.2 ms  (bilo 8.1 ms, ustedeli 2.9 ms)

stat unit:
Frame:    19.4 ms  (51 FPS)
GPU:      18.1 ms

Memorija:

Texture Streaming Pool:  890 MB  (bilo 1420 MB, ustedeli 530 MB)

Skoro smo tu! Fali nam jos malo.

Korak 5: LOD za namestaj i post-processing optimizacija

Problem: Modeli namestaja imaju veoma visok poly count (sofa 180K tris, svaka stolica 95K tris), a svi post-process efekti su na maximum.

Resenje:

Primenjujemo principe iz Poglavlja 30 (LOD -- Nivoi Detalja) i Poglavlja 27 (Post-Processing Optimizacija):

• Auto-LOD generisanje: Za svaki komad namestaja generisemo LOD-ove:

  • LOD0: Originalni model (koristi se kad je kamera blizu)
  • LOD1: 50% redukcija (srednja udaljenost)
  • LOD2: 25% redukcija (daleka udaljenost)

  Koristimo UE5 built-in LOD generation (desni klik na Static Mesh --> "Generate LODs" sa Reduction Settings).

• Nanite za kljucne modele: Razmatramo Nanite za modele sa najvise poligona, ali u ovom slucaju tradicionalni LOD-ovi su dovoljni jer imamo mali broj modela.

• Post-processing optimizacija:

  • Motion Blur: Iskljucujemo potpuno. Ovo je archviz, ne brza igra. Usteda: ~0.5 ms.
  • Bloom: Smanjujemo kvalitet sa 5 na 3. Razlika je jedva vidljiva. Usteda: ~0.3 ms.
  • Ambient Occlusion: Smanjujemo Intensity sa 1.0 na 0.5 i Radius sa 200 na 100. Usteda: ~0.4 ms.
  • Screen Space Reflections: Vec smo ovo optimizovali u Koraku 3.
  • Depth of Field: Prebacujemo sa Cinematic na Gaussian. Za interaktivni walkthrough, Gaussian je sasvim dovoljan i jeftiniji. Usteda: ~0.3 ms.

• Eksterijerni LOD: City skyline vidljiv kroz prozore zamenjujemo sa HLOD verzijom -- mnogo jednostavnija geometrija sa baked teksturama. Posto se nikada ne pristupa tim modelima, dovoljno je da izgledaju dobro kroz staklo.

Rezultat posle Koraka 5:

stat gpu:
PostProcessing           3.6 ms  (bilo 5.6 ms, ustedeli 2.0 ms)
BasePass                 4.3 ms  (bilo 5.2 ms, ustedeli 0.9 ms)

stat unit:
Frame:    16.1 ms  (62 FPS)
GPU:      15.2 ms

1.5 Finalni rezultat

Klijent je zadovoljan. Scena radi stabilno na 60+ FPS na 4K rezoluciji, sa minimalnim vizuelnim kompromisima. Vecina posetilaca ne bi uocila razliku izmedju optimizovane i neoptimizovane verzije, ali bi itekako osetila razliku u fluidnosti kretanja.

1.6 Kljucne lekcije iz Studije 1

1. Overlapping lights su najcesci "tihi ubica" performansi u enterijerskim scenama. Uvek proveri koliko se svetala preklapa u datom prostoru.
2. Transparentni materijali su skuplji nego sto izgledaju. Kad god mozes, zameni ih "laznim" pristupima (dithered opacity, opaque sa alpha clip).
3. Post-processing je "besplatan" sve dok ne postane problem. Revidiraj svaki efekat i pitaj se: "Da li mi je ovo zaista potrebno?"
4. Teksture vece od onoga sto ce se ikada videti su cisto bacanje resursa. Audit tekstura je brz i jeftin, a donosi znacajne ustede.

Studija Slucaja 2: Open World Landscape -- Beskrajne Ravnice

2.1 Opis scene i zahtevi

Drugi projekat je open world okruzenje za RPG igru. Scena predstavlja ogromno prirodno okruzenje sa razlicitim biomovima.

Karakteristike scene:

• Velicina terena: 8 km x 8 km (64 km2 ukupne povrsine)
• Landscape sa 7 layer-a materijala (trava, zemlja, pesak, stene, sneg, blato, put)
• Vegetacija: ~500,000 instanci foliage-a (trava, busenje, drvece) rasporedjena proceduralno
• Stene: Vise stotina razlicitih rock formation-a, mnoge sa visokim poly count-om
• Voda: Veliki jezero i reka sa Water System (UE5 built-in)
• Atmosfera: Volumetric Clouds, Sky Atmosphere, Exponential Height Fog
• Dinamicko doba dana: Day/night cycle sa pokretnim Directional Light-om

Zahtevi:

2.2 Pocetno stanje

Scena je zavrsena od strane art tima. Izgleda prelepo -- ali performanse su problematicne.

Pocetni stat unit rezultati:

Frame:    28.6 ms  (35 FPS)
Game:      3.2 ms
Draw:     11.4 ms
GPU:      26.8 ms
RHI:       5.1 ms

Pocetni stat gpu rezultati:

BasePass                10.2 ms
Shadows                  5.8 ms
Foliage                  4.1 ms
Landscape                3.2 ms
PostProcessing           2.1 ms
Translucency (water)     1.4 ms

Dodatni problemi:

• Streaming hitches: Svaka 2-3 sekunde, frame time skace na 80-120 ms dok se igraci krece po svetu
• Memorija: VRAM koriscenje doseze 9.2 GB, RAM 14.8 GB -- oba prekoracuju budget

2.3 Profilisanje

Ovaj scenario je slozeniji od prethodnog jer imamo mesovito usko grlo (mixed bottleneck). Pogledajmo:

• GPU (26.8 ms) je najsporiji -- to je primarni bottleneck
• Draw thread (11.4 ms) je takodje visok -- sekundarno usko grlo na CPU strani

Koristimo Unreal Insights (kao sto smo naucili u Poglavlju 39, Unreal Insights -- Napredna Dijagnostika) da dublje analiziramo:

GPU analiza:

1. BasePass (10.2 ms): Landscape material sa 7 layer-a je izuzetno skup. Svaki piksel terena mora da evaluira svih 7 layer-a i blend-uje izmedju njih. Ovo je poznati problem koji smo opisali u Poglavlju 33 (Landscape i World Partition).

2. Shadows (5.8 ms): Dinamicke senke od Directional Light-a sa Cascaded Shadow Maps pokrivaju ogromno podrucje. Far cascade renderuje senke za objekte udaljene i do 4 km.

3. Foliage (4.1 ms): Pola miliona instanci foliage-a generise znacajan overdraw, pogotovo trava koja je renderovana kao alpha-masked billboard.

CPU analiza (Draw thread):

Koristimo stat SceneRendering:

Mesh Draw Calls:        18,420
Visible Static Meshes:  12,800
Visible Foliage:         8,900

18,420 draw call-ova! Kao sto smo naucili u Poglavlju 42 (Draw Call-ovi i Batching), svaki draw call ima CPU overhead, i iznad ~5,000-10,000 draw call-ova pocinjemo da vidimo CPU bottleneck na Draw thread-u.

Streaming analiza:

Koristimo stat Streaming i vidimo problem:

Texture Streaming Pool:     2048 MB / 1024 MB (OVER BUDGET!)
Pending Mip Requests:       342
Cancelled Requests:          87

Texture streaming pool je duplo manji od onoga sto scena zahteva. Engine neprekidno ucitava i izbacuje teksture, sto uzrokuje hitches. Ovo je klasican problem koji smo obradili u Poglavlju 24 (Teksture -- Formati, Streaming, i Memorija).

2.4 Optimizacija

Korak 1: Runtime Virtual Texture (RVT) za Landscape

Problem: 7-layer landscape material evaluira svaki layer za svaki piksel, sto je O(n) po broju layer-a.

Resenje:

Implementiramo Runtime Virtual Texture (RVT) sistem, detaljno opisan u Poglavlju 34 (Virtual Textures):

• Kreiramo RVT asset za landscape sa BaseColor, Normal, Roughness/Specular i WorldHeight stranicama
• Landscape material renderuje svoje layer-e u RVT umesto direktno na ekran
• Finalni material cita iz RVT-a -- sto je konstantna operacija (O(1)) bez obzira na broj layer-a
• RVT tile velicina: 256x256 piksela, sa 8 mip nivoa

Kljucna prednost: jednom kada je tile renderovan u RVT cache, ne mora se ponovo racunati dok se ne promeni. Za vecinu frame-ova, landscape sampling je jednostavno citanje teksture.

Rezultat posle Koraka 1:

stat gpu:
Landscape                0.9 ms  (bilo 3.2 ms, ustedeli 2.3 ms)
BasePass                 7.8 ms  (bilo 10.2 ms, ustedeli 2.4 ms, jer landscape BasePass deo)

stat unit:
Frame:    24.1 ms  (41 FPS)
GPU:      22.3 ms

Korak 2: Foliage LOD, Cull Distance, i Overdraw

Problem: 500K foliage instanci generise 4.1 ms GPU cost i 8,900 draw call-ova.

Resenje:

Primenjujemo principe iz Poglavlja 31 (Foliage i Instanced Rendering) i Poglavlja 26 (Transparentnost i Overdraw):

• Cull Distance Volume-i: Postavljamo agresivne cull distance-e:

  • Trava (grass): max 50 metara (bilo 150 m)
  • Busenje (bushes): max 100 metara (bilo 300 m)
  • Mala drveca: max 500 metara (bilo 1000 m)
  • Velika drveca: max 2000 metara (bez promene)

• Foliage LOD:

  • Trava: LOD0 (full mesh) do 15 m, LOD1 (simplified) 15-35 m, LOD2 (billboard) 35-50 m
  • Busenje: LOD0 do 30 m, LOD1 30-70 m, LOD2 70-100 m
  • Drvece: LOD0 do 100 m, LOD1 100-300 m, LOD2 (billboard/impostor) 300+ m

• Overdraw redukcija za travu:

  • Zamenjujemo alpha-masked grass shader sa Masked blend mode umesto Translucent
  • Koristimo Opacity Mask Clip Value od 0.33 umesto default 0.5 da smanjimo aliasing
  • Dodajemo Dither Temporal AA za meksi prelaz na LOD granicama

• Density skaliranje: Smanjujemo density trave za 30% u oblastima gde je manje vidljiva (udaljene livade). Korisniku ovo nece biti primetno jer se trava ionako gasi na 50 m.

Rezultat posle Koraka 2:

stat gpu:
Foliage                  1.4 ms  (bilo 4.1 ms, ustedeli 2.7 ms)

stat SceneRendering:
Visible Foliage:         3,200   (bilo 8,900, smanjeno za 64%)
Mesh Draw Calls:        12,700   (bilo 18,420, smanjeno za 31%)

stat unit:
Frame:    20.5 ms  (49 FPS)
Draw:      7.8 ms  (bilo 11.4 ms)
GPU:      18.9 ms

Korak 3: HLOD za distant areas

Problem: Udaljene oblasti (izvan 500 m) i dalje generisu mnogo draw call-ova za individualne objekte (stene, drvece, strukture).

Resenje:

Implementiramo Hierarchical Level of Detail (HLOD) sistem, detaljno opisan u Poglavlju 32 (HLOD i Proxy Geometry) i Poglavlju 33 (Landscape i World Partition):

• Koristimo World Partition HLOD pipeline:

  • Svet delimo u HLOD cell-ove velicine 256 m x 256 m
  • Za svaki cell generisemo HLOD proxy mesh koji zamenjuje sve objekte u tom cell-u na velikoj udaljenosti
  • HLOD layer 0 (256 m cells): aktivira se na 500 m udaljenosti
  • HLOD layer 1 (512 m cells, 4 cell-a spojena): aktivira se na 1500 m udaljenosti
  • HLOD layer 2 (1024 m cells, 16 cell-ova spojeno): aktivira se na 3000 m udaljenosti

• HLOD Build generise:

  • Simplified proxy mesh za svaki cell
  • Baked teksture (albedo + normal) na atlasu
  • Pojednostavljene materijale

• Rezultat: umesto hiljada individualnih draw call-ova za udaljene objekte, imamo samo nekoliko desetina HLOD proxy draw call-ova.

Rezultat posle Koraka 3:

stat SceneRendering:
Mesh Draw Calls:         6,800   (bilo 12,700, smanjeno za 46%)
Visible Static Meshes:   4,100   (bilo 12,800, smanjeno za 68%)

stat unit:
Frame:    17.8 ms  (56 FPS)
Draw:      5.1 ms  (bilo 7.8 ms)
GPU:      16.2 ms

Korak 4: Async Loading i Streaming optimizacija

Problem: Streaming hitches od 80-120 ms se desavaju tokom kretanja.

Resenje:

Primenjujemo principe iz Poglavlja 35 (World Partition i Level Streaming) i Poglavlja 47 (Streaming -- Sve Sto Treba Da Znas):

• World Partition streaming source konfiguracija:

  • Povecavamo Streaming Source radius na 300 m (umesto default 150 m) da se level-i ucitavaju ranije, pre nego sto igracu zatrebaju
  • Postavljamo Loading Range na 500 m tako da se cell-ovi ucitavaju na 500 m i otpustaju na 600 m (sa 100 m histerezom)

• Async Loading prioritizacija:

  • Aktiviramo s.AsyncLoadingTimeLimit=2.0 -- ogranicavamo async loading na 2 ms po frame-u umesto default-nih 5 ms. Ovo znaci da ce ucitavanje trajati duze, ali nece uzrokovati primetne hitches.
  • Koristimo FStreamableManager za prioritizaciju: geometrija i collision se ucitavaju prvi, teksture i detalji drugi.

• Texture Streaming Pool podesavanje:

  • Povecavamo pool sa 1024 MB na 1536 MB: r.Streaming.PoolSize=1536
  • Postavljamo r.Streaming.HLODStrategy=2 da HLOD teksture imaju nizi prioritet od blizih objekata
  • Smanjujemo max mip level za distant objekte: r.Streaming.MaxTempMemoryAllowed=128

• Preloading na osnovu kretanja: Implementiramo jednostavan sistem koji detektuje smer kretanja igraca i pre-loaduje cell-ove u tom smeru sa visim prioritetom.

Rezultat posle Koraka 4:

Streaming hitches:       < 2 ms  (bilo 80-120 ms)
Texture Pool Usage:      1280 MB / 1536 MB (u okviru budgeta)
RAM Usage:               10.8 GB (bilo 14.8 GB)
VRAM Usage:               5.4 GB (bilo 9.2 GB)

stat unit (worst case tokom kretanja):
Frame:    18.2 ms  (55 FPS worst case, obicno 56-58 FPS)

Korak 5: Nanite za stene i Shadow optimizacija

Problem: Stene imaju visok poly count sa tradicionalnim LOD-ovima koji nisu dovoljno dobri, i senke su skupe.

Resenje:

Primenjujemo principe iz Poglavlja 29 (Nanite -- Mikro-poligoni) i Poglavlja 43 (Optimizacija Osvetljenja):

• Nanite za rock formations:

  • Konvertujemo sve rock mesh-eve u Nanite mesh-eve
  • Nanite automatski upravlja LOD-ovima na per-cluster nivou
  • Ovo je idealan use case za Nanite: visoko detaljni, neprozirni, nepokretni objekti

• Shadow optimizacija:

  • Smanjujemo broj Cascaded Shadow Map kaskada sa 4 na 3
  • Far shadow cascade distance: 1000 m umesto 4000 m
  • Za objekte izvan 1000 m koristimo Distance Field Shadows umesto CSM (kako smo objasnili u Poglavlju 43)
  • Stene konvertovane u Nanite koriste Nanite-native shadow rendering, sto je efikasnije od tradicionalnog shadow map pristupa

• Virtual Shadow Maps (VSM): Aktiviramo VSM za Directional Light (detaljno u Poglavlju 44):

  • VSM automatski alocirani shadow map prostor samo tamo gde je potrebno
  • Za open world scenario, ovo je mnogo efikasnije od fiksnih CSM kaskada
  • Podesavamo r.Shadow.Virtual.MaxPhysicalPages=2048 za optimalan balans

Rezultat posle Koraka 5:

stat gpu:
Shadows                  2.1 ms  (bilo 5.8 ms, ustedeli 3.7 ms)
BasePass                 5.4 ms  (bilo 7.8 ms, zahvaljujuci Nanite)

stat unit:
Frame:    15.8 ms  (63 FPS)
GPU:      14.2 ms
Draw:      4.8 ms

2.5 Finalni rezultat

2.6 Kljucne lekcije iz Studije 2

1. Runtime Virtual Textures su nezamenjive za Landscape sa mnogo layer-a. Ako imas vise od 3-4 layer-a, RVT pristup ce znacajno poboljsati performanse.
2. Foliage je najcesci izvor overdraw-a u open world scenama. Agresivni cull distance-i i LOD-ovi su obavezni.
3. HLOD dramaticno smanjuje draw call-ove za distant content. World Partition HLOD pipeline je dizajniran bas za ovu svrhu -- koristi ga.
4. Streaming hitches se resavaju prevencijom, ne reakcijom. Ucitavaj ranije, ucitavaj manje po frame-u, i predvidjaj gde ce igrac ici.
5. Nanite je idealan za high-poly prirodne objekte poput stena, ali ne za sve -- foliage sa alpha masking-om i dalje zahteva tradicionalne pristupe.

Studija Slucaja 3: Urbana Scena -- Gusti Gradski Blok

3.1 Opis scene i zahtevi

Treci projekat je urbana scena za story-driven igru -- gusto naseljeni gradski blok sa zivotem na ulicama.

Karakteristike scene:

• Gradjevine: 28 zgrada razlicite velicine (od prizemnih lokala do 12-spratnica)
• Ulice: Asfaltirani putevi sa trotoarima, raskrsnicama, parking mestima
• Vozila: 45 parkiranih automobila, 8 pokretnih vozila (sa AI)
• NPC-jevi: 32 animirana NPC-a sa razlicitim ponasanjem (hodaju, sede, razgovaraju)
• Rekviziti (props): Hiljade malih objekata -- kante za smece, klupe, semafori, znakovi, stubovi, sanduke za struju, itd.
• Dinamicko osvetljenje: Directional Light (sunce) + 86 Point/Spot svetala za ulicne lampe, izloge, neon znakove
• Efekti: Particije (dim iz resetki, lisice, golubovi), decals na asfalt

Zahtevi:

3.2 Pocetno stanje

Art tim je zavrsio scenu i predao je za optimizaciju. Rezultati su zabrinjavajuci.

Pocetni stat unit rezultati:

Frame:    35.7 ms  (28 FPS)
Game:      6.8 ms
Draw:     14.2 ms
GPU:      22.4 ms
RHI:       7.6 ms

Pocetni stat gpu rezultati:

BasePass                 7.8 ms
Shadows                  6.2 ms
Lights                   3.4 ms
PostProcessing           2.1 ms
Translucency             1.3 ms
Reflections              1.1 ms
Velocity                 0.5 ms

Stat SceneRendering:

Mesh Draw Calls:        24,600
Visible Static Meshes:  16,200
Visible Skeletal Meshes:    40
Instanced Draw Calls:      890

3.3 Profilisanje

Ova scena ima visestruka uska grla -- cest slucaj u urbanim scenama:

CPU bottleneck -- Draw thread (14.2 ms):

Kao sto smo naucili u Poglavlju 42 (Draw Call-ovi i Batching), 24,600 draw call-ova je ogroman broj. Svaki mali prop (kanta, stub, znak) generise zasebni draw call. Problem nije u slozenosti pojedinacnog objekta, vec u ogromnom broju malih objekata.

Koristimo stat InitViews iz Poglavlja 38:

Frustum Cull:            2.8 ms
Process Visible:         4.1 ms
Init Dynamic Shadows:    3.6 ms

CPU trosi 3.6 ms samo na inicijalizaciju shadow setup-a za svaki objekat -- mnogi mali objekti generisu shadow maps.

GPU bottleneck -- Shadows (6.2 ms):

86 dinamickih svetala, od kojih mnoga bacaju senke. Svako svetlo sa senkama zahteva dodatni geometry pass za shadow map renderovanje. Kao sto smo detaljno objasnili u Poglavlju 22 (Osvetljenje i Senke), senke su najskuplji deo osvetljenja.

CPU bottleneck -- Game thread (6.8 ms):

Analiza pomocu stat Game:

Tick Time:               3.2 ms
AI Controller:           1.8 ms
Navigation:              0.9 ms
Physics:                 0.6 ms
Blueprint Tick:          0.3 ms

32 NPC-a sa AI kontrolerima i navigation tick-ovima doprinose Game thread opterecenju. Ovo smo obradili u Poglavlju 40 (CPU Optimizacija i Threading).

RHI overhead (7.6 ms):

RHI (Render Hardware Interface) thread je takodje visok. Ovo je direktna posledica velikog broja draw call-ova -- svaki draw call generise RHI komande koje moraju biti procesuirane.

3.4 Optimizacija

Korak 1: Nanite za zgrade

Problem: 28 zgrada sa visokim poly count-om generise veliki broj draw call-ova i teski BasePass.

Resenje:

Ovo je savrseni use case za Nanite (detaljno u Poglavlju 29):

• Konvertujemo svih 28 zgrada u Nanite mesh-eve

• Nanite automatski:

  • Upravlja LOD-ovima na per-cluster nivou (ne na per-mesh nivou)
  • Vrsi occlusion culling na GPU-u -- delovi zgrada koji su skriveni iza drugih zgrada se ne renderuju
  • Smanjuje efektivan broj trokuta koji se sadu na ekran

• Nanite i zgrade su idealan par jer:

  • Zgrade su neprozirne (Nanite ne podrzava transparentne materijale)
  • Zgrade su staticne (Nanite je optimizovan za staticnu geometriju)
  • Zgrade imaju visok poly count gde Nanite moze da pokaze svoju snagu

• Takodje konvertujemo trotoare, puteve i druge velike staticne objekte

Rezultat posle Koraka 1:

stat gpu:
BasePass                 3.2 ms  (bilo 7.8 ms, ustedeli 4.6 ms)

stat SceneRendering:
Mesh Draw Calls:        16,800   (bilo 24,600, smanjeno za 32%)

stat unit:
Frame:    28.4 ms  (35 FPS)
Draw:     10.8 ms  (bilo 14.2 ms)
GPU:      17.1 ms  (bilo 22.4 ms)

Korak 2: Instancing za ponovljene rekvizite

Problem: Hiljade malih props-ova generisu individualne draw call-ove. Mnogi od njih su identicni -- isti model kante, klupe, stuba.

Resenje:

Primenjujemo principe iz Poglavlja 31 (Foliage i Instanced Rendering) i Poglavlja 42 (Draw Call-ovi i Batching):

• Identifikujemo ponovljene objekte:

  • Kante za smece: 84 instance istog mesh-a
  • Ulicne lampe: 48 instanci
  • Semafori: 12 instanci
  • Parking metri: 24 instance
  • Klupe: 36 instanci
  • Ulicni znakovi: 56 instanci razlicitih tipova (ali svaki tip ima 4-8 instanci)

• Konvertujemo u Instanced Static Mesh Components:

  • Kreiramo Blueprint za svaki tip rekvizita koji koristi Instanced Static Mesh Component (ISM) ili Hierarchical Instanced Static Mesh Component (HISM) umesto individualnih Static Mesh Actor-a
  • ISM renderuje sve instance istog mesh-a u jednom draw call-u

• Merge Actor za male staticne objekte:

  • Manje vazne objekte koji nisu instancirani (jedinstveni rekviziti) grupujemo po blizini pomocu Merge Actors alata
  • Kreiramo merged mesh-eve za grupe objekata u istom "bloku" ulice

• Nanite za vece rekvizite: Vece rekvizite koji imaju dovoljno poligona (npr. kiosci, telefonske govornice) konvertujemo u Nanite.

Rezultat posle Koraka 2:

stat SceneRendering:
Mesh Draw Calls:         5,400   (bilo 16,800, smanjeno za 68%)
Instanced Draw Calls:    2,100   (bilo 890, povecano jer vise koristimo instancing)

stat unit:
Frame:    22.6 ms  (44 FPS)
Draw:      6.2 ms  (bilo 10.8 ms, ustedeli 4.6 ms)
RHI:       3.8 ms  (bilo 7.6 ms, ustedeli 3.8 ms)
GPU:      16.4 ms

Ogromno poboljsanje na CPU strani! Draw thread je skoro prepolovljen, a RHI overhead je dramaticno smanjen.

Korak 3: Shadow optimizacija

Problem: 86 dinamickih svetala, mnoga sa senkama, generise 6.2 ms GPU shadow cost i 3.6 ms CPU shadow initialization cost.

Resenje:

Primenjujemo principe iz Poglavlja 43 (Optimizacija Osvetljenja) i Poglavlja 22 (Osvetljenje i Senke):

• Klasifikacija svetala po vaznosti:

  • Tier 1 (kriticna): Directional Light (sunce/mesec) -- uvek shadow-casting
  • Tier 2 (vazna): 8 glavnih ulicnih lampi -- shadow-casting sa ogranicenim radijusom
  • Tier 3 (dekorativna): 78 preostalih svetala -- bez shadow casting-a

• Implementacija:

  • Na svih 78 Tier 3 svetala postavljamo Cast Shadows = false
  • Za Tier 2 svetla smanjujemo Shadow Resolution Scale na 0.5
  • Za Tier 2 svetla smanjujemo Shadow Max Distance na 30 metara (obicno su visina lampe + malo okoline dovoljni)

• Virtual Shadow Maps optimizacija:

  • Aktiviramo VSM za Directional Light
  • Postavljamo r.Shadow.Virtual.MaxPhysicalPages=1024
  • Podesavamo r.Shadow.Virtual.Clipmap.FirstCoarseLevel=3 da smanjimo rezoluciju daljih clipmap nivoa

• Contact Shadows: Umesto pravih shadow maps za male objekte, koristimo Screen Space Contact Shadows (r.ContactShadows=1) koji su mnogo jeftiniji i daju dovoljno dobar rezultat za male detalje.

• Mali objekti ne bacaju senke: Na svim merged mesh-ovima i instanciranim rekvizitima manjih dimenzija postavljamo Cast Shadow = false. Kanta za smece ne treba da baca senku -- niko nece primetiti razliku.

Rezultat posle Koraka 3:

stat gpu:
Shadows                  1.8 ms  (bilo 6.2 ms, ustedeli 4.4 ms)

stat InitViews:
Init Dynamic Shadows:    0.8 ms  (bilo 3.6 ms, ustedeli 2.8 ms)

stat unit:
Frame:    17.2 ms  (58 FPS)
GPU:      11.8 ms
Draw:      5.1 ms

Skoro smo na cilju!

Korak 4: NPC i Game thread optimizacija

Problem: 32 NPC-a sa AI kontrolerima trose 6.8 ms na Game thread-u.

Resenje:

Primenjujemo principe iz Poglavlja 40 (CPU Optimizacija i Threading) i Poglavlja 41 (Blueprint Optimizacija):

• Significance Manager: Implementiramo UE5 Significance Manager koji dodeljuje prioritete NPC-jevima na osnovu udaljenosti od igraca:

  • Bliski NPC-jevi (< 20 m): Full AI tick svaki frame, puna animacija
  • Srednji NPC-jevi (20-50 m): AI tick svaka 3 frame-a, animacija sa reduced bone count
  • Daleki NPC-jevi (> 50 m): AI tick svaka 10 frame-ova, LOD animacija

• AI optimizacija:

  • Navigation mesh recomputation: prebacujemo sa Dynamic na Static gde je moguce (ulice se ne menjaju)
  • EQS (Environment Query System) tick interval: sa 0.1s na 0.5s za Tier 2/3 NPC-jeve
  • Perception system: smanjujemo Sight radius sa 2000 na 500 za performans

• Animation Budget Allocator:

  • Koristimo Anim Budget Allocator plugin da automatski upravlja koliko animacijskih resursa svaki NPC dobija
  • Budget: max 4 ms za sve animacije kombinirane

• Tick Group organizacija:

  • NPC tick-ove stavljamo u TG_PostPhysics grupu
  • Koristimo SetTickGroup() i SetTickInterval() da raspodelimo opterecenje ravnomerno kroz frame-ove

Rezultat posle Koraka 4:

stat Game:
Tick Time:               1.4 ms  (bilo 3.2 ms)
AI Controller:           0.6 ms  (bilo 1.8 ms)
Navigation:              0.2 ms  (bilo 0.9 ms)

stat unit:
Frame:    15.4 ms  (64 FPS)
Game:      3.1 ms  (bilo 6.8 ms)
Draw:      5.0 ms
GPU:      11.7 ms

Korak 5: Merge small actors i finalno ciscenje

Problem: Jos uvek imamo 5,400 draw call-ova. Mozemo bolje.

Resenje:

Poslednji korak cisci preostale probleme:

• Actor Merging za staticne objekte:

  • Koristimo Merge Actors na grupama staticnih objekata po bloku ulice
  • Svaki blok ulice (trotoar + ograde + manja geometrija) postaje jedan merged mesh
  • Ovo smanjuje draw call-ove za jos ~1,500

• Decal optimizacija:

  • Mnogo decal-ova na asfaltu (fleke, pukotine, oznake) se preklapa
  • Smanjujemo broj decal-ova tako sto ih kombinujemo u vece decal atlase
  • Dodajemo Fade Screen Size da se manji decal-ovi ne renderuju na velikoj udaljenosti

• Lights attenuation radius tightening:

  • Svih 86 svetala dobijaju precizno podesene attenuation radius-e da se minimizuje overlap

• LOD za vozila:

  • Parkirana vozila dobijaju agresivne LOD-ove (LOD2 na 30 m udaljenosti)
  • Samo 8 pokretnih vozila zadrzavaju full LOD do vece udaljenosti

Rezultat posle Koraka 5:

stat SceneRendering:
Mesh Draw Calls:         3,800   (bilo 5,400)

stat unit:
Frame:    14.8 ms  (67 FPS)
Game:      3.0 ms
Draw:      4.2 ms
GPU:      11.2 ms

3.5 Finalni rezultat

3.6 Kljucne lekcije iz Studije 3

1. Urbane scene su cesto CPU-bound pre nego GPU-bound zbog ogromnog broja malih objekata. Nemoj se fokusirati samo na GPU -- Draw thread je jednako vazan.
2. Nanite je gamechanger za arhitektonsku geometriju. Zgrade, putevi, trotoari -- sve sto je staticno i neprozirno moze da koristi Nanite.
3. Instancing je najjeftiniji nacin da smanjis draw call-ove kada imas mnogo kopija istog objekta. Uvek prvo trazi ponovljene objekte.
4. Senke su luksuz koji treba selektivno dodeljivati. Vecina svetala u igri ne treba da baca senke. Samo kriticna svetla (sunce, glavno osvetljenje) zasluzuju pravu shadow map.
5. NPC tick management je kriticna vestina. Ne smej svakom NPC-u dati full tick svaki frame -- koristi Significance Manager za pametnu alokaciju resursa.

Studija Slucaja 4: VR Projekat -- Virtuelni Muzej

4.1 Opis scene i zahtevi

Cetvrti i poslednji projekat je VR iskustvo -- virtuelna galerija/muzej sa interaktivnim eksponatima. Ovo je najzahtevniji scenario jer VR ima ekstremne zahteve za performanse.

Karakteristike scene:

• Prostor: Muzejska galerija sa 5 prostorija povezanih hodnicima
• Eksponati: 40 visoko detaljnih 3D objekata (skulpture, mehanicke naprave, interaktivni modeli)
• Zidovi: Galerijski zidovi sa ramovima i umetnickim reprodukcijama (teksture)
• Osvetljenje: Profesionalno galerijsko osvetljenje (spot lights na eksponate, ambient osvetljenje)
• Interakcija: Igraci mogu da prilagodjavaju eksponate, otvaraju informativne panele, koristeVR kontrolere
• Audio: Prostorno pozicioniran audio za svaki eksponat

VR-specificni zahtevi:

Zasto je VR toliko zahtevan:

Kao sto smo detaljno objasnili u Poglavlju 48 (VR i AR Optimizacija), VR ima nekoliko fundamentalnih razlika od obicnog renderovanja:

1. Duplo renderovanje: Svaki frame se renderuje dva puta -- jednom za svako oko, sa malo razlicitom perspektivom
2. Visoka rezolucija: Kombinovana rezolucija oba oka na Quest 3 je 4128 x 2208 piksela -- vise od 4K!
3. 90 FPS minimum: Frame budget je samo 11.1 ms (1000 / 90). Za poredjenje, 60 FPS daje 16.67 ms -- imamo 33% manje vremena
4. Nema frame skip-ovanja: U obicnoj igri, povremeni drop na 50 FPS je prihvatljiv. U VR-u, svaki propusten frame moze izazvati mucninu
5. Latencija je kriticna: Svako kasnjenje izmedju pokreta glave i promene slike se oseca kao dezorijentacija

4.2 Pocetno stanje

Pocetni build scene sa Lumen osvetljenjem i standard rendering pipeline-om:

Pocetni stat unit rezultati (PC VR, Quest Link):

Frame:    22.2 ms  (45 FPS per eye)
Game:      1.8 ms
Draw:      4.6 ms
GPU:      21.4 ms
RHI:       3.2 ms

Pocetni stat gpu rezultati:

BasePass                 5.4 ms
Lumen GI                 4.8 ms
Lumen Reflections        3.2 ms
PostProcessing           3.1 ms
Shadows                  2.4 ms
Translucency             1.2 ms
StereoOverhead           1.3 ms

Sa 45 FPS po oku, daleko smo od 90 FPS cilja. Moramo skoro prepoloviti frame time sa 22.2 ms na 11.1 ms. Ovo je najagresivnija optimizacija u ovom poglavlju.

Dodatni problemi na Quest 3 standalone:

• Scena se uopste ne moze pokrenuti na standalone Quest 3 -- GPU je preslab za Lumen
• Moramo obezbediti dve verzije: PCVR i standalone

4.3 Profilisanje

GPU je dominantni bottleneck (21.4 ms).

Analiza po komponentama:

1. Lumen GI (4.8 ms) + Lumen Reflections (3.2 ms) = 8.0 ms samo za Lumen! Ovo je 72% naseg celog frame budget-a (11.1 ms). Lumen je fenomenalan za flat-screen renderovanje, ali za VR na 90 FPS je preskup. Kao sto smo naglasili u Poglavlju 48 (VR Optimizacija), Lumen trenutno nije prakticno za VR projekte na vecini hardware-a.

2. PostProcessing (3.1 ms): Screen space efekti su posebno skupi u VR-u jer se primenjuju na duplu rezoluciju. Mnogi od njih (Bloom, Lens Flare, Vignette) nisu ni potrebni u VR-u jer HMD vec ima sopstvene opticke karakteristike.

3. BasePass (5.4 ms): Materijali sa visokom rezolucijom tekstura i kompleksnim shader-ima.

4. Shadows (2.4 ms): Dinamicke senke za eksponate.

5. Stereo Overhead (1.3 ms): Overhead od dupliranja render pipeline-a za oba oka.

4.4 Optimizacija

Korak 1: Prelazak na baked osvetljenje

Problem: Lumen trosi 8.0 ms -- vise od celog naseg frame budget-a.

Resenje:

Ovo je radikalna ali neophodna odluka. Primenjujemo principe iz Poglavlja 22 (Osvetljenje i Senke) i Poglavlja 48 (VR Optimizacija):

• Iskljucujemo Lumen kompletno:

  • Project Settings > Rendering > Global Illumination > Method: None (za realtime GI)
  • Prelazimo na baked lighting pristup

• Lightmass baking:

  • Sva galerijska svetla (spot lights na eksponate) postavljamo na Static
  • Ambient osvetljenje: baked sa Volumetric Lightmap za indirektno osvetljenje
  • Lightmap rezolucija: 256 za podove, 128 za zidove, 64 za plafone
  • Lightmass Settings > Num Indirect Lighting Bounces: 4 za kvalitetno indirektno osvetljenje

• Lightmap UV-ovi: Proveravamo da svi mesh-evi imaju kvalitetne Lightmap UV-ove (Channel 1) bez overlapping-a. Koristimo Validate Lightmap UVs alat u Static Mesh editoru.

• Reflection Captures: Umesto Lumen refleksija, postavljamo:

  • 1 Sphere Reflection Capture u svaku prostoriju
  • 2-3 Box Reflection Capture za specificne oblasti (vitrine sa staklom)
  • Ovo su staticki cubemap-ovi -- besplatni za renderovanje, samo jedan texture lookup

• Kompromis: Gubimo dinamicko indirektno osvetljenje i refleksije u realnom vremenu, ali za muzejsku scenu to je prihvatljivo -- eksponati se ne menjaju, osvetljenje je fiksno. Ako nam treba interaktivno osvetljenje za posebne eksponate, dodajemo jedan ili dva dinamicka svetla samo za te objekte.

Rezultat posle Koraka 1:

stat gpu:
Lumen GI                 0.0 ms  (eliminisan!)
Lumen Reflections        0.0 ms  (eliminisan!)
Reflections              0.4 ms  (samo Reflection Capture lookup)
Shadows                  0.6 ms  (vecina staticna, baked)

stat unit:
Frame:    13.8 ms  (72 FPS per eye)
GPU:      12.6 ms

Ogromno poboljsanje! Ali jos nismo na cilju.

Korak 2: Prelazak na Forward Renderer sa MSAA

Problem: Default Deferred Renderer je dizajniran za scene sa mnogo dinamickih svetala. Nasa scena ima uglavnom baked osvetljenje, tako da Deferred Renderer ima nepotreban overhead.

Resenje:

Primenjujemo principe iz Poglavlja 21 (Rendering Pipeline -- Deferred vs Forward) i Poglavlja 48 (VR Optimizacija):

• Prebacujemo na Forward Renderer:

  • Project Settings > Rendering > Forward Shading: Enabled
  • Ovo eliminise G-Buffer pass i smanjuje bandwidth zahteve
  • Za scene sa pretezno baked osvetljenjem, Forward Renderer je efikasniji

• Anti-aliasing: MSAA umesto TAA:

  • U VR-u, Temporal AA (TAA) moze izazvati ghosting i blurriness koji je posebno primetan u HMD-u
  • Prelazimo na 4x MSAA koji daje ciscu sliku bez temporal artifacts
  • Project Settings > Rendering > Anti-Aliasing Method: MSAA
  • MSAA je dostupan samo u Forward Rendering modu

• Forward Rendering ogranicenja: Moramo prilagoditi scene:

  • Maksimum dinamickih svetala: smanjujemo na 4 (1 Directional + 3 za interaktivne eksponate)
  • Screen Space Reflections: nisu dostupne u Forward modu -- koristimo Reflection Captures
  • Decal-i: ograniceni u Forward modu -- koristimo mesh-based detalje umesto decal-ova

Rezultat posle Koraka 2:

stat gpu:
BasePass                 3.8 ms  (bilo 5.4 ms, usteda od Forward pipeline)

stat unit:
Frame:    12.4 ms  (80 FPS per eye)
GPU:      11.2 ms

Blizu smo! Ali trebaju nam jos ~1.3 ms da sigurno budemo ispod 11.1 ms sa marginom.

Korak 3: Agresivni LOD-ovi i redukcija post-processinga

Problem: Preostali GPU cost treba dodatno smanjiti.

Resenje:

Primenjujemo principe iz Poglavlja 30 (LOD -- Nivoi Detalja), Poglavlja 27 (Post-Processing Optimizacija) i Poglavlja 48 (VR Optimizacija):

• LOD za exponate:

  • Svaki eksponat dobija 3 LOD nivoa:
    • LOD0: Full detail (kamera unutar 3 m)
    • LOD1: 40% redukcija (3-8 m)
    • LOD2: 15% originalnog poly count-a (8+ m)
  • Za muzejsku scenu, korisnik ce uglavnom gledati jedan eksponat izbliza -- ostali mogu biti na LOD1/LOD2

• Screen Size LOD tranzicije: Koristimo Screen Size umesto udaljenosti za LOD tranzicije. Ovo je preciznije jer uzima u obzir velicinu objekta na ekranu, ne samo udaljenost.

• Post-processing cistka za VR:

  • Bloom: OFF (HMD ima sopstveni bloom od leca -- dodatan softverski bloom izgleda neprirodno)
  • Lens Flare: OFF (ovo simulira artefakte kamere -- u VR-u si "ti", ne kamera)
  • Motion Blur: OFF (HMD reprojection vec upravlja percepcijom pokreta)
  • Vignette: OFF (HMD vec ima prirodni vignette)
  • Film Grain: OFF (nepotrebno za VR)
  • Chromatic Aberration: OFF (HMD vec ima sopstvenu aberaciju)
  • Ambient Occlusion: Smanjujemo na Intensity = 0.3, Radius = 50
  • Auto Exposure: Fiksna ekspozicija umesto automatske (sprecava "pulsiranje" pri gledanju u razlicitim smerovima)

• Material simplifikacija:

  • Smanjujemo Num Texture Samples u materijalima za pod i zidove
  • Uklanjamo Detail Normal Maps (vidljivi su samo na veoma kratkoj udaljenosti)
  • Koristimo Fully Rough flag na materijalima koji ne trebaju specular refleksije

Rezultat posle Koraka 3:

stat gpu:
PostProcessing           0.8 ms  (bilo 3.1 ms, ustedeli 2.3 ms)
BasePass                 3.1 ms  (bilo 3.8 ms, ustedeli 0.7 ms)

stat unit:
Frame:    10.2 ms  (98 FPS per eye)
GPU:       9.1 ms

Sada smo sigurno iznad 90 FPS sa solidnom marginom od ~1 ms.

Korak 4: Instanced Stereo Rendering i VR-specificne optimizacije

Problem: Zelimo jos vecu marginu i pripremiti osnovu za Quest 3 standalone.

Resenje:

Primenjujemo napredne VR-specificne tehnike iz Poglavlja 48 (VR Optimizacija):

• Instanced Stereo Rendering (ISR):

  • Project Settings > Rendering > VR > Instanced Stereo: Enabled
  • ISR renderuje oba oka u jednom pass-u koristeci hardware instancing
  • Umesto dva potpuno odvojena render pass-a, geometrija se renderuje jednom sa dva viewport-a
  • Ovo smanjuje CPU draw call overhead za ~30% i GPU vertex processing za ~20%

• Round Robin Occlusion:

  • Project Settings > Rendering > VR > Round Robin Occlusion: Enabled
  • Occlusion query-ji se alterniraju izmedju ociju -- levo oko frame N, desno oko frame N+1
  • Ovo prepolovljuje CPU cost occlusion sistema bez vidljivog uticaja na kvalitet

• Hidden Area Mesh:

  • Aktiviramo VR.HiddenAreaMesh=1
  • Quest 3 (i vecina modernih HMD-ova) ima oblasti na ivicama leca koje korisnik ne vidi
  • Hidden Area Mesh maskira ove oblasti tako da se ne renderuju -- usteda od ~10-15% piksela

• Foveated Rendering koncept:

  • Quest 3 podrzava Fixed Foveated Rendering (FFR)
  • Centralni deo slike (gde oko prirodno gleda) se renderuje na punoj rezoluciji
  • Periferija se renderuje na nizoj rezoluciji
  • Na Quest 3 standalone postavljamo FFR Level = High:
    • Centar: 100% rezolucija
    • Srednja zona: 50% rezolucija
    • Periferija: 25% rezolucija
  • Usteda GPU cost-a od ~25-40% sa minimalnim vizuelnim uticajem (periferalni vid ima nizak acuity)

• Resolution scaling: Za PCVR, postavljamo render resolution na 1.0x native umesto default-nog 1.2x supersampling-a. Za muzejsku scenu, razlika je minimalna a usteda znacajna.

Rezultat posle Koraka 4:

stat unit:
Frame:     8.8 ms  (113 FPS per eye)
GPU:       7.6 ms
Draw:      2.8 ms
StereoOverhead:          0.4 ms  (bilo 1.3 ms)

Korak 5: Quest 3 Standalone prilagodjavanja

Za Quest 3 standalone (bez PC-ja), potrebne su dodatne agresivne optimizacije:

• Rezolucija: Smanjujemo render resolution na 0.8x native (Quest 3 ima upscaling)
• Texture rezolucije: Maksimalna tekstura: 1024x1024 (umesto 2048 ili 4096)
• Poly budget: Maximum 500K trokuta na ekranu
• Shader complexity: Single layer materijali, bez parallax mapping-a
• Fixed Foveated Rendering: Level = High
• Dynamic lights: Maksimum 1 (samo za interaktivni eksponat koji korisnik aktivno gleda)
• Shadow-i: Samo baked -- nema dinamickih senki na standalone-u
• Particle efekti: Minimalni -- samo esencijalni za interakciju

Quest 3 Standalone rezultat:

Frame:    10.5 ms  (95 FPS per eye)
GPU:       9.2 ms
Memory:    2.8 GB  (Quest 3 ima ~4 GB dostupno)

4.5 Finalni rezultat (PCVR)

4.6 Kljucne lekcije iz Studije 4

1. Lumen i VR trenutno ne idu zajedno. To se moze promeniti u buducim verzijama UE5, ali za sada, baked lighting je jedini pouzdan pristup za 90 FPS VR.
2. Forward Renderer je superioran za VR sa pretezno staticnim osvetljenjem. Manji bandwidth, cisci anti-aliasing sa MSAA, manje latencije.
3. Vecina post-process efekata nema smisla u VR-u. Bloom, Lens Flare, Motion Blur, Film Grain -- sve ovo simulira kameru, a VR simulira oci. Ukloni ih bez zaljenja.
4. Instanced Stereo Rendering je besplatno poboljsanje. Nema razloga da ga ne ukljucis u svakom VR projektu.
5. Foveated Rendering je buducnost VR performansi. Sa eye-tracking-om, ova tehnika postaje jos mocnija jer se rezolucija dinamicki prilagodjava gde korisnik zaista gleda.
6. VR zahteva drugaciji mindset. Svaki milisekund se broji. Nema kompromisa oko frame rate-a -- 90 FPS ili nista.

Uporedna Analiza -- Sta Smo Naucili Iz Cetiri Studije

Pogledajmo sva cetiri scenarija uporedo i izdvojimo zajednicke obrasce:

Zajednicki obrasci

Univerzalna pravila

Iz svih cetiri studija slucaja, mozemo izvuci nekoliko univerzalnih pravila koja vaze za svaki UE5 projekat:

1. Uvek profiliraj pre nego sto optimizujes. Bez merenja, ne znas gde je problem. Mozda potrosis dane optimizujuci GPU dok je tvoj pravi bottleneck na CPU-u.

2. Optimizuj najveci problem prvo. Pogledaj stat unit i kreni od najviseg broja. Nema smisla ustedi 0.5 ms na post-processingu ako lighting trosi 12 ms.

3. Osvetljenje je skoro uvek na vrhu liste. U tri od cetiri studije, optimizacija osvetljenja je bila najvazniji korak.

4. Draw call-ovi su "tihi ubica" performansi. Jedan model sa 100K trokuta je jeftiniji od 100 modela sa po 1K trokuta (sa stanovista CPU-a). Instancing, merging i HLOD su tvoji prijatelji.

5. Texture streaming je infrastruktura koja se cesto zanemaruje. Pravilno konfigurisan streaming pool i texture velicine mogu eliminisati hitches bez ikakvog vizuelnog kompromisa.

6. LOD nije opcija -- obavezan je. Svaki mesh u projektu treba LOD-ove. Bez izuzetka. Cak i u archviz-u.

7. Svaki piksel koji se renderuje a niko ga ne vidi je bacen posao. Culling, occlusion, hidden area masking -- sve ovo eliminise nevidljiv rad.

Tabela Kljucnih Pojmova

Zavrsne Misli -- Optimizacija Kao Neprekidni Proces

Dosao si do samog kraja ove knjige. Pedeset poglavlja, stotine strana, bezbroj tehnickih detalja. Ali zelim da te ostavim sa najvaznijom lekcijom od svih:

Optimizacija nije jednokratan dogadjaj. To je proces.

Svaki put kada dodas novi sadrzaj u scenu, svaki put kada promenis materijal, svaki put kada ukljucis novi efekat -- performanse se menjaju. Projekat koji danas radi na 60 FPS moze sutra raditi na 45 FPS jer je neko dodao "samo jednu malu stvar".

Zato je vazno uspostaviti kulturu performansi u svom timu:

1. Redovno profiliraj. Nemoj cekati kraj projekta. Profiliaj svake nedelje, idealno svaki dan. Koristis stat unit kao sto koristis rucni sat -- cesto i bez razmisljanja.

2. Postavi budgete rano. Pre nego sto pocnes sa razvojem, odluci: koliki je frame budget? Koliko draw call-ova mozemo imati? Kolika je maksimalna tekstura? Ovi budgeti su temelj svih odluka.

3. Automatizuj testiranje performansi. Napravi automated performance test koji prolazi kroz kljucne delove scene i belezi FPS, frame time, memoriju. Pokreci ga kao deo CI/CD pipeline-a.

4. Nemoj optimizovati prerano -- ali ne cekaj ni prekasno. "Premature optimization is the root of all evil" (Donald Knuth) je tacno, ali isto tako je tacno da optimizacija na kraju projekta kosta 10x vise nego optimizacija tokom razvoja. Pravi balans je u redovnom prasjenju i ranim korekcijama.

5. Uci iz svake studije slucaja. Svaki projekat je drugaciji, ali obrasci se ponavljaju. Sto vise scenarija vidis, sto vise problema resis, bices brzi i precizniji u identifikaciji i resavanju performansnih problema.

6. Prati razvoj UE5. Epic Games konstantno poboljsava engine. Nanite danas ne podrzava transparentne materijale -- mozda ce sutra. Lumen danas ne moze 90 FPS za VR -- mozda ce sledeca verzija moci. Budi u toku sa novostima.

Ako si prosao sve sto ova knjiga nudi -- od osnova renderovanje pipeline-a, preko profilisanja i dijagnostike, do naprednih tehnika optimizacije -- onda imas alate da se nosis sa bilo kojim performansnim izazovom u Unreal Engine 5.

Srecno kodiranje, i neka tvoji frame-ovi budu brzi od svetlosti.

Korisni Linkovi i Dalje Citanje

Zvanicna Dokumentacija

• Unreal Engine 5 Documentation -- Performance and Profiling: https://docs.unrealengine.com/5.0/en-US/performance-and-profiling-in-unreal-engine/

• Nanite Virtualized Geometry: https://docs.unrealengine.com/5.0/en-US/nanite-virtualized-geometry-in-unreal-engine/

• Lumen Global Illumination and Reflections: https://docs.unrealengine.com/5.0/en-US/lumen-global-illumination-and-reflections-in-unreal-engine/

• Virtual Shadow Maps: https://docs.unrealengine.com/5.0/en-US/virtual-shadow-maps-in-unreal-engine/

• World Partition: https://docs.unrealengine.com/5.0/en-US/world-partition-in-unreal-engine/

• VR Development in Unreal Engine: https://docs.unrealengine.com/5.0/en-US/developing-for-xr-experiences-in-unreal-engine/

Epic Games Learning Resources

• Unreal Engine Learning Portal: https://dev.epicgames.com/community/unreal-engine/learning

• Unreal Engine YouTube Channel: https://www.youtube.com/@UnrealEngine

• Unreal Fest Presentations (Performance Talks): https://www.youtube.com/results?search_query=unreal+fest+performance+optimization

Community Resources

• Unreal Engine Forums -- Performance Section: https://forums.unrealengine.com/categories?tag=performance

• r/unrealengine (Reddit): https://www.reddit.com/r/unrealengine/

Preporucene Knjige

• Real-Time Rendering (Tomas Akenine-Moller, Eric Haines, Naty Hoffman) -- Biblija rendering-a. Ako zelis da razumes STA se desava ispod haube engine-a, ovo je knjiga za tebe.

• GPU Gems Series (NVIDIA) -- Besplatne online knjige sa naprednim tehnikama. Dostupne na developer.nvidia.com.

• Game Engine Architecture (Jason Gregory) -- Fantastican pregled kako game engine-i funkcionisu na sistemskom nivou.

Alati za Profilisanje (van UE5)

• RenderDoc: Open-source GPU debugger koji moze da uhvati i analizira svaki draw call. https://renderdoc.org/

• NVIDIA Nsight Graphics: Napredni GPU profiler za NVIDIA graficke kartice. https://developer.nvidia.com/nsight-graphics

• PIX (Windows): Microsoft-ov GPU profiler za DirectX 12 aplikacije. https://devblogs.microsoft.com/pix/

• AMD Radeon GPU Profiler: Za AMD graficke kartice. https://gpuopen.com/rgp/

Ovo je bilo poslednje poglavlje knjige "Unreal Engine 5: Od Nule do Heroja". Hvala ti sto si bio sa nama na ovom putovanju. Sada idi i napravi nesto neverovatno.