ItCG Projekt 2. Bjarke N. Laustsen ( ) Martin Jørgensen ( )

Transkript

1 ItCG Projekt 2 Bjarke N. Laustsen ( ) Martin Jørgensen ( ) 1/06/2007

2 Indhold: INTRODUKTION... 2 HVAD ER ET PARTIKEL SYSTEM?... 2 LØSNING AF ORDINÆRE DIFFERENTIAL LIGNINGER:... 3 SCENE 1: FOUNTAIN SCENE... 4 PARTIKEL SYSTEMET:... 5 Preframe:... 5 Initialisering af nye vandpartikler:... 6 Preframe Udregninger:... 6 Kræfter:... 7 Tegning af partiklerne:... 8 Billboarding:... 8 Tegning af gennemsigtige objekter:... 9 VANDOVERFLADEN:...10 SCENE 2: SPRING-MASS CLOTH SCENE...11 PARTIKEL SYSTEMET:...12 Kræfter:...13 Tegning af partiklerne:...15 SKYBOX:...16 LENSFLARE:...17 SCENE 3: SPRING-MASS JELLY SCENE...20 KONKLUSION...21 FUTURE WORK...22 REFERENCER

3 Introduktion I dette projekt har vi implementeret to partikel systemer. Partikel systemer kan bruges til at rendere objekter og effekter, der kan være svære at simulere med de traditionelle metoder fra første del af kurset. Projektet består af 3 scener: En springvands scene, en scene med et stykke stof der blafrer i vinden og en scene med en skvulpende kasse. I programmet vælges scene med F1-F5. På windows (med f.eks. MingW installeret) kompileres programmet med make (eller tilsvarende) og køres med main.exe. På linux kompileres det med make -f MakefileLinux og køres med main. Hvad er et Partikel System? Iflg. [RTR] sektion 8.5 er et partikel system en mængde små objekter der sættes i bevægelse af en eller anden algoritme. Som regel er reglerne for hvordan partiklerne sættes i bevægelse en efterligning af de fysiske love for masse-kraft påvirkning. Partiklerne i et partikel system følger altså ofte de fysiske love for hvordan kræfter påvirker bevægelsen af masse. Dette gælder også i vores partikel systemer. Man skal altså have et antal kræfter og hver partikel skal gives en masse (samt position, hastighed og evt. andre attributter). En kraft påvirker en partikel ved at accelerere den i en given retning og med en given styrke. En kraft repræsenteres som en 3D vektor. Accelerationen af en f partikel påvirkes af en kraft på denne måde: a m (vi ser altså at jo større masse partiklen har, jo stærkere skal kraften være for at opnå en given acceleration). Hvis flere kræfter f 1,...,f n påvirker en partikel, fås den totale acceleration ved at summere kraft-vektorerne: n a. i 1 f i m Der er flere måder at udregne hastigheden og positionen af en partikel ud fra accelerationen. Den simpleste måde er eulers metode. Efter accelerationen er fundet, opdateres hastighedsvektoren, ved at plusse den med accelerationen. For at gøre animationen tidsafhængig, skal accelerationen dog først ganges med tidsforskellen fra sidste frame til denne frame (målt i sek.): position findes nu ud fra hastighedsvektoren. Alt i alt: a : f m v : v a t p : p v t v : v a t. Den nye Til sidst skal det nævnes at partikel systemer ikke handler om hvordan systemet bliver tegnet de kan tegnes på mange måder og behøver ikke tegnes som partikler. For eksempel tegnes vores partikler i springvands systemet som 2

4 partikler (texturede billboardede quads), mens partiklerne i vores spring-mass system i stedet bruges som vertices i trekanter og selve partiklerne tegnes ikke eksplicit (man kan dog få partiklerne tegnet eksplicit ved at trykke p ). Implementation af partikel effekter består altså af to separate trin: simulerings trinet og renderings trinet. Løsning af ordinære differential ligninger: Metoderne vi bruger til at opdatere hastigheden og positionen ud fra accelerationen fra frame til frame er faktisk løsnings metoder til differential ligninger. Da dette ikke er et kursus i numerisk analyse vil vi ikke gå i detaljer med dette. Eulers metode blev skitseret i forrige afsnit. Fordelen ved den er at den er simpel, men ulemperne er at den er ustabil og trunkerings fejlen er stor. Ustabilitet i numerisk forstand, betyder at små fejl lavet på ét trin i processen bliver forstørrede i de efterfølgende trin. Dette kommer i vores tilfælde til udtryk i at vores partikel systemer eksploderer. Det sker ofte hvis vi tager for store skridt i tiden t (hvis frame-raten bliver for lav). Dette er rigtigt godt og intuitivt forklaret i [4]. En bedre metode er Verlets metode. Verlets metode står beskrevet i [PMN] og er mere stabil end eulers metode. Den kan dog stadig eksplodere, men ikke helt så nemt som eulers metode. En forbedring er Verlets time-corrected method, som er beskrevet i [5]. Dette er metoden vi har brugt i vores spring-mass system. Der findes også andre mere stabile metoder der dog er en smule dyrere, som f.eks. Runge-Kutta dem har vi dog ikke set på. 3

5 Scene 1: Fountain Scene Den første scene indeholder vores første partikel system, nemlig et springvand i et rum. Springvandet udspringer fra midten af en kasse midt i rummet. Vandet skydes op i luften og trækkes nedad af tyngdekraften. Hvis vandpartiklerne falder ned på kassen, hopper de hen ad kassen en billig måde at efterligne at vandet pjasker når det rammer kassen og flyder hen ad den. Omkring kassen er et vandbassin. Når vandpartiklerne fra springvandet rammer denne vandoverflade, kommer der små forstyrrelser i vandet. Selve scenen er opbygget af kasser med textures. Vandoverfladen er lavet ud fra [PMN] og springvandet er vores partikelsystem. Med grabberen kan man tage fat i kameraet og verdenen. Begge disse bruges til at translatere og rotere verdenen med musen. Forskellen er at rotation af kameraet sker omkring kameraets position (det globale nulpunkt), mens rotation af verdenen sker omkring midten af scenen (verdenens lokale nulpunkt). Kameraet kan også translateres med cursor tasterne. Udover dette er der taster der kan bruges til at ændre visse parametre ved springvandet for eksempel spredningen af vandstrålen og at tænde og slukke for springvandet. Tryk h for at se hvilke taster der gør hvad. 4

6 Hovedklasserne i denne scene er: - FountainScene : selve scenen - Fountain : kontrol klassen for springvands partikel systemet - WaterParticle : partiklerne i systemet er objekter af denne klasse - WaterPlane : vandoverfladen Scenegrafen for scenen ser sådan ud: camera : Camera world : GroupObject light1 : Light centercube : Cube floor : Cube water : WaterPlane fountain : Fountain p 1 : WaterParticle p n : WaterParticle Bemærk at et GroupObject tegner dets børn i rækkefølgen venstre mod højre. Dette udnytter vi når vi tegner gennemsigtige objekter (fountain og water) i scenen så de gennemsigtige objekter bliver tegnet til sidst se nedenfor. Partikel Systemet: Lad os nu se på selve partikel systemet der styrer vandpartiklerne. Vi vil først se på hvordan en ny partikel initialiseres når den laves, hvordan simulations udregningerne foregår fra frame til frame i Fountain klassens preframe metode og til sidst hvordan partiklerne tegnes af klassens draw metode. De variabler der gemmes for hver partikel (i WaterParticle objekterne) som vedrører udregningerne for bevægelse af partiklen er: masse, position, hastighedsvektor, om den har bounced på kassen endnu og tidspunktet den blev lavet. I denne scene har alle partiklerne samme masse. Udover disse variable i WaterParticle klassen gemmes også nogle konstanter i Fountain-klassen som bruges som parametre for bevægelsen og som er fælles for alle partiklerne. Preframe: For at udregne bevægelsen af partiklerne fra sidste frame til denne frame, kaldes preframe metoden i Fountain-klassen. Denne metode står for at lave 5

7 udregningerne der flytter partiklerne, ved at kalde preframe metoderne i WaterParticle-objekterne, og for at lave nye partikler og dræbe gamle partikler. Initialisering af nye vandpartikler: Lad os først se på hvordan den laver en ny partikel. En ny vandpartikel laves ved at konstruere et nyt WaterParticle objekt. Når en ny vandpartikel laves, udsendes (eller emittes ) den fra kassen i midten af rummet. Partiklernes startposition initialiseres således: x og z koordinatet sættes til et tilfældigt sted indenfor en cirkel midt på kassen. Startpositionens y-koordinat sættes til at være en smule under toppen af kassen. p start = ((random()-0.5)*k startposspread, (random()-0.5)*k startposymul - 0.5, (random()-0.5)*k startposspread ) Partiklesnes start hastighedsvektor sættes således: v start = ((random()-0.5)*k startvelspread, random() *k startvelymul + k startvelyadd, (random()-0.5)*k startvelspread ) Ved at variere k startvelspread kan man altså variere hvor meget partiklerne spredes i forskellige retninger dvs. tykkelsen af vandstrålen. Partiklernes hastighed opad er også forskellig fra partikel til partikel, sådan at de når forskellige højder, også selvom de har næsten samme xz-hastighed. Preframe Udregninger: I hver frame skal partiklernes positioner og hastigheder opdateres. Der skal også laves nye partikler og gamle partikler skal muligvis dræbes. Fountain objektets preframe metode kalder preframe metoderne i alle vandpartiklerne (WaterParticle objekter). WaterParticles preframe metode sørger for at accelerere partiklernes hastigheder ud fra de kræfter der påvirker den, sørger for at partiklerne bouncer hvis de rammer toppen af den midterste kassen og sørger for at give WaterPlane objektet besked hvis partiklen rammer vandfladen. Et partikel objekt holder også selv styr på hvornår det skal slettes dens preframe metoden returnere en boolean der fortæller Fountains preframe metode om den skal slettes. En partikels preframe metode finder dens nye position og hastighedsvektor via eulers metode, som beskrevet ovenfor. 6

8 En partikel bouncer på den midterste kasse hvis dens y-koordinat er mindre/lig y- koordinatet af toppen af kassen og dens x og z koordinater er indenfor kassen. Første gang en partikel rammer kassen reduceres dens y-hastighed betydeligt og fortegnet ændres så den får retning opad. Samtidig bliver dens hastighed i xzretningen forøget med en faktor. De evt. efterfølgende gange den rammer kassen, ændres blot fortegnet af y-hastigheden. Hvis partiklens y-koordinat er mindre/lig y-koordinatet på vandoverfladen, kaldes hit-metoden i WaterPlane objektet (vil blive beskrevet nedenfor) med partiklens (x,z) koordinat, sådan at der kommer en forstyrrelse i vandoverfladen det sted partiklen ramte. En partikel bliver dræbt hvis dens y-koordinat er under en vis værdi y kill eller hvis den har oversteget sin levetid. Grunden til vi har sat en begrænsning på levetiden er at undgå der kommer for mange partikler i scenen på én gang. Ved tynde stråler har partiklerne lav xz-hastighed, hvilket gør at det tager lang tid før de bouncer ned af kassen og når y kill. Uden begrænset levetid ville der derfor kunne være for mange partikler i live og dette ville tage for meget CPU tid. Når en partikel har oversteget sin levetid og skal slettes, ville det se forkert ud hvis partiklen forsvandt fra det ene øjeblik til det andet. Før den slettes, fades den langsomt ud ved at formindske dens -værdi. Først når =0 slettes den. Det er WaterParticle objektet selv der sørger for at fade farven ud og det er som sagt også objektet selv der sørger for at holde styr på hvornår det skal slettes. Kræfter: Vi vil her kort beskrive kræfterne der påvirker partiklerne i springvandet: - Tyngdekraften accelerere partiklerne nedad: f gravity = [0, -m g, 0]. (m er atomets masse og for normal dansk tyngdekraft er g=9.82 sm ) Det ses at tyngdeaccelerationen er uafhængig af partiklens masse. - Selvom der ikke er vind af nogen betydning i et rum, har vi alligevel tilføjet en meget simpel vindkraft i scenen som kan styres med tastaturet. Grunden til dette er at det er nemmere at styre springvandets retning interaktivt ved at variere vinden, end det er at styre den ved at variere retningen partiklerns initielle hastighedsvektor, da man med vinden kan se resultatet på alle partikler med det samme. Denne simple vindkraft virker sådan: f wind = w, hvor w er en vektor med vindens retning og styrke - (det at partiklerne bouncer på kassen kan også ses som resultatet af en kraft, men det er ikke implementeret eksplicit som en sådan) 7

9 Tegning af partiklerne: Hver partikel tegnes som en billboarded textured quad. Der er to muligheder for hvilken texture der bruges, for at give springvandet en smule variation. Quaden er centreret omkring partiklens position og bliver længere jo større partiklens y- hastighed er. Vi bruger billboarding på quadene sådan at de altid vender ud mod skærmen. (Havde vi ikke brugt billboarding ville en quad f.eks. være helt flad når man så den fra siden) Udover dette er partiklerne gennemsigtige, hvilket der også skal tages speciel højde for når de tegnes (dette vil blive beskrevet nedenfor). Når en ny partikel laves, initialiseres dens farve og -værdi således (R,G,B, ) = (random()* , 1, 1, random()* ) i WaterParticle constructoren. (Det er også muligt at tegne springvandet som linier i stedet for quads, hvilket kan være nyttigt til debugging. Dette valg sker på compile time.) Billboarding: Partiklerne tegnes som world-oriented billboards med viewplane-alignment og er lavet ud fra beskrivelsen i [RTR] sektion 8.3. Da vores kamera kan rotere om z- aksen (roll) ville det se forkert ud hvis vi brugte screen-alignede billboards. Formålet med billboarding er at vende partiklernes quads mod kameraet (skærmen). Kameraet er altid det globale koordinatsystem i OpenGL. For at vende ud mod skærmen, skal de altså være parallelle med det globale xy-plan. For world oriented billboards skal vi, som beskrevet i [RTR] sektion 8.3.2, bruge kameraets negerede normal-vektor og verdenens up-vektor i globale koordinater. Disse skal bruges til at konstruere en ortonormal basis (ONB) for rotations matricen som billbordet skal orienteres med. Kameraets normal-vektor c n er altid (0,0,-1) og verdens up-vektor w up er y-aksen i globale koordinater efter kameraets transformationer og verdenens egne transformationer er udført. Disse to vektore er ikke nødvendigvis ortogonale, som de jo skal være for at være en ONB. Vi vælger at c n skal være fast mens w up skal justeres sådan at de bliver ortogonale. Valget at c n er fast gør at vores billboards vil være parallelle med xy-planen. Den ortonormale basis konstrueres således: Vi laver først right vektoren r = -c n w up. Den justerede up-vektor w up er: w up = -c n r. Den ortonormale basis bliver nu: ONB = (r, w up, -c n ). 8

10 Lad os se på billboaring koden. Billboarding koden er i partiklernes draw-metode. Først translatere vi hen til positionen hvor quaden skal tegnes, mens vi stadig er i springvandets lokale koordinatsystem: gltranslatef(pos->x, pos->y, pos->z); Derefter finder vi ONB en på overstående måde og overskriver rotations-delen af modelview matricen med denne, men beholder translations delen: r glloadm atrix( 0 w up 0 ' c 0 n oldtranslationvector ); 1 Partiklen tegnes nu som en quad i xy-planen omkring (0,0,0). (det lokale (0,0,0) jo er den position hvor partiklen skal tegnes pga. translationen fra før). Tegning af gennemsigtige objekter: Gennemsigtige objekter (objekter hvis alfa-værdi er mindre end 1) skal renderes med speciel omhu, som beskrevet i [RTR, s.102n] og [1]. Generelt skal gennemsigtige primitiver først renderes efter alle ikke-gennemsigtige primitiver er blevet renderet og de skal tegnes i back-to-front rækkefølge, sådan at de gennemsigtige primitiver længst væk fra kameraet renderes først. Grunden til dette er z-bufferen. Z-bufferen bruges jo til at afvise at putte farven af et fragment ind i colorbufferen, hvis dens z-koordinat er mindre end z-koordinatet af det fragment hvis farve allerede er i colorbufferen. Når vi tegner gennemsigtige objekter er dette ikke helt den opførsel vi ønsker. Hvis vi f.eks. først tegner et ikke-gennemsigtigt primitiv A og derefter et gennemsigtigt primitiv B foran det, vil vi kunne se A bag B. Hvis vi derimod tegnede B først, ville vi ikke kunne se A, da dens fragmenter ville blive afvist af z- buffer testen. Resultatet afhænger altså af rækkefølgen A og B bliver tegnet. Vi skal derfor tegne alle ikke-gennemsigtige primitiver før vi begynder at tegne de gennemsigtige primitiver. Af samme grund skal de gennemsigtige primitiver længst fra kameraet tegnes før dem der er tættere på. Vi sørger derfor for at alle ikke-gennemsigtige objekter tegnes før de gennemsigtige objekter i scenerne. Før vandpartiklernes quads tegnes sorterer vi dem back-to-front og tegner dem i denne rækkefølge. Bemærk at de selvfølgelig skal sorteres efter global z position, ikke lokal z position. Comparatoren der bruges i sorteringen, finder en partikels globale z-koordinat ud fra dens lokale z- koordinat ved at gange dens lokale z-koordinat med modelview matricen. 9

11 (Det kan selvfølgelig lede til en mere kompliceret problem stilling end skitseret her, hvis primitiverne vi tegnede ikke var orienterede parallelt med skærmen og det ikke var helt veldefineret om en quad var foran eller bagved en anden. Her skulle man måske splitte nogle quads op i flere mindre quads. Heldigvis bruger vi billboards, så vi kan uden problemer benytte denne metode). Vandoverfladen: Vandoverfladen er implementeret i WaterPlane klassen og er lavet ud fra beskrivelsen af bølgeligningen i [PMN]. Bølgerne i modellen taber dog aldrig energi, så for at opnå dæmpning har vi ændret formlen til: z(x, y, t t) i j 2 z(x i 1 (2 4, y, t) z(x 2 j, y, t) z(x, y )z(x, y, t) ((1 k t) z(x, y, t t) k t z(x, y, t)) hvor k [0;1] angiver hvor meget bølgerne skal dæmpes. i i i 1 j, t) z(x, y Når en vandpartikel fra springvandet rammer vandoverfladen skal den skabe en forstyrrelse i vandet. Dette sker ved at hit-metoden i WaterPlane objektet bliver kaldt. Metoden bliver kaldt med x og z koordinatet af vandpartiklen og metoden sørger så for at identificere partiklen i vandoverfladen der svarer til dette koordinat. Forstyrrelsen skabes ved at denne partikels y-koordinat bliver formindsket en lille smule. Vandoverfladen kan tegnes på to måder. De enkelte partikler kan tegnes som kugler og overfladen kan tegnes som gennemsigtige trekanter med partiklerne som vertices. Da overfladen er gennemsigtig skal den igen først tegnes efter de ikke-gennemsigtige objekter er blevet tegnet. Den skal dog tegnes før vanddråberne, da man skal kunne se den igennem vanddråberne. Da det i vandoverfladen er meget svært at få øje på fejl pga. manglende sortering, har vi undladt at sorteret trekanterne i back-to-front rækkefølge for at spare CPU tid. i j 1 i i i j 1, t) i i 10

12 Scene 2: Spring-mass Cloth Scene Den anden scene indeholder vores andet partikel system og forestiller et stykke stof der hænger højt oppe over nogle bjerge en tidlig aften. Scenen indeholder partikel systemet for stoffet, en skybox og en lensflare effekt. Med grabberen kan man igen tage fat i kameraet og verdenen. Man kan nu også tage fat i de enkelte partikler i stoffet og man kan styre vindens retning med grabberen. Igen har visse taster speciel betydning f.eks. kan man vælge at tegne de enkelte partikler med p tasten og vælge ikke at tegne selve overfladen af stoffet med t. Tryk igen h for help. Hovedklasserne i denne scene er: - SpringmassScene :selve scenen - SpringSystem : kontrol klassen for partikel systemet - Spring : repræsenterer en fjeder i systemet - Atom : repræsenterer et atom (en partikel) i systemet - Skybox : skyboxen - Lensflare : lensflare effekten 11

13 Scenegrafen for scenen ser sådan ud: camera : Camera world : GroupObject springsystem : SpringSystem skybox : Skybox sun : Cube a 1 : Atom s 1 : Spring winddirection : ArrowObject lensflare : LensFlare a n : Atom s m : Spring Bemærk igen at det gennemsigtige objekt (lensflare) tegnes sidst. Partikel Systemet: Lad os nu se på partikel systemet. Partikel systemet er lavet ud fra beskrivelsen i [PMN]. Systemet er et såkaldt spring-mass system der består af atomer (partikler) og fjedre imellem disse atomer. Hvert atom er forbundet til et antal andre atomer via fjedre. I vores implementation er atomerne placeret i et n n gitter. Hvert atom er bundet til dens horisontale, vertikale og diagonale naboer: Figur: initiel konfiguration hvor n=5. I starten af scenen sættes positionerne af atomerne op og fjedrene forbindes imellem dem. Denne initielle tilstand er hviletilstanden (equlibrium tilstanden). Her er der ingen energi i systemet atomerne har ingen kinetisk energi (de bevæger sig ikke) og der er ingen potentiel energi i fjedrene (de er i hviletilstanden). 12

14 Ved at ændre positionerne eller hastighederne af atomerne (dvs. ved at tilføre energi) vil systemet komme ud af hviletilstanden og fjedrene vil prøve at komme tilbage til deres hviletilstand ved at flytte atomerne de er forbundet til. Hvis en fjeder er presset sammen eller strukket ud, vil den prøve at komme tilbage til dens hviletilstands længde igen, ved at flytte de to atomer den er forbundet til. Dette gør fjedrene ved at udsætte de to atomerne for fjeder kraften der modvirker bevægelsen ved at accelerere atomerne i en bestemt retning og med en bestemt hastighed (denne kraft vil blive beskrevet i flere detaljer nedenfor). Lad os se på de tre klasser partikel systemet består af: Atom klassen repræsenterer et atom i systemet. Klassen indeholder instans variabler for massen, positionen og hastighedsvektoren. Den indeholder listen af fjedrene som atomet er forbundet til. Den indeholder også den totale kraft der påvirker den (denne værdi sættes hver frame af SpringSystem klassen). Til sidst indeholder den også partiklens position fra sidste frame, da dette skal bruges i verlets metode, samt t fra sidste frame, da dette bruges i time-corrected verlet. Spring klassen repræsenterer en fjeder i systemet. Den indeholder pointere til de to atomer den er forbundet til, fjeder-konstanten og dens hviletilstands længde. SpringSystem klassen er kontrol klassen for systemet. Dens constructor sætter atomerne og fjedrene op i gitteret. Som Fountain klassen har denne klasse også en preframe og en draw metode. Preframe metoden udregner kræfterne for hvert atom (incl. fjeder-kræfterne) og kalder derefter preframe metoderne i alle atomerne. Preframe metoderne af de to atomer som stoffet hænger i bliver dog ikke kaldt på denne måde undgår vi at disse atomer bevæger sig. Preframe metoden kaldes heller ikke på et atom, hvis grabberen er ved at flytte det (det ville besværliggøre flytningen en hel del). Atomernes preframe metoder opdatere atomernes position og hastigheds vektore via eulers eller verlets time-corrected metode (hvilken metode der bruges bestemmes på compile time). Fjeder klassen har ingen preframe metode. Kræfter: Lad os nu se på kræfterne der er i vores implementation: - Fjeder Kraften: Denne kraft er kort beskrevet i [PMN]. En fjeder er som nævnt forbundet til 2 atomer. Når atomernes positioner ændres bliver fjederen strukket eller presset sammen (i forhold til dens start-længde (hvilelængden)). Som sagt 13

15 vil en fjeder gerne have hvilelængden og prøver at komme tilbage til den ved at modvirke strækket eller presset via en kraft i den omvendte retning. Begge atomer fjederen er forbundet til påvirkes med samme kraft dog med modsat fortegn. Kraft påvirkningen på et atom a fra en fjeder der forbinder a til et atom b er: f spring_ ab w d d ab ab (D d hvor: - d ab er den nuværende retningsvektor af fjederen med fjederens længde (målt fra a til b for b til a er det omvendt fortegn) - D er hvilelængden af fjederen - w er en fjeder konstant der angiver hvor stiv fjederen er Sidste led af formlen er længden af strækket (målt med fortegn). Vi ser at kraften enten er i d ab retningen eller modsat (hvis D< d ab ). Kraften er altså med andre ord parallel med fjederens retning. Vi ser også at jo større w, jo større er kraften (fjederen er altså mere stiv - kommer hurtigere tilbage til hviletilstanden). Den totale fjeder-kraft på et atom er selvfølgelig summen af kræfterne fra de fjedre som den er forbundet til. (og denne kraft skal selvfølgelig findes inden man ændrer atomernes positioner) - Dampening Kraften: En dampening kraft er en kraft der dæmper bevægelsen af en partikel og dermed styrken af alle kræfter der påvirker partiklen. Den kan ses som friktion af det medium som partiklen bevæger sig i. Kraften virker i modsat retning partiklens hastighed: f dampening = -k dampening_konstant v hvor v er hastighedsvektoren fra den forgående frame for atomet som kraften virker på. (bemærk at da v er fra forgående frame vil kraften altså ikke udslukke alt bevægelse selvom k dampening_konstant =1 da kræfterne fra denne frame stadig vil accelerere partiklen) Denne kraft er nødvendig i vores system fordi det er nødvendigt at dæmpe fjeder kraften. Hvis den ikke blev dæmpet ville stoffet f.eks. hoppe op og ned uden at miste energi, når det blev udsat for tyngdekraften (svarende til at styrken af tyngdekraften og fjederkraften skiftes til at vinde over hinanden), hvilket ikke ser synderligt realistisk ud. Udover at gøre bevægelsen mere realistisk, lader det også til at kraften modvirker ustabiliteten af de numeriske integrations metoder der skal mere til før de eksploderer. ab ) 14

16 - Tyngde Kraften: Denne kraft er f gravity = [0, -m g, 0] som beskrevet tidligere. - Vind kraften: Denne kraft er lavet efter beskrivelsen i [2]. Kraften er lidt anderledes end de tidligere kræfter, da den ikke kun afhænger af de individuelle partikler og fjedre, men mere af hvordan partiklerne bliver sat sammen når de skal tegnes. I vores implementation tegnes klædet som trekanter med atomer som vertices vi skal derfor se hvordan vinden påvirker en trekant. Vi har en vind-vektor w der beskriver retningen og styrken af vinden. Kraft påvirkningen af vinden på en trekant afhænger af styrken af vinden, arealet af trekanten og orienteringen af trekanten i forhold til vindens retning dvs. vinklen mellem trekantens normal-vektor n og vind-vektoren w. Når kraftpåvirkningen på trekanten er fundet tilføjer vi denne kraft til de tre atomer som var vertices i trekanten. Efter alle trekanter er løbet igennem, har hvert atom fået summen af vindkraften fra alle trekanterne som de er vertices i. n f (n w) ( er prikprodukt) wind n Vinden påvirker en trekant i dens normal-vektors retning, som det fremgår af den første faktor. Den anden faktor angiver styrken, som jo afhænger af trekantens areal og orientering i forhold til vinden. Da n er fundet via krydsprodukt mellem to af trekantens sider s 1,s 2 er arealet proportional s1 s2 n med længden af n: A 2 2. Prikproduktet giver os kraftens styrke ud fra arealet A, vindens styrke w og orienteringen n,w : n w n w cos - Grabber: Med grabberen kan man flytte de individuelle atomer med musen. Dette gøres blot ved at ændre atomernes positioner. Dette er altså ikke eksplicit implementeret som en kraft, men svarer jo til at partiklen bliver accelereret i bestemte retninger. Når man flytter et atom vil andre atomer også følge med, pga. fjeder kraften, da de jo er forbundet til hinanden via fjedre. Tegning af partiklerne: Vi har lavet to måder at tegne systemet og systemet kan godt tegnes på begge måder på samme tid. ( p og t tasterne bruges til at slå måderne til og fra) Den første måde er at tegne atomerne som kugler og fjedrene som linier. Jo mere kinetisk energi et atom har og jo mere potentiel energi en fjeder har, jo n, w 15

17 rødere er de. Dvs. jo hurtigere et atom bevæger sig og jo længere en fjeder er fra dens hvilelængde, jo rødere bliver de. Den anden måde er at tegne overfladen af klædet via trekanter med textures. Vi deler hver celle i atom gitteret op i to trekanter, hvor atomerne bruges som vertices: Hver vertex tildeles et texture koordinat og en vertex normal. Vertex normalen findes ud fra dens nabo atomers position via krydsprodukt. Texture koordinaten tildeles sådan at verticen svarende til atom (i,j) i gitteret får texture koordinatet (i/n, j/n). Skybox: Vi har brugt en skybox til at lave omgivelserne i scenen. Skyboxe står beskrevet i [RTR] sektion 8.9. En skybox skaber illusionen af detaljerede omgivelser langt borte i alle retninger. Med de rigtige textures kan det se utroligt overbevisende ud. På trods af dette er de overraskende nemme at lave. Man laver blot en kasse med 6 sider med en texture på hver af disse sider. Man placerer kassen sådan at kameraet er præcis i midten af kassen (kameraet skal til hver en tid være i midten af kassen, så kassen skal ikke flytte sig med resten af verdenen ved translationer). For at man ikke kan se det er en kasse, skal man slå lighting fra, da dette ville gøre det klart at man så på siderne af en kasse. Figur: Vores skybox med lighting slået til. Det ses tydeligt at vi befinder os i en kasse. 16

18 Kameraet altid er placeret i det globale koordinatsystems nulpunkt. Måden vi har sørget for at skyboxen altid er placeret sådan at kameraet er præcis i midten af boxen, er at tegne den centrere omkring nulpunktet og nulstille transitionerne fra modelview matricen før den tegnes på denne måde beholdes rotationerne mens translationerne smides væk. Som nævnt i [RTR] kan der være problemer med at få det til at se helt rigtigt ud de steder hvor texturene fra de forskellige sider af kassen støder op mod hinanden. Vi oplevede kun ét mindre problem af denne art. Til at starte med havde vi brugt texture wrapping funktionen GL_REPEAT (se [RED s.427]). Da vi bruger texture interpolation (GL_LINEAR frem for GL_NEAREST), betød dette at vi fik synlige linier i kanterne af hver texture, da GL_REPEAT funktionen interpolere farven i den ene side af en texture med farven fra den modsatte side. Disse linier gjorde at man godt kunne se det var en kasse. For at undgå dette brugte vi GL_CLAMP_TO_EDGE i stedet (ikke GL_CLAMP da denne interpolere til texturens border-farve i siderne, hvilket kun gør linierne tydeligere). Lensflare: Som beskrevet i [RTR] sektion 8.4 er en lensflare en special effekt der efterligner måden hvorpå det indkommende lys reflekteres i kameralinsen på virkelige kameraer. Denne effekt er forholdsvis nem at efterligne og kan give en forøget fornemmelse af lys intensitet fra lysende objekter. Vores implementation er baseret på beskrivelsen i [3], dog har vi tilføjet nogle udvidelser. En lensflare effekt er i bund og grund en 2D effekt. Det første vi gør er at lave en vektor fra midten af skærmen til lyskildens position på skærmen. Midten af skærmen i globale 2D-koordinater er (0,0) og lyskildens 2D-position på skærmen finder vi ved først at finde dens position i globale 3D-koordinater (ved at se på translations indgangene i modelview matricen) og derefter at projektere positionen på det globale xy-plan: (x p,y p ) = (x/z,y/z). Da midten af skærmen er (0,0) er v=(x p,y p ) vektoren fra midten af skærmen til lyskildens position på skærmen. 17

19 Langs linien der går igennem denne vektor skal vi nu tegne vores haloer og bursts. Vi starter med at normalisere w = v/ v og huske på dens længde v. For at tegne billederne langs linien, skal vi altså blot tegne billederne på linien d*w for et antal passende værdier af d (bemærk at hvis vi sætter d= v tegner vi oven i solen og at negative værdier af d svarer til den modsatte side af (0,0)). Vi tegner haloerne og burstene som screen-alignede texturede quads. Vi tegner disse quads i det globale koordinatsystem (via glloadidentity()) med z=-1 for alle vertices. Dette svarer til screen-aligned billboarding. Kameraets negerede normal vektor og kameraets up-vektor er altid hhv. (0,0,1) og (0,1,0). Rotations matricen quadene skal orienteres efter er dermed altid identitets matricen. Da vores textures er delvist gennemsigtige, skal vores quads først tegnes efter alle ikke-gennemsigtige objekter er blevet tegnet. Da vores lensflare skal være foran alt andet i scenen, slås depth testen fra og de tegnes først efter alt andet (også efter andre gennemsigtige objekter) er blevet tegnet. Lighting slås også fra, da vi ikke er interesserede i at lyskilder i scenen skal påvirke farven af vores textures. (burstene tegnes også efter haloerne, da haloerne ikke skal skygge for burstene) Da det ikke ser godt ud at lensflarene altid er der, også selvom kameraet er rettet langt væk fra solen, bruger vi -værdier til langsomt at fade quadsene ud, jo længere væk (x p,y p ) er fra (0,0). Samtidig bliver quadsne en smule mindre. Punktet (x p,y p ) var jo projektionen af solens position i 3D-rummet på xy-planen. Derfor har (x p,y p ) samme værdi hvis man ser i retningen af den modsatte vinkel mellem solen og xy-planen som hvis man ser på solen. Solen er på den positive side af xy-planet i denne scene, så for at der ikke kommer en lensflare fra ingenting når vi ser mod den omvendte vinkel, tegner vi ikke lensflaren hvis solens globale z<0. Et problem med dette er hvis vi ser direkte eller næsten direkte på solen. I dette tilfælde vil vores quads skygge for solen, da de bliver tegnet oven på den. Da det ikke er meningen at solen skal blive mørkere når man ser direkte på den, fader vi 18

20 quadsene ud jo tættere (x p,y p ) er på (0,0) når (x p,y p ) er indenfor en vis afstand fra (0,0). Når man ser direkte på solen bliver man som regel også blændet. Dette har vi efterlignet ved at lægge en hvid quad over skærmen. Den tegnes som det sidste i scenen, også efter selve lensflaren, så den dækker derfor alt i scenen. Denne quad har normalt =0 og er altså normalt ikke synlig. Men når (x p,y p ) kommer indenfor en vis afstand fra (0,0) skrues alfa værdien op, hvilket gør hele scenen lysere. Dette simulere altså at man bliver mere og mere blændet jo mere direkte man ser på solen. (igen gøres det kun hvis z>0) Figur: På disse screenshots er kameraet roteret så solen kommer tættere og tættere på midten af skærmen. Det ses at lensflaren bliver mere synlig jo tættere solen kommer på midtpunktet af skærmen, optil et vis trin, hvorefter den bliver mindre synlig igen. Det ses også at skærmen bliver lysere, efter et vis trin, jo mere direkte vi ser på solen. 19

21 Scene 3: Spring-mass Jelly Scene Nu hvor vi har lavet en 2 dimensionel spring-mass figur er det jo naturligt og ganske simpelt at udvide den til 3 dimensioner, sådan at vi får en kasse i stedet for et stykke stof. Det eneste der skal ændres er hvordan atomerne og fjedrene sættes op og hvordan polygonerne på overfladen af kassen tegnes (og dermed også hvordan vindkraften påvirker objektet, da den jo afhang af hvordan trekanterne i figuren blev placeret). Kun SpringmassScene og SpringSystem klasserne er ændret i forhold til før. Atom og Spring klasserne er præcis som før. Vores initielle n n n gitter sættes op som før, ved at forbinde naboerne til hinanden, bare det nu er et tredimensionelt gitter i stedet for et todimensionelt. Kassen har dog meget lettere ved at folde ind i sig selv i forhold til klædet, så for at forøge den strukturelle stabilitet en smule, har vi også forbundet nogle af genboerne til hinanden (vi har ikke forbundet diagonale genboer med hinanden). Figur: Initiel konfiguration hvor n=3. På dette screenshot kan man ikke se det, men nogle af genboerne er også forbundet. 20

22 Man kan igen tegne både figurens partikler og fjedre (gøres præcis som før) og tegne en texture på overfladen af kassen. Overfladen tegnes kun på de yderste 6 sider af kassen dvs. ikke mellem atomer inde i selve kassen. Vindkraften virker derfor også kun på de yderste 6 sider af kassen. I virkeligheden burde vinden jo blive stoppet af kassen og ændre retning når den ramte kassen. Dette sker dog ikke i vores implementation vinden går direkte igennem kassen og ud på den anden side. Denne scene var da også blot et hurtigt eksperiment med hvordan det ville se ud at udvide stoffet med en ekstra dimension, så den er ikke helt så finpudset. Kassen kan også stadig folde sig ind i sig selv, hvis man behandler den for hårdt (kunne sandsynligvis forbygges yderligere ved at forbinde flere genboer med hinanden). En positiv observation vi har gjort, er at selv en lille kasse ser flot ud, så man kan altså ganske billigt inkludere en skvulpende kasse af god kvalitet i sine projekter. Konklusion I dette projekt har vi lavet tre scener med forskellige partikel systemer. Den første scene viser et springvand der udsender vandpartikler, som udsættes for bl.a. tyngdekraft og vindpåvirkning. Som det kan ses i hjælpe funktionen til denne scene kan flere parametre ændres vha. bruger input. Dette inkluderer bl.a. vindretning, vandets spredning og vandets retning. Derudover har vi tilføjet en vandoverflade, som påvirkes af partiklerne der rammer overfladen. De to sidste scener er lavet som et springmass system. Scene 2 simulerer et stykke stof, mens scene 3 simulerer en geléagtig kasse, der kan ses som en udvidelse af stoffet med en ekstra dimension tilføjet. Ligesom scene 1 bliver disse objektet påvirket af bruger input og diverse kræfter. Til alle scenerne har vi tilføjet ekstra grafik og effekter for at tilføre lidt mere liv til dem. Vi har bl.a. tilføjet en skybox og lensflare til udendørsscenerne. Euler og Verlet metoderne er numerisk ustabile ved lav framerate og sætter derfor en begrænsning på antallet af partikler. Dette gav os en smule vanskeligheder i starten. Den lettelse måde at fremkalde denne ustabilitet i vores program, er at vælge scene 2 med et stort antal partikler, tegne partiklerne og skubbe lidt til dem. Et andet mindre problem vi havde i starten var at spring-mass systemet ikke tabte energien igen som den blev tilført. Problemet var, som beskrevet tidligere, at tyngdekraften og fjederkraften skiftevis dominerede hinanden, hvilket førte til at klædet hoppede op og ned uden at falde til ro. Dampening kraften blev tilføjet for at løse dette. 21

23 Vi har set, at hvis man har gennemsigtige objekter i en scene, er rækkefølgen objekterne renderes i vigtig. Vi tegner derfor de gennemsigtige objekter til sidst og sortere dem ift. deres z koordinat. Future Work Vi har ikke brugt meget tid på at optimere vores kode, men mere forsøgt at skrive den så den er forholdsvis letlæselig. Det er klart af den i sidste ende burde optimeres, men dette har ikke været vores hoved fokus. At den ikke er optimeret betyder bl.a. at spring-mass systemet, på langsommere computere, vil eksplodere hurtigere end det reelt burde, da t vil blive stor. Da klædet kan gå igennem sig selv og boxen kan folde sig ind i sig selv, kunne vi også se nærmere på collision detection mellem polygonerne de består af. Problemet kan dog i høj grad løses ved at forbinde flere atomer med hinanden via fjedre, som vi gjorde i den 3. scene. Flere steder på nettet, f.eks. på [2], har vi set billeder eller animationer hvor et fast objekt kolliderer med et klæde og derved påvirker positionerne af klædets atomer. Dette kunne også være spændende at se nærmere på. Vi havde oprindeligt snakket om, at oversætte partikel systemerne til GPU en, så det var vertex og fragment programmerne der lavede opdateringerne og renderingen. Vi har lavet små eksperimenter med, at lægge data op og opdatere partikler, men pga. tiden nåede vi ikke at gå i dybden med dette og valgte derfor til sidst at koncentrere os udelukkende om CPU en. Referencer [RTR] : Møller and Haines: Real-Time Rendering, second edition [RED]: Dave Shreiner, Mason Woo, Jackie Neider, Tom Davis: OpenGL programming Guide, fifth edition [PMN]: Peter Møller-Nielsen: Parallel Programming 2006 (PP F06) Lecture notes [1]: OpenGL FAQ / 15 Transparency, Translucency, and Using Blending [2]: Cloths [3]: Alan Gordie: Lens Flare Tutorial [4]: Pixar: Physically Based Modeling [5]: Jonathan lonesock Dummer: A simple Time-Corrected Verlet Integration Method 22