Poglavlje 35: Niagara Particle System

Uvod -- zasto su nam cestice uopste potrebne?

Zamislite scenu u vasoj igrici: heroj baca vatrenu magiju prema neprijatelju. Bez vizuelnih efekata, videli biste samo kako neprijatelj odjednom gubi zdravlje. Dosadno, zar ne? Ali kada dodate plamen koji se siri, iskre koje lete na sve strane, dim koji se dize, svetlost koja treperi -- scena odjednom ozivi. To je posao cestica (particles).

U ovom poglavlju cemo detaljno proci kroz Niagara Particle System -- Unreal Engine 5 sistem za cestice koji je zamenio stariji Cascade sistem. Niagara je mocniji, fleksibilniji i potpuno data-driven, sto znaci da imate kontrolu nad bukvalno svakim aspektom ponasanja cestica.

Pripremite se -- ovo je jedno od duzih poglavlja, ali kada ga zavrsiste, mocicete da kreirate sve od jednostavnog dima do kompleksnih magicnih efekata.

35.1 Sta su cestice (Particles)?

Cestice su mali vizuelni elementi koji se pojavljuju u velikom broju i zajedno stvaraju vizuelni efekat. Pojedinacna cestica je obicno jednostavan oblik -- ravni cetvorougao (quad), 3D mesh ili traka (ribbon) -- ali kada ih imate stotine ili hiljade, one zajedno formiraju slozene efekte.

35.1.1 Tipovi vizuelnih efekata koje cestice stvaraju

Evo pregleda najcescih efekata koji se postizu cesticama:

35.1.2 Vizuelni oblici cestica

Svaka pojedinacna cestica moze biti prikazana na razlicite nacine:

• Sprite: ravni cetvorougao (quad) koji je uvek okrenut prema kameri (billboard). Ovo je najcesci tip.
• Mesh: pun 3D model za svaku cesticu -- koristite ovo za komade rasprsnutog objekta (debris), case za metke (shell casings), lisce koje pada.
• Ribbon / Trail: povezana traka koja prati putanju cestice -- idealna za tragove metaka, munje, magicne tragove.
• Light: svaka cestica emituje svetlost. Izuzetno skup tip renderovanja -- o tome vise kasnije.

Detaljno cemo obraditi svaki tip renderovanja u sekciji 35.5.

35.2 Niagara arhitektura

Niagara je dizajnirana sa jasnom hijerarhijskom strukturom. Razumevanje ove strukture je kljucno za efikasan rad.

35.2.1 System (Sistem)

Niagara System je najvisi nivo organizacije -- to je kontejner koji moze da sadrzi jedan ili vise emittera. Kada postavite efekat u level, vi zapravo postavljate System.

Razmisljajte o System-u kao o "sceni" u filmskom smislu. Scena eksplozije se ne sastoji samo od vatre -- tu su i dim, iskre, debris, svetlost, udarni talas. Svaki od tih elemenata je zaseban emitter, ali svi zive unutar jednog System-a.

Niagara System: "NS_Explosion"
├── Emitter: "Fire"
├── Emitter: "Smoke"  
├── Emitter: "Sparks"
├── Emitter: "Debris"
├── Emitter: "Shockwave"
└── Emitter: "Light"

Kljucne karakteristike System-a:

• Ima sopstvene parametre (System Parameters) koji mogu biti deljeni izmedju svih emittera
• Ima sopstveni Spawn i Update lifecycle
• Moze kontrolisati redosled renderovanja emittera unutar sebe
• Moze biti instanciran vise puta u sceni, svaki sa razlicitim parametrima

35.2.2 Emitter (Emiter)

Emitter definise jednu vrstu ponasanja cestica. Svaki emitter ima svoj zivotni ciklus, svoje module i svoje postavke renderovanja.

Emitter odredjuje:

• Koliko cestica se stvara (spawn rate, burst count)
• Kako se cestice ponasaju (brzina, pravac, gravitacija, boja, velicina)
• Koliko dugo cestice zive (lifetime)
• Kako se cestice prikazuju (sprite, mesh, ribbon, light)

Emitter se moze sacuvati kao Niagara Emitter asset i koristiti u vise razlicitih System-a. Na primer, mozete napraviti genericki emitter za iskre i koristiti ga u sistemu za eksploziju, sistemu za udarac maca i sistemu za elektricni kvar.

Saveti za organizaciju emittera:

1. Imenujte emittere opisno: "Fire_Core", "Smoke_Rising", "Sparks_Radial"
2. Grupisajte povezane emittere u isti System
3. Koristite emitter inheritance kada imate slicne emittere sa malim razlikama
4. Drzite broj emittera po sistemu razumnim -- svaki emitter ima overhead

35.2.3 Modules (Moduli)

Moduli su srcani deo Niagara sistema. To su reusable blokovi logike koji definisu ponasanje cestica.

Svaki modul je zapravo mali program (napisan u Niagara Module Script jeziku, koji je vizuelni graph ili HLSL) koji se izvrsava u odredjenom trenutku zivotnog ciklusa cestice.

Primeri ugradjenih modula:

Pisanje custom modula:

Niagara vam dozvoljava da pisete sopstvene module koristeci:

1. Niagara Module Script Editor -- vizuelni graph editor, slican Blueprint-u ali optimizovan za matematicke operacije nad cesticama
2. HLSL Custom Expressions -- za napredne korisnike koji zele da pisu shader code direktno

Custom modul moze pristupiti:

• Parametrima cestice (pozicija, brzina, boja, velicina, starost, itd.)
• Parametrima emittera (spawn rate, emitter age, itd.)
• Parametrima sistema (system age, pozicija sistema, itd.)
• Eksternim parametrima (prosledjeni iz Blueprint-a ili C++ koda)

35.2.4 Module Stack (Stek modula)

Moduli nisu nasumicno rasporedeni -- oni se izvrsavaju po redosledu, od vrha ka dnu, u takozvanom module stack-u. Redosled je bitan!

Na primer, u Particle Update fazi:

Particle Update Stack:
1. Gravity Force          -- dodaje gravitacionu silu
2. Wind Force             -- dodaje silu vetra
3. Drag                   -- primenjuje otpor
4. Curl Noise Force       -- dodaje turbulenciju
5. Solve Forces and Velocity  -- izracunava konacnu poziciju
6. Scale Color            -- menja boju prema starosti
7. Scale Sprite Size      -- menja velicinu prema starosti
8. Kill Particles in Volume   -- ubija cestice van zone

Zasto je redosled bitan?

Zamislite da stavite Solve Forces and Velocity PRE Gravity Force. U tom slucaju, gravitacija bi bila primenjena tek u sledecem frame-u, sto bi dovelo do jednofremovskog kasnjenja u fizici. Niagara uglavnom stavlja Solve Forces and Velocity na kraj fizickih kalkulacija, ali vi ste odgovorni za pravilan redosled vasih custom modula.

Pravilo palca za redosled:

1. Prvo sile (gravity, wind, drag, noise)
2. Zatim resavanje sila (Solve Forces and Velocity)
3. Zatim vizuelne promene (boja, velicina, rotacija)
4. Na kraju uslovno unistavajte cestice (kill conditions)

35.2.5 Data-Driven pristup

Ovo je mozda najvaznija filozofska razlika izmedju Niagare i starijeg Cascade sistema. U Niagari, sve je parametar i sve moze biti skriptovano.

Sta to znaci u praksi?

1. Svaki atribut cestice je podatak: pozicija, brzina, boja, velicina, rotacija, lifetime -- sve su to promenljive (attributes) koje mozete citati i menjati iz bilo kog modula.

2. Parametri se mogu eksponirati: mozete napraviti parametre koji su vidljivi u Blueprint-u ili Details panelu, tako da dizajneri mogu podesavati efekat bez otvaranja Niagara editora.

3. Dynamic Inputs: umesto statickih vrednosti, mozete koristiti dinamicke ulaze -- krive (curves), random range-ove, matematicke izraze, pa cak i custom module script-ove za izracunavanje vrednosti.

4. Parameter Binding: parametri iz razlicitih nivoa (System, Emitter, Particle) mogu biti medjusobno povezani.

Primer hijerarhije parametara:

System Parameter: "ExplosionScale" = 2.0
    │
    ├── Emitter "Fire" cita ExplosionScale za spawn rate
    ├── Emitter "Smoke" cita ExplosionScale za velicinu cestica
    └── Emitter "Debris" cita ExplosionScale za pocetnu brzinu

5. Namespace sistem: Niagara koristi namespace-ove za organizaciju parametara:
   • System. -- parametri na nivou sistema
   • Emitter. -- parametri na nivou emittera
   • Particles. -- atributi pojedinacnih cestica
   • Engine. -- Engine-provided vrednosti (DeltaTime, itd.)
   • User. -- korisnicki definisani parametri (eksponurani za Blueprint)
   • Transient. -- privremene vrednosti koje se ne cuvaju izmedju frame-ova

Ovaj data-driven pristup znaci da mozete napraviti jedan System "NS_GenericExplosion" i onda ga koristiti za male eksplozije granata, srednje eksplozije automobila i ogromne eksplozije zgrada -- samo menjajuci User parametre.

35.3 Simulation Stages (Faze simulacije)

Niagara simulacija se odvija u tacno definisanim fazama (stages). Razumevanje ovih faza je apsolutno kriticno za pravilan rad sa sistemom.

35.3.1 Pregled svih faza

Redosled izvrsavanja po frame-u:

1. System Spawn    (samo prvi frame)
2. System Update   (svaki frame)
3. Emitter Spawn   (samo prvi frame emittera)
4. Emitter Update  (svaki frame)
5. Particle Spawn  (za svaku novu cesticu)
6. Particle Update (za svaku zivu cesticu, svaki frame)
7. Render          (definise kako se cestice crtaju)

Hajde da detaljno prodjemo kroz svaku fazu.

35.3.2 System Spawn

Kada se izvrsava: Jednom, kada se System prvi put kreira (instancira u svetu).

Cemu sluzi: Inicijalizacija system-level podataka. Ovde postavljate pocetne vrednosti za System parametre.

Tipicni moduli:

• Postavljanje pocetnih vrednosti system parametara
• Izracunavanje vrednosti koje zavise od uslova pri spawn-u (npr. velicina eksplozije na osnovu tipa projektila)

Primer:

System Spawn:
├── Set System Parameter "BaseScale" = 1.0
├── Set System Parameter "TotalDuration" = 3.0
└── Custom Module: Calculate scale from input damage

35.3.3 System Update

Kada se izvrsava: Svaki frame, jednom za ceo sistem.

Cemu sluzi: Logika na nivou sistema koja treba da se azurira svaki frame. Moze kontrolisati ponasanje svih emittera.

Tipicni moduli:

• Kontrola lifecycle-a sistema (auto-deactivation posle odredjenog vremena)
• Globalne sile koje uticu na sve emittere
• Komunikacija sa Blueprint-om (citanje eksternih parametara)
• Azuriranje deljenih parametara

Primer:

System Update:
├── System State: manage lifetime, loop, auto-deactivate
├── Update system-level curl noise offset
└── Read Blueprint parameter "WindDirection"

35.3.4 Emitter Spawn

Kada se izvrsava: Jednom, kada se emitter prvi put aktivira.

Cemu sluzi: Inicijalizacija emitter-level podataka.

Tipicni moduli:

• Postavljanje spawn rate-a
• Inicijalizacija emitter-specificnih parametara
• Postavljanje emitter lifetime-a

Primer:

Emitter Spawn (Emitter: "Smoke"):
├── Set Emitter Parameter "SpawnRate" = 50
├── Set Emitter Parameter "EmitterLifetime" = 2.0
└── Set Emitter Parameter "ParticleBaseSize" = 30.0

35.3.5 Emitter Update

Kada se izvrsava: Svaki frame, jednom po emitteru.

Cemu sluzi: Kontrola emittera -- koliko cestica spawn-ovati ovaj frame, da li je emitter aktivan, logika koja se tice emittera ali ne i pojedinacnih cestica.

Tipicni moduli:

• Emitter State -- upravlja zivotnim ciklusom emittera (active, inactive, complete)
• Spawn Rate -- koliko cestica po sekundi
• Spawn Burst Instantaneous -- odjednom kreira N cestica
• Spawn Per Frame -- kreira fiksni broj cestica po frame-u
• Spawn Per Unit -- kreira cestice na osnovu predjenog rastojanja (korisno za tragove)

Spawn mehanizmi detaljno:

Kombinovanje spawn mehanizama:

Mozete imati vise spawn modula u istom emitteru. Na primer, efekat vatre moze imati:

• Spawn Burst sa 20 cestica na pocetku (pocetni plamen)
• Spawn Rate sa 10 cestica/sek (kontinualno gorenje)

35.3.6 Particle Spawn

Kada se izvrsava: Jednom za svaku novu cesticu, u trenutku njenog kreiranja.

Cemu sluzi: Inicijalizacija atributa pojedinacne cestice. Ovo je trenutak kada cestica "dobija" svoje pocetne osobine.

Tipicni moduli:

Shape Location -- odakle se cestice radjaju:

Ovo je jedan od najvaznijih modula. Definise geometrijski oblik iz kojeg se cestice spawn-uju:

• Point: sve cestice se radjaju na istoj tacki
• Sphere: cestice se radjaju na povrsini ili unutar sfere
• Box: cestice se radjaju unutar kutije
• Cylinder: korisno za efekte poput vodopada, dimnjaka
• Torus: prsten -- korisno za magicne krugove, portale
• Cone: konus -- idealno za mlazeve, plamene bacace
• Mesh Surface: cestice se radjaju na povrsini statickog mesh-a
• Skeletal Mesh Surface: cestice se radjaju na povrsini animiranog mesh-a (npr. lik koji gori)
• Spline: cestice prate spline putanju
• Grid: pravilna mreza cestica

Primer kompletnog Particle Spawn stack-a:

Particle Spawn:
├── Initialize Particle
│   ├── Lifetime: Random Range (1.0 - 2.5)
│   ├── Mass: 1.0
│   ├── Sprite Size: Random Range (10 - 30)
│   ├── Color: (1.0, 0.5, 0.1, 1.0)  -- narandzasta
│   └── Sprite Rotation: Random Range (0 - 360)
├── Shape Location: Sphere
│   ├── Sphere Radius: 20
│   └── Surface Only: false
├── Add Velocity: Cone
│   ├── Speed: Random Range (100 - 300)
│   ├── Cone Angle: 30 degrees
│   └── Direction: (0, 0, 1)  -- nagore
└── Set (Particles.SubImageIndex): Random Integer (0 - 15)

35.3.7 Particle Update

Kada se izvrsava: Svaki frame, za svaku zivu cesticu.

Cemu sluzi: Azuriranje stanja cestica -- primena fizike, promena boje, velicine, provera uslova za unistavajnje.

UPOZORENJE O PERFORMANSAMA: Ovo je najskuplja faza jer se izvrsava za svaku cesticu, svaki frame. Ako imate 1000 cestica i 10 modula u Particle Update, to je 10,000 izvrsavanja modula po frame-u. Budite pazljivi sa kompleksnoscu modula ovde!

Tipicni moduli (u preporucenom redosledu):

Particle Update:
│
│  -- SILE --
├── Gravity Force              -- gravitacija
├── Wind Force                 -- vetar
├── Drag                       -- otpor vazduha
├── Curl Noise Force           -- organska turbulencija
├── Point Attraction Force     -- privlacenje ka tacki
├── Vortex Force               -- vrtlozno kretanje
│
│  -- RESAVANJE FIZIKE --
├── Solve Forces and Velocity  -- izracunava konacnu poziciju
│
│  -- KOLIZIJA --
├── Collision (opcionalno)     -- kolizija sa svetom
│
│  -- VIZUELNE PROMENE --
├── Scale Color                -- promena boje tokom zivota
├── Scale Sprite Size          -- promena velicine tokom zivota
├── Sprite Rotation Rate       -- rotacija tokom vremena
├── Sub Image Animation        -- animacija sprite sheet-a
│
│  -- USLOVNO UNISTAVAJNJE --
├── Kill Particles in Volume   -- ubij van odredjene zone
└── (Implicit) Kill on Lifetime -- automatski kada istekne lifetime

Scale Color -- kriva boje tokom zivota:

Jedan od najcescih vizuelnih trikova. Na primer, za cesticu vatre:

• Na pocetku (age = 0): jarka zuta boja sa punim alpha
• Na sredini (age = 0.5): narandzasta boja
• Pred kraj (age = 0.9): tamnocrvena sa smanjenim alpha
• Na samom kraju (age = 1.0): crna sa alpha = 0 (potpuno providna)

Ovo se postize koristeci Curve (krivu) kao Dynamic Input za Scale Color modul.

Curl Noise Force -- organska turbulencija:

Ovo je modul koji daje cesticama prirodno, organsko kretanje. Bez njega, dim izgleda kao ravna kolona cestica koje idu pravo gore. Sa Curl Noise-om, cestice dobijaju blage, vijugave putanje koje mnogo vise lice na pravi dim.

Curl Noise parametri:

• Noise Strength: koliko jako utice na kretanje (vece = haotocnije)
• Noise Frequency: frekvencija suma (veca = sitnije kovrdzanje)
• Noise Quality: kvalitet suma (visi = sporiji ali lepsi)
• Pan Noise Field: da li se polje suma pomera tokom vremena

35.3.8 Render Stage

Sta radi: Definise kako se cestice vizuelno prikazuju. Ovo nije "simulacioni" korak u smislu da ne menja ponasanje cestica -- vec samo odredjuje njihov vizuelni prikaz.

Render stage se konfigurse dodavanjem Renderer modula u Render section emittera. Detaljno cemo obraditi tipove renderera u sekciji 35.5.

Vazan koncept -- Render stage ne menja simulaciju:

Render moduli citaju atribute cestica (pozicija, boja, velicina, rotacija) ali ih ne menjaju. To znaci da mozete promeniti renderer iz Sprite u Mesh bez ikakve promene u simulacionoj logici.

35.4 GPU Particles vs CPU Particles

Ovo je jedna od najvaznijih odluka koje donosite kada pravite particle efekat. Hajde da detaljno razmotrimo obe opcije.

35.4.1 CPU Particles

Kako rade: Simulacija cestica se izvrsava na CPU-u (procesoru). Svaki frame, CPU prolazi kroz sve zive cestice, izvrsava sve module, azurira pozicije, boje, velicine, i salje rezultate GPU-u za renderovanje.

Prednosti CPU cestica:

1. Potpuna fleksibilnost: mozete koristiti bilo koju logiku, pristupati bilo kojim podacima, pozivati Blueprint funkcije
2. Kolizija sa svetom: CPU cestice mogu koristiti line trace za preciznu koliziju i dobiti nazad informacije (normal, physical material, itd.)
3. Interakcija sa gameplay-om: mozete reagovati na koliziju -- npr. cestica pogodi pod i spawn-uje novu "splash" cesticu
4. Event sistem: CPU cestice mogu generisati evente koje drugi emitteri (ili Blueprint) mogu slusati
5. Pristup podacima: mogu citati podatke iz Data Interface-ova (mesh surface, spline, itd.)
6. Debugging: lakse je debugovati CPU simulaciju

Ogranicenja CPU cestica:

1. Limitiran broj: prakticni limit je nekoliko hiljada cestica po sistemu (zavisi od kompleksnosti modula i CPU budgeta)
2. CPU overhead: zauzimaju CPU vreme koje bi moglo biti iskorisceno za gameplay logiku, AI, fiziku
3. Skaliranje: ne skaliraju se dobro -- duplo vise cestica = duplo vise CPU posla
4. Thread contention: mogu se takmiciti sa drugim CPU taskovima za procesorsko vreme

35.4.2 GPU Particles

Kako rade: Simulacija cestica se izvrsava na GPU-u koristeci compute shader-e. CPU samo salje komande ("spawn 100 cestica sa ovim parametrima"), a GPU radi svu tezak posao paralelno.

O tome kako compute shader-i rade govori Poglavlje 08 u sekciji o GPU compute pipeline-u.

Prednosti GPU cestica:

1. Masivan broj cestica: mozete imati milione cestica jer GPU ima hiljade jezgara koja rade paralelno
2. Manji CPU overhead: CPU samo salje minimalne komande, ne radi simulaciju
3. Paralelizam: GPU je dizajniran za ovakav tip posla -- ista operacija nad ogromnim brojem elemenata (SIMD paradigma)
4. Performanse po cestici: svaka pojedinacna cestica je "jeftinija" na GPU-u

Ogranicenja GPU cestica:

1. Ograniceni moduli: ne mogu svi moduli raditi na GPU-u. Neki zahtevaju CPU funkcionalnost
2. Nema kolizije sa gameplay svetom: GPU cestice ne mogu raditi line trace. Kolizija je ogranicena na:
   • Depth Buffer Collision: kolizija sa onim sto kamera vidi (ne radi iza kamere, netacno na ivicama objekata)
   • Distance Field Collision: kolizija sa Global Distance Field-om (Poglavlje 09), bolje ali zahteva SDF generisanje
3. Nema event callback-ova: ne mozete reagovati na koliziju u Blueprint-u -- nema "OnParticleCollision" eventa
4. Ogranicen pristup podacima: ne mogu citati proizvoljne CPU podatke
5. Latencija: postoji jedan frame kasnjenja za GPU readback (ako vam trebaju podaci nazad na CPU)
6. Debugging: teze je debugovati GPU simulaciju

35.4.3 GPU kolizija detaljno

Posto GPU cestice ne mogu koristiti line trace, Niagara nudi alternativne metode kolizije:

Depth Buffer Collision:

Kako radi:
1. GPU renderuje scenu u depth buffer (Z-buffer)
2. Za svaku cesticu, projektujem njenu poziciju na screen space
3. Uporedjujem dubinu cestice sa dubinom u depth buffer-u
4. Ako je cestica "iza" geometrije u depth buffer-u, doslo je do kolizije

Prednosti:

• Brzo, koristi vec postojeci depth buffer
• Radi sa svom vidljivom geometrijom

Mane:

• Ne radi za cestice van ekrana (iza kamere, van frustuma)
• Neprecizno na ivicama objekata (edge artifacts)
• Zavisi od rezolucije depth buffer-a
• Ne moze detektovati koliziju sa tankim objektima

Distance Field Collision:

Kako radi:
1. Engine generise Global Distance Field (SDF) za staticnu geometriju
2. Za svaku cesticu, sampluje SDF na njenoj poziciji
3. Ako je SDF vrednost <= 0, cestica je unutar geometrije (kolizija)
4. Gradijent SDF-a daje normalu kolizije za odbijanje

Prednosti:

• Radi u svim pravcima (ne zavisi od kamere)
• Preciznija od depth buffer metode
• Daje normalu za odbijanje

Mane:

• Zahteva generisanje Distance Field-a (kosta memoriju i vreme)
• Rezolucija SDF-a je ogranicena -- ne hvata sitne detalje
• Dinamicki objekti ne uce u Global Distance Field po default-u
• Zahteva da je opcija "Generate Mesh Distance Fields" ukljucena u Project Settings

35.4.4 Kada koristiti koji tip?

Prakticna preporuka:

Pocnite sa GPU cesticama i predjite na CPU samo ako vam treba nesto sto GPU ne moze (collision callback, event, kompleksni data access). Vecina vizuelnih efekata ne zahteva interakciju sa gameplay-om i moze lepo raditi na GPU-u.

Hibridni pristup:

Mozete kombinovati oba tipa u istom System-u! Na primer, za eksploziju:

• GPU emitter: hiljade malih cestica za dim i pepeo
• CPU emitter: desetak komada debris-a koji reaguju na fiziku i koliziju

35.5 Particle Rendering Types (Tipovi renderovanja cestica)

35.5.1 Sprite Renderer (Billboard)

Sta je: Svaka cestica je ravni cetvorougao (quad) koji je uvek okrenut prema kameri. Ovo se zove billboard tehnika.

Kako radi:

Za svaku cesticu:
1. Uzmi poziciju cestice u world space
2. Kreiraj quad (4 vertexa) na toj poziciji
3. Rotriaj quad tako da uvek gleda prema kameri
4. Primeni materijal (tekstura + alpha)
5. Primeni boju i velicinu cestice

Varijante billboard-a:

Sprite Sheet animacija:

Umesto jedne teksture, mozete koristiti sprite sheet (atlas) -- jednu teksturu podeljenu na mrizu sub-slika (sub-images). Modul Sub Image Animation u Particle Update menja index tokom zivota cestice, stvarajuci iluziju animacije.

Primer: animacija eksplozije na 4x4 sprite sheet-u (16 frame-ova):

• Frame 0: mali plamen
• Frame 4: veci plamen
• Frame 8: dim se siri
• Frame 15: dim se rasprsuje

Materijali za sprite cestice:

Tipican material za sprite cesticu koristi:

• Texture Sample: osnovna tekstura (cesto sa alpha kanalom)
• Particle Color: mnozen sa teksturom za tintovanje
• Particle Alpha: kontrola providnosti
• Emissive: za svetlece cestice (vatra, magija)
• Blend Mode: Translucent (najcesci) ili Additive (za svetlece efekte)

Additive vs Translucent blend mode:

• Translucent: standardno mesanje sa alpha. Cestica zaklanja pozadinu proporcionalno svom alpha kanalu. Realistican izgled za dim, prasinu.
• Additive: boja cestice se DODAJE na pozadinu. Nikada ne zaklanja, samo dodaje svetlost. Odlicno za vatru, iskre, magiju. Problem: na svetloj pozadini postaje nevidljiv.

35.5.2 Mesh Renderer

Sta je: Umesto ravnog quad-a, svaka cestica je pun 3D mesh.

Kada koristiti:

• Debris: komadi rasprsnutog objekta (cigle, drvo, metal)
• Shell casings: caurre koje izlece iz oruzja
• Lisce: padajuce lisce sa drveca
• Kristali: magicni kristali koji lete
• Stene: vulkanski debris
• Konfete: za proslavu

Performansna razmatranja:

Mesh cestice su skuplje od sprite cestica jer:

1. Svaki mesh ima vise verteksa nego quad (4 vertexa)
2. Svaki mesh zahteva punu 3D transformaciju
3. Svaki mesh ima vise piksela za rasterizaciju (nije uvek facing camera)
4. Instanced rendering pomaze ali ima overhead za setup

Mesh Particles i Nanite:

Ovo je bitna novost u UE5! Mesh cestice mogu koristiti Nanite za renderovanje. Ovo je izuzetno korisno kada imate veliki broj mesh cestica jer Nanite automatski upravlja LOD-om i occlusion culling-om za svaki mesh instance.

Vise o Nanite interakciji u sekciji 35.7.

Tipican setup za debris mesh cestice:

Particle Spawn:
├── Initialize Particle
│   ├── Lifetime: Random Range (3.0 - 8.0)
│   └── Mass: Random Range (0.5 - 2.0)
├── Shape Location: Sphere (radius: 50)
├── Add Velocity: From Center (outward)
│   └── Speed: Random Range (200 - 800)
├── Set Mesh Index: Random (0-4)  -- 5 razlicitih mesh varijanti
└── Set Initial Rotation: Random 3D

Particle Update:
├── Gravity Force (strength: -980)
├── Drag (0.1)
├── Solve Forces and Velocity
├── Mesh Rotation Rate: Random per-axis
└── Collision (CPU mode, za bounce)

35.5.3 Ribbon / Trail Renderer

Sta je: Umesto pojedinacnih cestica, cestice se povezuju u kontinuiranu traku (ribbon/strip). Svaka cestica postaje tacka kontrole (control point) trake.

Kako radi:

Cestica 0 -------- Cestica 1 -------- Cestica 2 -------- Cestica 3
     |                  |                  |                  |
    quad              quad               quad              quad
     |                  |                  |                  |
  (povezani u kontinuiranu traku sa interpolacijom)

Ribbon renderer kreira geometriju (quad strip) izmedju uzastopnih cestica, sa opcionalnom interpolacijom (Catmull-Rom, Bezier) za glatke krive.

Tipicne upotrebe:

Kljucni parametri Ribbon renderera:

• Width: sirina trake (moze se menjati po cestici)
• Facing Mode: kako je traka okrenuta
  • Camera: uvek prema kameri (najcesci)
  • Custom: definisana osom
  • Screen Space: uvek paralelna sa ekranom
• Tessellation: koliko segmenata izmedju kontrolnih tacaka (vise = glatkije ali skuplje)
• UV Mode: kako se tekstura mapira na traku
  • Stretch: tekstura se razvlaci celom duzinom
  • Tile: tekstura se ponavlja
  • Distribution: kontrolisana distribucija

Primer: Trail za magicni projektil:

Emitter Update:
├── Spawn Per Unit (distance: 5 units)  -- nova cestica svakih 5 unita pokreta

Particle Spawn:
├── Initialize Particle
│   ├── Lifetime: 0.5  -- kratak zivot za kratak trag
│   └── Ribbon Width: 20

Particle Update:
├── Scale Color (od svetle do providne)
├── Scale Ribbon Width (od 20 do 0)

Render:
└── Ribbon Renderer
    ├── Material: M_MagicTrail
    ├── Facing: Camera
    └── UV Mode: Stretch

35.5.4 Light Renderer

Sta je: Svaka cestica emituje dinamicku tackastu svetlost (point light) u sceni.

UPOZORENJE: Ovo je IZUZETNO skup tip renderovanja!

Svaka svetlost u sceni kosta odredjen deo rendering budgeta. Kada imate 100 cestica sa light renderer-om, to je 100 dinamickih svetala u sceni -- sto moze unistiti performanse.

Kada koristiti:

• Mali broj cestica za koje je svetlost kriticna (iskre u mraku, vatrene cestice)
• Uvek u kombinaciji sa drugim renderer-om (sprite + light, ne samo light)
• Sa strogim limitom na maksimalan broj svetlostnih cestica

Prakticni saveti:

1. Limitirajte broj: koristite poseban emitter za svetlost sa mnogo manjim spawn rate-om nego za vizuelne cestice
2. Koristite mali radius: manji radius svetlosti = manje objekata na koje utice = jeftinije
3. Kratki lifetime: svetlost ne mora da traje dugo
4. Smanjite intenzitet na daljinu: LOD za svetlost -- na vecoj udaljenosti, ugasite svetlost
5. Maximum count: postavite strog maksimalan broj svetlostnih cestica

Primer: Efekat vatre sa svetloscu:

System: "NS_Campfire"
├── Emitter: "Fire_Sprites"
│   ├── Spawn Rate: 30/sec
│   ├── Sprite Renderer, Additive blend
│   └── (mnogo cestica, nema svetlosti)
│
├── Emitter: "Fire_Light"
│   ├── Spawn Rate: 2/sec  -- SAMO 2 svetla u sekundi!
│   ├── Max Particles: 3   -- nikad vise od 3 svetla
│   ├── Light Renderer
│   │   ├── Light Radius: 300
│   │   ├── Light Intensity: animirano (flicker)
│   │   └── Light Color: topla narandzasta
│   └── (malo cestica, samo za svetlost)
│
└── Emitter: "Smoke"
    ├── Spawn Rate: 10/sec
    └── Sprite Renderer, Translucent blend

35.6 Performance -- Detaljno razmatranje performansi

Cesticni efekti su jedan od najcescih uzroka performansnih problema u igrama. Hajde da detaljno analiziramo svaki aspekt.

35.6.1 Overdraw

Sta je overdraw?

Overdraw se desava kada se vise poluprozirnih piksela renderuje na istoj poziciji na ekranu. Svaki put kada GPU renderuje piksel cestice koja prekriva vec renderovani piksel, to je "overdraw".

Ovaj koncept smo detaljno objasnili u Poglavlju 09 (Rendering Pipeline) i vratiticemo se na njega u Poglavlju 43 (Optimizacija overdraw-a).

Primer problema:

Zamislite efekat dima sa 50 cestica. Svaka cestica je veliki, poluproziran quad. Kada gledate dim, na centru efekta se moze desiti da se 20+ cestica preklapa. To znaci da GPU renderuje isti piksel 20+ puta!

Vizuelizacija overdraw-a (pogled sa strane):

Ekran (1 piksel):
                        ┌── Cestica 20 (alpha 0.3)
                     ┌──┤
                  ┌──┤  └── Cestica 19 (alpha 0.2)
               ┌──┤  │
            ┌──┤  │  └──── Cestica 18 (alpha 0.4)
         ┌──┤  │  │
      ┌──┤  │  │  └────── ...
   ┌──┤  │  │  │
   │  │  │  │  └────────── Cestica 2 (alpha 0.5)
   │  │  │  │
   │  │  │  └──────────── Cestica 1 (alpha 0.6)
   │  │  │
   │  │  └────────────── Background
   
   GPU mora da renderuje SVAKI od ovih slojeva!

Kako smanjiti overdraw:

1. Koristite manje cestica sa vecim alpha: umesto 50 cestica sa alpha 0.1, koristite 10 cestica sa alpha 0.5
2. Koristite manje cestice: manja cestica = manji quad = manje piksela
3. Koristite Additive blend gde je moguce: additive blending ne zahteva depth sorting i moze biti brzi
4. Opaque masking umesto translucency: gde je vizuelno prihvatljivo, koristite Masked blend mode koji ne kosta overdraw
5. Smanjite velicinu cestica blizu kamere: cestice blizu kamere pokrivaju ogroman deo ekrana

35.6.2 Fill Rate

Sta je fill rate?

Fill rate je kolicina piksela koju GPU moze da obradi u jednom frame-u. Svaki piksel svake cestice (pomnozeno sa overdraw-om) trosi fill rate.

Formula:

Ukupni fill rate trosak = Σ (velicina_cestice_u_pikselima × shader_kompleksnost)

Za svaku cesticu:
- Velicina u pikselima zavisi od velicine cestice u world space i udaljenosti od kamere
- Shader kompleksnost zavisi od materijala (broj tekstura, matematickih operacija, itd.)

Primer fill rate problema:

Cestica dima velicine 200x200 unita, na rastojanju 100 unita od kamere, na 1080p ekranu:

• Moze zauzeti ~400x400 piksela na ekranu = 160,000 piksela
• Pomnozeno sa 30 cestica = 4,800,000 piksela
• Pomnozeno sa overdraw faktorom ~10 = 48,000,000 piksela!
• Na 1080p ekranu (2,073,600 piksela), to je ~23x fill rate ekrana samo za dim!

Kako smanjiti fill rate potrosnju:

1. Manje cestice: ocigledan ali najefektniji pristup
2. Jednostavniji materijali: manje tekstura, manje matematike u shader-u
3. Udaljenost: na vecoj udaljenosti, smanjite velicinu ili ugasite efekat
4. Near-camera fade: cestice blizu kamere postaju providne (ili se ne spawn-uju)

35.6.3 Particle Count (Broj cestica)

CPU cestice:

Prakticni limiti za CPU cestice (na modernom desktop CPU-u):

• Jednostavni moduli: 5,000 - 10,000 cestica
• Srednje kompleksni moduli: 2,000 - 5,000 cestica
• Kompleksni moduli (kolizija, events): 500 - 2,000 cestica
• Budget za celu igru: obicno 10,000 - 50,000 CPU cestica ukupno

GPU cestice:

Prakticni limiti za GPU cestice:

• Jednostavni moduli: 500,000 - 5,000,000 cestica
• Srednje kompleksni: 100,000 - 500,000 cestica
• Kompleksni moduli: 10,000 - 100,000 cestica
• Budget zavisi od GPU-a: entry-level GPU ce imati manji limit od high-end-a

Vazno: Broj cestica nije jedini faktor! 1,000 velikih, poluprozirnih cestica sa kompleksnim materijalima moze biti skuplje od 100,000 malih, aditivnih cestica sa jednostavnim materijalima.

35.6.4 Simulation Cost (Cena simulacije)

Svaki modul u Particle Update se izvrsava za svaku zivu cesticu svaki frame. Ovo se brzo sabira.

Primer kalkulacije:

Emitter sa 1,000 cestica
Particle Update sa 8 modula
60 FPS

= 1,000 × 8 × 60 = 480,000 izvrsavanja modula po sekundi

Ako svaki modul traje 0.001ms:
= 480,000 × 0.001ms = 480ms -- NEMOGU CE, previse!

Realniji scenario sa optimizovanim modulima (0.00001ms po izvrsavanju):
= 480,000 × 0.00001ms = 4.8ms -- prihvatljivo ali znacajno

Najskuplji moduli:

35.6.5 Sort Cost (Cena sortiranja)

Zasto je sortiranje potrebno?

Translucent (poluprozirne) cestice moraju biti rendrovane od najdalje ka najblizoj (back-to-front) da bi blending bio korektan. Ovo zahteva sortiranje svih cestica po udaljenosti od kamere svaki frame.

Cena sortiranja:

• Sortiranje N elemenata: O(N log N) kompleksnost
• Za 10,000 cestica: ~130,000 operacija poredjenja po frame-u
• Ovo se desava na CPU-u cak i za GPU cestice (jer CPU mora da odredi redosled renderovanja)

Kako smanjiti sort cost:

1. Additive blending: ne zahteva sortiranje (ali menja vizuelni izgled)
2. Opaque/Masked blend: ne zahteva sortiranje (ali nije poluproziran)
3. Sort po emitteru umesto po cestici: jeftinije ali manje precizno
4. Smanjite broj cestica: manje cestica = manje sortiranja
5. Grupisite emittere: emitteri sa istim materijalom se mogu sortirati zajedno

35.6.6 LOD (Level of Detail) za cestice

LOD je najvaznija tehnika optimizacije cestica. Ideja je jednostavna: na vecoj udaljenosti, smanjite kvalitet efekta jer igrac ionako ne vidi detalje.

Niagara Scalability sistem:

Niagara ima ugradjeni sistem za LOD koji radi na vise nivoa:

1. Distance-based Spawn Rate reduction:

Udaljenost 0-500 unita:   Spawn Rate = 100%
Udaljenost 500-1000:      Spawn Rate = 50%
Udaljenost 1000-2000:     Spawn Rate = 25%
Udaljenost > 2000:        Spawn Rate = 0% (ugaseno)

2. Platform Scalability:

Mozete definisati razlicite postavke za razlicite kvalitete (Low, Medium, High, Epic, Cinematic):

Scalability Settings:
├── Low:
│   ├── Spawn Rate Scale: 0.25
│   ├── Max Particle Count: 100
│   └── Disable Light Renderer: true
├── Medium:
│   ├── Spawn Rate Scale: 0.5
│   ├── Max Particle Count: 500
│   └── Disable Light Renderer: true
├── High:
│   ├── Spawn Rate Scale: 0.75
│   ├── Max Particle Count: 1000
│   └── Disable Light Renderer: false (max 2)
└── Epic:
    ├── Spawn Rate Scale: 1.0
    ├── Max Particle Count: 5000
    └── Disable Light Renderer: false (max 5)

3. Budget-based culling:

Mozete postaviti globalni budget za cestice. Kada se budget prekoraci, Niagara ce automatski ugasiti ili smanjiti efekte nizeg prioriteta.

Priority sistem:

• Svaki System ima Significance vrednost
• Efekti blize kameri imaju veci znacaj
• Efekti vidljivi na ekranu imaju veci znacaj od onih van ekrana
• Kada je budget prekoracen, efekti sa najnizim znacajem se prvi gasee

Prakticni LOD saveti:

1. Uvek postavite Cull Distance: efekat koji niko ne vidi ne treba da se simulira
2. Smanjite spawn rate na daljinu: logaritamski, ne linearno
3. Ugasite skupe module na daljinu: npr. kolizija, curl noise
4. Ugasite light renderer na daljinu: svetlost je preskupa za daleke efekte
5. Smanjite velicinu cestica na daljinu: kontraintuitivno, ali manje cestice = manje fill rate
6. Koristite Significance Manager: automatski culling na osnovu prioriteta

35.7 Niagara i Nanite/Lumen interakcija

Ovo je tema specificna za Unreal Engine 5 i izuzetno je bitna za razumevanje ogranicenja cestica u modernom rendering pipeline-u.

35.7.1 Cestice i Lumen Global Illumination

Problem: Lumen GI (Global Illumination) koristi Surface Cache za izracunavanje indirektne svetlosti (vidi Poglavlje 09 za detalje o Lumen arhitekturi). Cestice ne ucestvuju u Surface Cache-u, sto znaci:

1. Cestice ne doprinose GI-u: vatra od cestica nece osvetliti okolne zidove indirektnom svetloscu
2. Cestice ne primaju korektnu GI: ne dobijaju indirektnu svetlost od okoline
3. Cestice ne stvaraju odbijenu svetlost: dim od cestica nece occlud-ovati svetlost

Zasto?

Cestice su dinamicne, kratkotrajne i cesto poluprozirne. Surface Cache je dizajniran za staticne ili sporo-menjajuce povrsine. Ukljucivanje cestica u Surface Cache bi bilo izuzetno skupo i nestabilno.

Workaround za svetlost od cestica:

Koristite Light Renderer za kljucne cestice (npr. glavni plamen vatre) da biste dobili direktnu svetlost na okolini. Ovo nije GI u pravom smislu, ali vizuelno postize slican efekat za male izvore svetlosti.

35.7.2 Light cestice i Lumen

Kada koristite Light Renderer, te svetlosti mogu uticati na Lumen jer su to standardni dinamicki point light-ovi. Ali:

1. Izuzetno skupo: svaki light u Lumen-u mora biti evaluiran za ray tracing (software ili hardware)
2. Shadow casting: ako light cestica baca senke, to je jos skuplje
3. Flickering: veliki broj malih svetlosti koje se stalno stvaraju i nestaju moze izazvati vizuelne artifakte u Lumen GI-u

Preporuka: Koristite maksimalno 3-5 svetlostnih cestica po efektu, sa strogo kontrolisanim lifecycle-om (ne spawn-ujte ih brzo, ne ubijajte ih naglo).

35.7.3 Mesh cestice i Nanite

Ovo je pozitivna vest! Mesh cestice mogu koristiti Nanite za renderovanje, sto otvara mogucnosti za:

1. Veliki broj mesh cestica: Nanite automatski upravlja LOD-om za svaki mesh instance
2. Occlusion culling: Nanite automatski skriva mesh cestice koje su zaklonjene
3. Efikasno renderovanje: Nanite batching za instanced rendering

Kako aktivirati Nanite za mesh cestice:

1. Mesh koji koristite za cestice mora imati Nanite enabled (u Mesh editor-u)
2. U Mesh Renderer postavkama emittera, uključite Nanite opciju
3. Proverite da materijal podrzava Nanite (Opaque ili Masked blend mode)

Ogranicenja Nanite mesh cestica:

• Samo Opaque/Masked materijali: Translucent materijali ne rade sa Nanite
• Nema per-particle materijal promene: sve cestice koriste isti materijal (mada mozete koristiti per-instance custom data za varijaciju u shader-u)
• Veliki meshevi: Nanite je dizajniran za kompleksne mesheve -- za jednostavne cube-ove ili sfere, instanced rendering moze biti brzi
• Animacija: Nanite ne podrzava vertex animaciju (skeletal mesh, morph targets)

Prakticni primer -- Nanite debris:

Scenario: Rusenje zgrade
├── 500 mesh cestica (komadi zgrade)
├── Svaki komad je high-poly mesh (5000+ trouglova)
├── Bez Nanite: 500 × 5000 = 2,500,000 trouglova -- SKUPO
├── Sa Nanite: automatski LOD po udaljenosti
│   ├── Blizu kamere: pun detalj (5000 trouglova)
│   ├── Srednja udaljenost: LOD 2 (500 trouglova)
│   └── Daleko: LOD 5 (50 trouglova)
│   └── Zaklonjen: 0 trouglova (culled)
└── Rezultat: drasticno manje trouglova za renderovanje

35.7.4 Pregled interakcija

35.8 Prakticni primeri -- Korak po korak

U ovoj sekciji cemo proci kroz kreiranje nekoliko cesticnih efekata od nule.

35.8.1 Primer 1: Jednostavan efekat vatre

Cilj: Napraviti efekat vatre za baklju.

Korak 1: Kreiranje System-a

1. Content Browser > desni klik > Niagara System
2. Izaberite "Create Empty System"
3. Imenujte ga "NS_TorchFire"

Korak 2: Dodavanje Fire emittera

Emitter: "Fire_Sprites"

Emitter Update:
├── Emitter State (Life Cycle: Self, Loop: Infinite)
└── Spawn Rate: 25/sec

Particle Spawn:
├── Initialize Particle
│   ├── Lifetime: Random (0.3, 0.8)
│   ├── Sprite Size: Random (15, 35)
│   ├── Color: (1.0, 0.6, 0.1, 1.0) -- topla narandzasta
│   └── Sprite Rotation: Random (0, 360)
├── Shape Location: Cylinder
│   ├── Radius: 5
│   ├── Height: 2
│   └── Position Offset: (0, 0, 0)
└── Add Velocity: Cone
    ├── Speed: Random (50, 120)
    ├── Angle: 15 degrees
    └── Direction: Up (0, 0, 1)

Particle Update:
├── Curl Noise Force (Strength: 30, Frequency: 0.5)
├── Drag (0.3)
├── Solve Forces and Velocity
├── Scale Color (Curve):
│   ├── 0.0: (1.0, 0.8, 0.3, 1.0) -- svetlo zuta
│   ├── 0.3: (1.0, 0.4, 0.1, 0.8) -- narandzasta
│   ├── 0.7: (0.8, 0.2, 0.05, 0.4) -- tamno crvena
│   └── 1.0: (0.3, 0.1, 0.05, 0.0) -- gotovo nevidljiva
└── Scale Sprite Size (Curve):
    ├── 0.0: 0.5 (pocinje mala)
    ├── 0.3: 1.0 (raste)
    └── 1.0: 1.5 (zavrsava velika i rasprsena)

Render:
└── Sprite Renderer
    ├── Material: M_Fire (Additive blend, Emissive, Unlit)
    ├── Texture: T_Fire_SubUV (4x4 sprite sheet)
    ├── Sub UV: 4x4
    └── Sorting: By Distance

Korak 3: Dodavanje Smoke emittera

Emitter: "Smoke_Rising"

Emitter Update:
├── Emitter State (Life Cycle: Self, Loop: Infinite)
└── Spawn Rate: 8/sec

Particle Spawn:
├── Initialize Particle
│   ├── Lifetime: Random (1.5, 3.0)
│   ├── Sprite Size: Random (20, 50)
│   ├── Color: (0.15, 0.12, 0.1, 0.3) -- tamno siva sa niskim alpha
│   └── Sprite Rotation: Random (0, 360)
├── Shape Location: Cylinder (Radius: 8, Height: 5)
└── Add Velocity: Cone
    ├── Speed: Random (30, 60)
    ├── Angle: 20 degrees
    └── Direction: Up

Particle Update:
├── Curl Noise Force (Strength: 15, Frequency: 0.3)
├── Gravity Force (-50)  -- blaga negativna gravitacija (dim se dize)
├── Drag (0.5)
├── Solve Forces and Velocity
├── Scale Color: alpha fade out tokom zivota
├── Scale Sprite Size: raste od 1.0 do 3.0
└── Sprite Rotation Rate: Random (-30, 30) deg/sec

Render:
└── Sprite Renderer
    ├── Material: M_Smoke (Translucent, Lit)
    ├── Texture: T_Smoke_01
    └── Sorting: By Distance

Korak 4: Dodavanje Light emittera

Emitter: "Fire_Light"

Emitter Update:
├── Emitter State (Life Cycle: Self, Loop: Infinite)
└── Spawn Rate: 1/sec

Particle Spawn:
├── Initialize Particle
│   ├── Lifetime: 0.5
│   └── Position: (0, 0, 10) -- malo iznad osnove vatre

Particle Update:
├── Scale Color:
│   ├── Intensity: Sine wave (flicker efekat)
│   └── Color: topla narandzasta
└── (Nema kretanja -- svetlost ostaje na mestu)

Render:
└── Light Renderer
    ├── Radius: 200
    ├── Intensity: 5000 (varirano kroz Sine wave za flicker)
    ├── Color: (1.0, 0.6, 0.2)
    └── Max Count: 2

35.8.2 Primer 2: Efekat eksplozije

Cilj: Kompleksna eksplozija sa vise faza.

System: "NS_Explosion"

── Emitter: "Flash"
│  ├── Spawn: Burst 1 cestica
│  ├── Lifetime: 0.1 sec
│  ├── Sprite: veliki, beli, additive
│  └── Scale: brzo raste pa nestaje

── Emitter: "Fire_Core"
│  ├── Spawn: Burst 30 cestica
│  ├── Velocity: sfericno od centra (300-600 speed)
│  ├── Lifetime: 0.3-0.8 sec
│  ├── Material: Additive fire
│  └── Color: zuta → narandzasta → crvena → providna

── Emitter: "Smoke_Cloud"
│  ├── Spawn: Burst 20, zatim Rate 15/sec za 1 sec
│  ├── Velocity: sfericno (100-300 speed)
│  ├── Lifetime: 2.0-4.0 sec
│  ├── Material: Translucent smoke
│  ├── Size: raste od 30 do 150
│  └── Color: tamno siva, alpha fade out

── Emitter: "Sparks"
│  ├── Spawn: Burst 50 cestica
│  ├── Velocity: sfericno (500-1500 speed)
│  ├── Lifetime: 0.5-1.5 sec
│  ├── Gravity: da
│  ├── Size: male (2-5)
│  ├── Material: Additive, bright
│  └── Color: bela → zuta → narandzasta → providna

── Emitter: "Debris" (CPU, Mesh Renderer)
│  ├── Spawn: Burst 10-15 cestica
│  ├── Velocity: sfericno nagore (300-800 speed)
│  ├── Gravity: da (-980)
│  ├── Collision: da (CPU, bounce)
│  ├── Lifetime: 3.0-8.0 sec
│  ├── Mesh: razliciti debris meshevi
│  └── Rotation: random 3D rotacija

── Emitter: "Shockwave"
│  ├── Spawn: Burst 1 cestica
│  ├── Lifetime: 0.3 sec
│  ├── Sprite: horizontalni (ne billboard)
│  ├── Size: brzo raste od 0 do 500
│  ├── Material: Additive, ring tekstura
│  └── Alpha: brzo fade out

── Emitter: "Ground_Dust"
│  ├── Spawn: Burst 15, sa malim delay-om (0.1 sec)
│  ├── Velocity: radijalno od centra, samo horizontalno
│  ├── Lifetime: 2.0-5.0 sec
│  ├── Size: velike (50-150)
│  └── Material: Translucent dust

└── Emitter: "Explosion_Light"
    ├── Spawn: Burst 1
    ├── Lifetime: 0.5 sec
    ├── Light Radius: 500-1000
    ├── Intensity: 20000 → 0 (brz pad)
    └── Color: topla bela → narandzasta

35.8.3 Primer 3: Magicni spell efekat

System: "NS_MagicOrb"

── Emitter: "Core_Glow"
│  ├── Spawn: Burst 1 (persistent cestica)
│  ├── Lifetime: Infinite (dok sistem ne zavrsi)
│  ├── Size: pulsira (Sine wave, 20-30)
│  ├── Material: Additive, emissive
│  └── Color: pulsira (svetlo plava → tamno plava)

── Emitter: "Orbiting_Particles" (GPU)
│  ├── Spawn Rate: 50/sec
│  ├── Lifetime: 0.5-1.0 sec
│  ├── Shape Location: Sphere (radius: 30)
│  ├── Custom Module: orbitalno kretanje oko centra
│  ├── Size: male (2-5)
│  ├── Material: Additive
│  └── Color: svetlo plava → providna

── Emitter: "Trail" (Ribbon Renderer)
│  ├── Spawn Per Unit: distance-based
│  ├── Lifetime: 0.3 sec
│  ├── Width: 15 → 0 (sužava se)
│  ├── Material: Additive, animated UV
│  └── Color: plava → providna

── Emitter: "Sparkles" (GPU)
│  ├── Spawn Rate: 20/sec
│  ├── Lifetime: 0.2-0.5 sec
│  ├── Velocity: random u sferi, mala brzina
│  ├── Size: veoma male (1-3)
│  └── Material: Additive, bright white

└── Emitter: "Magic_Light"
    ├── Spawn: 1 (persistent)
    ├── Light Radius: 150
    ├── Intensity: pulsira (Sine wave)
    └── Color: plava

35.9 Niagara Data Interface-ovi

Data Interface-ovi su mehanizam kojim Niagara komunicira sa spoljnim sistemima i podacima.

35.9.1 Najcesci Data Interface-ovi

35.9.2 Particle Attribute Reader -- komunikacija izmedju emittera

Ovo je mocna funkcionalnost koja omogucava jednom emitteru da cita podatke iz drugog emittera u istom sistemu.

Primer: Iskre na mestu kolizije debris-a

Emitter 1: "Debris" (CPU)
├── Mesh particles sa kolizijom
├── Kada cestica udari u pod, generise Event
└── Event sadrzi: poziciju udara, normalu povrsine, brzinu udara

Emitter 2: "Impact_Sparks"
├── Slusa Event iz "Debris" emittera
├── Na Event: Burst spawn na poziciji udara
├── Brzina: odraz od normale povrsine
└── Intenzitet zavisi od brzine udara

35.9.3 Prosledjivanje podataka iz Blueprint-a

Mozete proslediti podatke iz Blueprint-a u Niagara System koristeci User Parameters:

U Niagari:

1. Kreirajte parametre u User namespace-u (npr. User.TargetPosition, User.SpellColor, User.IntensityScale)
2. Koristite te parametre u modulima

U Blueprint-u:

Blueprint pseudo-kod:

// Referenca na Niagara Component
NiagaraComponent = GetComponentByClass(NiagaraComponent)

// Postavljanje parametara
NiagaraComponent.SetNiagaraVariableVec3("User.TargetPosition", EnemyLocation)
NiagaraComponent.SetNiagaraVariableLinearColor("User.SpellColor", FLinearColor(0, 0.5, 1, 1))
NiagaraComponent.SetNiagaraVariableFloat("User.IntensityScale", DamageMultiplier)

Ovo je izuzetno korisno za kreiranje data-driven efekata gde jedan isti Niagara System moze da izgleda potpuno razlicito u zavisnosti od gameplay situacije.

35.10 Common VFX Optimization Strategies (Strategije optimizacije)

Ovo je sekcija koju bi svaki VFX artist i programer trebalo da zna napamet. Optimizacija cestica je kriticna za performanse igre.

35.10.1 Hijerarhija optimizacije (od najvaznijeg ka najmanje vaznom)

1. [KRITIČNO]  Da li efekat uopste treba da postoji?
2. [KRITIČNO]  Cull distance -- ugasite ga kad nije vidljiv
3. [VISOKO]    Smanjite broj cestica na daljinu (LOD)
4. [VISOKO]    Smanjite velicinu cestica (fill rate)
5. [VISOKO]    Koristite GPU simulaciju gde je moguce
6. [SREDNJE]   Smanjite overdraw (manje velikih cestica)
7. [SREDNJE]   Pojednostavite materijale
8. [SREDNJE]   Limitirajte svetlostne cestice
9. [NISKO]     Optimizujte module u Particle Update
10. [NISKO]    Koristite LOD za kompleksnost modula

35.10.2 Strategija 1 -- Reduce particle count at distance

Problem: Efekat sa 100 cestica izgleda isto na 10 metara i na 200 metara udaljenosti.

Resenje: Koristite Niagara Scalability opcije:

Effect Significance:
├── Near (0 - 500 units):    100% spawn rate, svi moduli
├── Medium (500 - 1500):     50% spawn rate, bez curl noise
├── Far (1500 - 3000):       25% spawn rate, pojednostavljen
└── Very Far (> 3000):       0% -- potpuno ugaseno

Takodje koristite Max Particles limit da sprecite nekontrolisan rast broja cestica.

35.10.3 Strategija 2 -- Use smaller particles

Problem: Velike cestice pokrivaju mnogo piksela, trose fill rate.

Resenje: Umesto 10 velikih cestica dima, koristite 30 manjih cestica. Vizuelno moze izgledati slicno (pa cak i bolje jer je vise detaljisan) ali sa drasticno manjim fill rate troskovima.

Primer:
Opcija A: 10 cestica, velicina 200x200 unita
  = na 1080p, svaka ~300x300px = 90,000 px/cestica
  = sa overdraw ~5x = 4,500,000 piksela

Opcija B: 30 cestica, velicina 60x60 unita
  = na 1080p, svaka ~90x90px = 8,100 px/cestica
  = sa overdraw ~3x (manje preklapanja) = 729,000 piksela
  
Opcija B trosi ~6x MANJE fill rate-a!

35.10.4 Strategija 3 -- Avoid overdraw

Detaljno razmatranje overdraw-a mozete naci u Poglavlju 09 i Poglavlju 43 (optimizacija overdraw-a).

Kljucne taktike:

1. Manje velikih cestica, vise malih: manje preklapanja
2. Additive blending: manje bolji nego translucent po overdraw pitanju (ne zahteva sort, ali vizuelno drugacije izgleda)
3. Opacity masking gde je prihvatljivo: potpuno eliminise overdraw (ali gubi smooth edge)
4. Depth fade: cestice postaju providne kada su blizu opaque geometrije, sto smanjuje vizuelni efekat preklapanja
5. Near camera fade: cestice blizu kamere (koje bi bile ogromne na ekranu) postaju providne

35.10.5 Strategija 4 -- GPU simulation where possible

Vec smo detaljno diskutovali o razlikama izmedju CPU i GPU simulacije u sekciji 35.4. Kljucna poruka: pocnite sa GPU, predjite na CPU samo kada je neophodno.

Konkretni koraci za prebacivanje na GPU:

1. U Emitter Properties, promenite Sim Target na GPUCompute Sim
2. Proverite da svi moduli podrzavaju GPU (Niagara ce vas upozoriti ako ne)
3. Zamenite CPU-only module sa GPU alternativama (npr. CPU collision → Depth Buffer collision)
4. Testirajte vizuelni rezultat -- ponekad se ponasanje blago razlikuje

35.10.6 Strategija 5 -- Limit particle lights

Pravila za svetlostne cestice:

35.10.7 Strategija 6 -- Use LOD system

Niagara LOD sistem je mocan i treba ga koristiti za svaki efekat koji ce se videti na razlicitim udaljenostima.

Kompletni LOD setup primer:

System: "NS_CampfireFire"

Scalability:
├── Spawn Rate Scaling:
│   ├── Close (0-300):    1.0x
│   ├── Mid (300-800):    0.5x
│   ├── Far (800-1500):   0.2x
│   └── VeryFar (>1500):  0.0x (culled)
│
├── Module LOD:
│   ├── Close: sve module (curl noise, collision, itd.)
│   ├── Mid: bez collision, smanjeni curl noise quality
│   └── Far: samo osnovni moduli (gravity, solve, color)
│
├── Renderer LOD:
│   ├── Close: Sprite + Light
│   ├── Mid: samo Sprite
│   └── Far: samo Sprite (smanjen sort)
│
└── Visibility:
    ├── Frustum Culling: da
    ├── Occlusion Culling: da (za vece efekte)
    └── Max Draw Distance: 2000 unita

35.11 Niagara Events i Communication

35.11.1 Event sistem

Niagara ima ugradjeni event sistem koji omogucava komunikaciju izmedju emittera i sa spoljnim sistemom.

Tipovi eventa:

1. Particle Events: generisani od strane cestica (npr. kolizija, smrt)
2. Emitter Events: generisani od strane emittera
3. Blueprint Events: primljeni iz ili poslati u Blueprint

Primer: Particle Death Event

Kada cestica umre (istekne lifetime), moze generisati event koji drugi emitter slusa:

Emitter 1: "Firework_Trail" (Ribbon)
├── Cestice lete nagore
├── Na smrti cestice: generisi "DeathEvent"
│   └── Event podatak: pozicija smrti

Emitter 2: "Firework_Burst"
├── Slusa "DeathEvent" iz Emitter 1
├── Za svaki event: Burst 50 cestica na poziciji iz eventa
└── Rezultat: vatromet koji eksplodira na vrhu putanje

Primer: Collision Event

Emitter: "Rain_Drops" (CPU)
├── Cestice padaju nadole (gravitacija)
├── Collision modul detektuje udar u pod
├── Na koliziju: generisi "CollisionEvent"
│   ├── Pozicija kolizije
│   ├── Normala povrsine
│   └── Brzina udara

Emitter: "Rain_Splash"
├── Slusa "CollisionEvent"
├── Na event: Burst 5-10 cestica na poziciji kolizije
├── Brzina: nagore i u stranu (na osnovu normale)
└── Mala velicina, kratak zivot

35.11.2 Communication sa Blueprint-om

Iz Blueprint-a u Niagaru:

• Set Niagara Variable (float, vector, color, itd.)
• Activate/Deactivate System
• Reset System

Iz Niagare u Blueprint:

• Niagara Component Callback -- Blueprint moze slusati specifične evente
• User Parameter Binding -- Niagara cita vrednosti iz Blueprint promenljivih

35.12 Debug i profiling Niagara efekata

35.12.1 Niagara Debugger

Niagara ima ugradjeni Debugger koji vam omogucava da u realnom vremenu vidite:

1. Broj aktivnih sistema, emittera i cestica: odmah vidite koliko cestica imate u sceni
2. Per-emitter statistike: spawn rate, particle count, simulation cost
3. Per-particle atributi: mozete selektovati pojedinacnu cesticu i videti sve njene atribute
4. Performance metriku: koliko vremena svaki emitter trosi na simulaciju

Kako pristupiti Debugger-u:

U Niagara Editor-u: Window > Debugger U igri: konzolna komanda Niagara.Debug 1

35.12.2 Stat komande

Korisne konzolne komande za profiling:

35.12.3 Overdraw vizuelizacija

Koristite View Mode > Shader Complexity u Editor-u da vizualno vidite koliko su vasi efekti skupi u smislu overdraw-a.

• Zeleno: prihvatljivo
• Zuto: skupo ali mozda OK
• Crveno: preskupo, morate optimizovati
• Belo: kriticno -- taj deo ekrana je izuzetno skup

Za detaljnu analizu overdraw-a, vidite Poglavlje 43.

35.13 Best Practices -- Saveti iz prakse

35.13.1 Organizacija

1. Konvencija imenovanja:

   • Systems: NS_ImeEfekta (NS = Niagara System)
   • Emitters: NE_ImeEmittera (NE = Niagara Emitter)
   • Modules: NM_ImeModula (NM = Niagara Module)
   • Parametri: NPC_ImeParametra (NPC = Niagara Parameter Collection)

2. Folder struktura:

Content/
├── VFX/
│   ├── Systems/
│   │   ├── Combat/
│   │   │   ├── NS_Explosion_Small
│   │   │   ├── NS_Explosion_Large
│   │   │   └── NS_MuzzleFlash
│   │   ├── Environment/
│   │   │   ├── NS_Rain
│   │   │   ├── NS_Snow
│   │   │   └── NS_Campfire
│   │   └── Magic/
│   │       ├── NS_FireSpell
│   │       └── NS_IceSpell
│   ├── Emitters/
│   │   ├── NE_Fire_Generic
│   │   ├── NE_Smoke_Generic
│   │   └── NE_Sparks_Generic
│   ├── Modules/
│   │   ├── NM_OrbitMotion
│   │   └── NM_CustomCurlNoise
│   ├── Materials/
│   │   ├── M_Fire_Additive
│   │   ├── M_Smoke_Translucent
│   │   └── M_Sparks_Additive
│   └── Textures/
│       ├── T_Fire_SubUV
│       ├── T_Smoke_01
│       └── T_Sparks_01

35.13.2 Performansni saveti

1. Zlatno pravilo: uvek profilirajte na ciljnoj platformi, ne na development masini
2. Budget: postavite ukupni budget za cestice (npr. max 20,000 CPU cestica, max 500,000 GPU cestica u sceni)
3. Prioritet: uvek smanjite kvalitet daljih efekata pre nego sto smanjite blize
4. Testiranje: testirajte sa "worst case" scenarijima (mnogo eksplozija odjednom, kisa + eksplozija + magija)
5. Platform targeting: razliciti budgeti za PC, konzole, mobilne uredjaje

35.13.3 Vizuelni saveti

1. Reference: uvek koristite video reference za prirodne efekte (snimci prave vatre, dima, eksplozija)
2. Timing: tajming je sve -- eksplozija koja traje 0.1 sekunde preduge izgleda pogresno
3. Varijacija: dodajte random varijaciju u SVE -- velicinu, boju, brzinu, lifetime, rotaciju
4. Layering: najbolji efekti imaju vise slojeva (core + detail + glow + secondary effects)
5. Movement: koristite curl noise za organsko kretanje; linearne putanje izgledaju vestacki

35.14 Kljucni termini

35.15 Unakrsne reference na druga poglavlja

35.16 Dodatni resursi za ucenje

Zvanicna dokumentacija

• Epic Games -- Niagara Overview: docs.unrealengine.com/niagara-overview
• Epic Games -- Niagara Key Concepts: docs.unrealengine.com/niagara-key-concepts
• Epic Games -- Niagara Quick Start: docs.unrealengine.com/niagara-quick-start

Video resursi

• Epic Games -- Introduction to Niagara (GDC talk): Detaljan pregled arhitekture sistema
• Epic Games -- Building Advanced Effects in Niagara: Napredne tehnike sa primerima
• Epic Games -- Niagara Performance and Optimization: Strategije optimizacije sa real-world primerima
• Unreal Engine YouTube kanal -- Inside Unreal: Niagara: Serija epizoda sa detaljnim objasnjenjima

Community resursi

• Real Time VFX Forum (realtimevfx.com): Zajednica VFX umetnika sa mnogo Niagara primera
• Unreal Engine Forums -- VFX sekcija: Diskusije, problemi i resenja
• ArtStation: pretrazite "Niagara UE5" za inspiraciju i breakdown-ove efekata

Rezime poglavlja

U ovom poglavlju smo prosli kroz kompletnu Niagara arhitekturu -- od osnovnog koncepta cestica, preko hijerarhije System/Emitter/Module, do detaljnog pregleda simulacionih faza. Razumeli smo razlike izmedju CPU i GPU cestica i kada koristiti koji pristup. Pokrili smo sve tipove renderovanja (Sprite, Mesh, Ribbon, Light) sa njihovim prednostima i manama.

Posebnu paznju smo posvetili performansama -- overdraw, fill rate, sort cost, simulation cost -- jer su cestice jedan od najcescih uzroka performansnih problema. Diskutovali smo o interakciji sa Nanite i Lumen sistemima, prosli kroz prakticne primere efekata, i zavrsili sa proverenim strategijama optimizacije.

Zapamtite: najbolji cesticni efekat nije onaj koji ima najvise cestica, vec onaj koji postize zeljeni vizuelni efekat sa najmanjim mogucim troskovom performansi.

U sledecem poglavlju cemo nastaviti sa daljim temama. Do tada, eksperimentisite sa Niagara editorom -- napravite vatru, eksploziju, magicni efekat -- i obavezno profilirajte vase kreacije!