WebGL og grunnleggende 3D transformasjoner
Dette avsnittet beskriver hvordan transformasjonsmatrisene brukes til å gjengi (rendre) 3D-geometri i form av primitiver/trekanter, som settes sammen til objekter/modeller, på en 2D skjerm.
Innhold:
- Normaliserte koordinatverdier
- Steg for å lage et WebGL program
- Graphics pipeline og transformasjoner
- Transformasjonene som utføres av verteksshaderen
- Mer om clipping og culling
- Siste del av graphics pipeline
- En kube bestående av 12 trekanter og 36 vertekser
- En kubeoppgave
Normaliserte koordinatverdier
3D modellene består av et sett primitiver som igjen består av et sett vertekser. En verteks tilsvarer et punkt i rommet, spesifisert vha. koordinatverdiene x, y og z. I tillegg kan man assosiere en farge, teksturkoordinat og normalvektor til en verteks – en verteks kan med andre ord inneholde mer enn bare koordinatverdiene x, y, z.
Man kan tegne primitiver/trekanter direkte på «canvaset» ved å bruke såkalte normaliserte koordinatverdier, dvs. verdiene til x,y og z i området [-1, 1]. Disse verdiene er uavhengig av skjerm/canvas-størrelse og er egentlig koordinatsystemet som OpenGL ES forholder seg til.
Før OpenGL ES kan tegne noe på skjermen kreves det at alle koordinatverdier er innenfor dette området (dvs. [-1, 1]). Bruker vi slike verdier direkte (som hittil) fungerer ting fint. Dette er imidlertid svært begrensende og derfor ikke ønskelig. I tillegg må det være mulig å posisjonere, skalere og rotere modellene.
Det må være mulig å bruke hvilke koordinatverdier som helst for å definere en modell. Deretter må disse transformeres slik at det ender opp i området [-1, 1].
Dette koordinatsystemet vil deretter avbildes («mappes») til canvaset, som tilsvarer det vi kaller «viewport». Normalt vil hele canvaset, dvs. det grønne området i figuren over, tilsvare viewporten.
Når trekanten i figuren over har koordinatverdier i dette området vil den vises på skjermen/canvaset som vist til høyre i figuren. Merk at figuren inkluderer koordinataksene – disse må evt. tegnes vha. egne linjer om de skal vises.
Oppsummert: Dersom man oppgir alle vertekskoordinatene (x,y og z) som normaliserte koordinatverdier, dvs. i området [-1, 1], kan de tegnes direkte på skjermen uten bruk av transformasjoner.
Videre skal vi se hvordan vi kan definere 3D-modeller med vilkårlige koordinatverdier. Vi vil se hvordan modeller defineres i sitt eget, lokale, koordinatsystem og deretter «plasseres» i det «globale koordinatsystemet». Ved hjelp av ulike transformasjoner, kamera og projeksjon vil modellens koordinater til slutt ende opp med normaliserte koordinatverdier som kan gjengis på skjermen med 3D-effekt.
Vi ønsker f.eks. å kunne bruke koordinatverdier som illustrert i figuren under og allikevel få den frem på skjermen som vist under:
Her er trekanten definert av verteksene [-10, -10, 0], [10, -10, 0] og [0, 10, 0]. Koordinatverdiene transformeres (T) deretter slik at de kan fremstilles på skjermen som en trekant som vist til høyre i figuren. Legg merke til at vi ser trekanten i perspektiv – dette vil også bli forklart her.
I WebGL defineres verteksene til figurer/modeller i forhold til et høyrehånds koordinatsystem. Figuren under viser dette i forhold til «skjermen».
Her ser vi at negativ z går «innover» i skjermen mens positiv z går utover. «Øyet» i figuren representerer det «virtuelle» kamera som er med på å bestemme hva som vises på skjermen. Dette peker i utgangspunktet mot negativ z.
Steg for å lage et WebGL program
Kort oppsummert vil et typisk WebGL/Javascript program gjøre følgende for å få tegnet en 3D-modell:
- Definere verteksene til modellen i et tenkt lokalt koordinatsystem. Det er som regel fordelaktig å sentrere modellen om origo.
- Lage en modellmatrise som inneholder en, eller en kombinasjon, av følgende transformasjoner: translasjon, rotasjon og skalering. Vha. modellmatrisa "plasseres" modellen i det globale koordinatsystemet.
- Lage en viewmatrise som spesifiserer hvilken del av «scenen» som skal vises på skjermen. Man tenker seg at man plasserer et kamera i det globale systemet. Det som kameraet «ser» er det som ender opp på skjermen.
- Lage en projeksjonsmatrise. Denne bestemmer hvordan 3D-verden/scenen skal projiseres på skjermen. I tillegg er den med på å avgrense hva som vises.
- Multiplisere sammen modell- og viewmatrisene til en modelview-matrise.
- Sende modelview-matrisa og projeksjonsmatrisa til verteksshaderen.
- Verteksshaderen bruker disse til å transformere hver enkelt verteks. Resten av «jobben», deriblant sammenstilling av primitiver/trekanter, rasterisering m.m. utføres av GPU’en og fragmentshaderen.
Mer om graphics pipeline
OpenGL ES sin «graphics pipeline» viser hvilke steg som inngår for å få definerte modeller og primitiver til å vises på skjermen. Den viser også hvilke transformasjoner som utføres fra verteksene leveres fra WebGL/Javascript-programmet til det endelige bildet kan vises på skjermen.
Shader
Når vi bruker OpenGL ES & WebGL er vi nødt til å forholde oss til shadere. Shadere er programmer, skrevet i sitt eget språk - GLSL, som kjører direkte på maskinens GPU. Man legger som regel shaderkoden som en del av html- eller Javascript-koden.
Verteksshaderen vil normalt transformere hver verteks vha. diverse 4x4 matriser, normalt en såkalt modelview-matrise og en projeksjons-matrise. Disse sendes normalt til verteksshaderen slik at de er tilgjengelig når verteksshaderen transformerer verteksene. Disse matrisene vil bli omtalt mer etter hvert.
Videre skal vi se på et eksempel som tegner en enkel trekant med koordinatverdier (x, y, z) i området -2.5 - +2.5 som transformeres og projiseres slik at den til slutt vises på skjermen.
Kodeeksempel
Vi tar utgangspunkt i et kodeeksempel som tegner en enkel trekant. Verteksene legges i et verteksbuffer. Legg merke til koordinatverdiene til de tre verteksene som utgjør trekanten – disse ligger i området [-2.5, 2.5]. Vi skal også hvordan vi bruker transformasjoner for å rotere og flytte trekanten. Vi ser først på html-fila, index.html:
Tilhørende Javascript-kode, helloTriangle.js:
Programmet bruker et position-array og et color-array, som begge legges inn i hvert sitt Float32Array-buffer. Bufferen brukes til å tegne en enkel trekant på html-canvaset, eller egentlig på canvasets viewport. Viewport tilsvarer den delen av skjermen, hele html5-canvaset i dette tilfellet, som den endelige tegninga vises på. Man kan alternativt definere en mindre del av canvaset som viewport. Kommer tilbake til dette senere.
Posisjonsbufret
Posisjonsbufret opprettes ved hjelp av tre posisjoner siden det er en enkel trekant som skal tegnes – se initBuffers() metoden. Disse har koordinatverdiene:
const positions = new Float32Array([ 0.0, height/2, 0.0, // X Y Z -width/2, -height/2, 0.0, // X Y Z width/2, -height/2, 0.0 // X Y Z ]);
Fargebufret
Vi bruker et eget buffer for fargene. Merk at det må være like mange farger som posisjoner. Hver verteks består dermed av en posisjon og en farge. Fargebufret opprettes vha. følgende array:
const colors = new Float32Array([ 1, 0.3, 0, 1, //R G B A 1, 0.3, 0, 1, //R G B A 1, 0.3, 1, 1, //R G B A ]);
Disse tre verteksene (posisjon+farge) vil bli sendt, en og en, til verteksshaderen etter at drawArrays() er utført, se draw() metoden. I draw() koples posisjon- og fargeattributtene til tilsvarende buffer. Deretter opprettes objektet cameraMatrixes via initCamera(). Dette inneholder view- og projeksjonsmatrisa. Deretter opprettes modellmatrisa som flytter modellen litt til venstre og litt opp, samt roterer den 30 grader. Vha. modellmatrisa og view-matrisa opprettes modelview-matrisa. Modelview- og projeksjonsmatrisa sendes så til verteksshaderen før vi kaller på drawArrays().
Modellmatrisa gjør at modellen flyttes litt (-3) til venstre og litt (1) opp. View-matrisa sørger for å plassere kameraet i [0,0,10] orientert mot origo. Kamera må peke mot modellen for at den skal vises på skjermen. Disse to matrisene slås sammen til en modelview-matrise. Her er det viktig at matrisene multipliseres i korrekt rekkefølge. Kodelinja
modelviewMatrix = viewMatrix.multiply(modelMatrix);
betyr at matrisene slås sammen slik:
modelviewMatrix = viewMatrix * modelMatrix
dvs. at rad1 i viewMatrix multipliseres med kolonne1 i modelMatrix for å beregne første element (e11) i modelviewMatrix osv.
Projeksjonsmatrisa er med på å begrense hvilken del av 3D-verden som skal vises på skjermen samt å sørge for at alle verteksene omgjøres til såkalte «clip-koordinater». Disse matriseoperasjonene vil bli forklart nærmere i neste avsnitt.
I verteksshaderen er følgende parametre definert:
#version 300 es
in vec3 aVertexPosition;
in vec4 aVertexColor;
uniform mat4 uModelViewMatrix;
uniform mat4 uProjectionMatrix;
out lowp vec4 vColor;
void main(void) {
gl_Position = uProjectionMatrix * uModelViewMatrix * vec4(aVertexPosition, 1.0);
vColor = aVertexColor;
gl_PointSize = 10.0; //Merk: Kun i bruk når man tegner POINTS
}
Den første, aVertexPosition av type vec3 representerer verteksen som kommer fra WebGL/Javascript-koden. Denne endres for hver verteks. Den andre, aVertexColor, representerer fargeverdien. De to neste er 4x4 matriser som også kommer fra WebGL/Javascript-koden men har samme verdi for alle vertekser (derfor nøkkelordet uniform). Parametret vColor er en «output»-variabel som lar oss videresende aVertexColor til fragmentshaderen (husk: fargeverdien interpoleres mellom verteks- og fragmentshaderen).
Videre ser vi at den innebygde variabelen gl_Position settes lik aVertexPosition multiplisert med de to nevnte matrisene (NB! Må gjøres i korrekt rekkefølge, mer etter hvert).
Legg også merke til at aVertexPosition gjøres om slik at homogene koordinater benyttes. Dette gjøres vha. vec4(aVertexPosition, 1) slik at den «homogene verteksen» blir (x,y,z,1). Se eget notat om vektorer og matriser som forklarer mer om homogene koordinater.
Variabelen gl_Position er en GLSL spesifikk variabel. Hovedoppgaven til verteksshaderen er å gi denne variabelen en verdi. Som regel settes den lik produktet av verteksen, modellview- og projeksjonsmatrisene. Verteksen sine koordinater (x,y,z,w) er nå gjort om til såkalte "clip-koordinater". Se figur under.
Graphics pipeline og transformasjoner
I WebGL snakker man gjerne om følgende transformasjoner:
- Modelltransformasjon
- View-transformasjonen
- De to foregående slås ofte sammen til en transformasjon (matrise): «Modelview»- transformasjonen
- Projeksjonstransformasjonen
Disse transformasjonene utføres vha. 4x4 matriser.
I tillegg utføres (automatisk, vi trenger egentlig ikke tenke på dette):
- «Perspective division», dvs. gjøre om fra homogene koordinater tilbake til kartesiske koordinater. Dette gjøres ved å dele x,y og z på den 4. koordinatverdien, w.
- Viewport-transformasjon.
Disse punktene forklares nærmere i etterfølgende kapitler.
Verteksshaderen
Normalt utføres både modelview-transformasjonen og projeksjonstransformasjonen i verteksshaderen vha. matrisemultiplikasjon. Dette ser vi også i kodeeksemplet over.
Både viewport-transformasjonen og «perspective division» utføres (automatisk) i steget etter verteksshaderen, dvs. i steget "Sammenstilling av primitiver".
Vi ser dette i figuren under, som er et utsnitt av tidligere vist graphics pipeline.
Verteksshaderen utfører vertekstransformasjonen ved å multiplisere verteksen med både modelview- og projeksjonsmatrisa. Dette betyr at shaderen må ha tilgang på disse matrisene. Normalt leveres disse fra «klientprogrammet» (WebGL/Javascript) før verteksene sendes til shaderen.
Etter at verteksen er multiplisert med modelview-matrisa sier vi at verteksene er transformert til «øye-koordinater». Hvorfor det kalles «øye-koordinater» vil bli tydeligere når vi ser mer på view-transformasjon.
Den transformerte verteksen multipliseres så med projeksjonsmatrisa og er da transformert til «clip-koordinater». Den transformerte verteksen tilordnes til slutt i verteksshaderen til gl_Position.
Sammenstilling av primitiver (trekanter)
I neste steg av pipelinen, «Sammenstilling av primitiver», vil koordinatene som er tilordnet gl_Position, som fortsatt består av homogene koordinater, divideres med w.
Verteksen er nå omgjort til såkalte NDC (Normalized Device Coordinates). Det vil si at alle vertekser som har koordinatverdier (x, y og z) i området [-1, 1] vil være med videre i pipelinen. Vertekser med koordinater utenfor dette området vil «clippes» vekk – de er ikke med videre. Primitiver som er delvis innenfor deles i to. Tenk på dette som om frustumet strekker seg fra -1 til +1 i x,y og z-retning.
Deretter utføres «viewport»-transformasjonen (dette gjøres ikke ved hjelp av en matrise), dvs. at NDC mappes til det området på skjermen som skal vise resultatet.
Beregning av dybde; z-buffer
Basert på z-verdien til NDC beregnes det en z-/dybdeverdi, i området 0-1, per fragment. Verdien legges i z-/dybde-bufret og er med på å bestemme om nye fragmenter skal vises eller ikke.
Se også (OpenGL Wiki, Vertex Transformation, 2012) for mer info.
Rasterisering
Etter «viewport»-transformasjonen utføres rasterisering som betyr å fylle primitivene (trekantene) med nødvendige fragmenter/piksler.
Modellene/trekantene er nå brutt ned til et sett fragmenter. Et fragment er en «kandidat» til å bli en piksel i skjermbufret, ikke alle fragmenter ender opp som piksler i skjermbufret. Hvert fragment sendes nå til fragmentshaderen (kalles pikselshader i Direct3D-terminologi).
Fragmentshaderen
Dette er, som verteksshaderen, et program som kjøres av GPUen. Her settes eller beregnes fargen til hver enkelt piksel som utgjør det indre av trekanten. Fargeverdien, vColor, til "innkommende" fragment er en interpolert (utjevnet) verdi som er basert på trekantenes verteksfarger.
Fragmentshaderen mottar en farge som et parameter, her har vi kalt den vColor (et in-parameter). I sin enkleste form vil fragmentshaderen kun videresende denne ved å sette out-parametret fragColor lik in-parametret vColor. Alternativt kan den f.eks. gjøre ulike lysberegninger som påvirker endelig farge på fragmentet. Uansett må fragmentshaderen videresende minst en fargeverdi, her vColor. I praksis betyr dette som regel å sette fragColor=vColor.
Alternativt kunne man latt vær å bruke verteksfarger og i stedet la alle pikslene få samme farge vha. en uniform-parameter i fragmentshaderen. Mer om dette senere.
Oppsummering
Hele prosessen kan forenklet illustreres slik:
Transformasjonene som utføres av verteksshaderen
La oss nå se mer detaljert på de ulike transformasjonene som verteksshaderen utfører.
Modelltransformasjonen
Når man opererer med mange modeller er det enklere å definere hver enkelt 3D modell i forhold til et lokalt koordinatsystem (model space) i stedet for et globalt/scene koordinatsystem. Tenk deg at du skal arrangere en miniatyrscene for et filmopptak hvor det inngår modeller som biler, hus, tog, trær osv. Modellene som skal fotograferes må bygges. I stedet for å bygge disse direkte i miniatyrverdenen vil man typisk bygge disse i et verksted (e.l.) før man plasserer dem i scenen.
På tilsvarende måte konstrueres 3D modeller i WebGL. Modellene defineres i forhold til et tenkt lokalt koordinatsystem (model space) og gjerne sentrert rundt origo. Deretter "plasseres modellen" i det "globale" koordinatsystemet (world space) ved hjelp av en koordinattransformasjon / matrisemultiplikasjon. Se (Luna, 2006), (Angel E. & David S., 2015) og (Matsuda et al., 2013, vedlegg G).
Når vi i Javascript-koden spesifiserer en modell, f.eks. en kube, oppgir vi verteksene i et tenkt lokalt koordinatsystem. Verteksene sine koordinater kalles da modellkoordinater. Vha. en modelltransformasjon kan vi posisjonere og orientere kuben i det globale koordinatsystemet (world space).
Hver enkelt modell har sin egen modelltransformasjon. Når alle modellene er transformert inn i det globale koordinatsystemet er alle i samme koordinatsystem. En modelltransformasjon består normalt av en eller flere av følgende i kombinasjon:
- Translasjon (forflytning)
- Rotasjon
- Skalering
Det fine med dette er at man kan definere modellene uavhengig av hverandre for deretter å gjøre en modelltransformasjon slik at modellen plasseres i det globale systemet sammen med andre modeller.
Dersom man f.eks. definerer et hus spesifiserer man alle verteksene i modellkoordinater for deretter å gjøre nødvendige transformasjoner. Dette kan f.eks. bety å skalere huset opp eller ned, rotere og evt. flytte det dit man måtte ønske i forhold til det globale systemet. Se figuren under.
Den sammensatte transformasjonen representeres av en 4x4 matrise som multipliseres med alle verteksene.
Legg merke til at dersom man setter modellmatrisa lik identitetsmatrisa vil modellen «plasseres direkte» i det globale systemet.
Dette betyr at dersom man ikke angir en modellmatrise, eller den settes lik identitetsmatrisa, utføres ingen rotasjon, skalering eller translering av opprinnelig modell.
View-transformasjonen
Det finnes egentlig ikke noe kameraobjekt i WebGL/OpenGL ES. Vi tenker oss i stedet at vi plasserer et kamera et sted i det globale koordinatsystemet og orienterer det mot objektene/modellene som vi ønsker skal vises på skjermen. Se figuren under.
Vha. view-transformasjonen kan vi posisjonere og orientere dette «virtuelle» kameraet der vi måtte ønske. I utgangspunktet, dvs. dersom view-matrisa = identitetsmatrisa, står kameraet i origo og ser langs negativ z-akse. Dette betyr at kameraet i utgangspunktet ikke nødvendigvis vil se alle modeller/figurer. For at kameraet skal se modeller som er bak eller ved siden av kameraet må enten modellene flyttes foran kameraet eller så må kameraet flyttes og roteres slik at det ser modellene.
Ved hjelp av view-matrisa transformeres verteksene til modellen(e) motsatt i forhold til hvor du ønsker å flytte kamera (man kan tenke seg at kameraet står i origo og at modellene flyttes i forhold til dette).
Dersom man tenker seg at kameraet skal flyttes +5 enheter langs z-aksen vil det være det samme som om vi flyttet modellen(e) -5 enheter langs z-aksen. Modell- og view-transformasjonene er egentlig to sider av samme sak. Dette vil bli nærmere forklart i avsnittet om modelview-transformasjonen.
View-transformasjonen består egentlig av en kombinasjon av en translasjon og en rotasjon.
Etter view-transformasjonen er koordinatene transformert til øyekoordinater (og modellen er i «view space»).
Ved hjelp av funksjonen mat4.lookAt(parametre) kan man generere en View-matrise. Parametrene til denne funksjonen omfatter bl.a. kameraets posisjon og punktet det peker/ser mot.
Bruk av glMatrix-biblioteket (bruker også vec3-klassen):
let v3Eye = vec3.fromValues(7.0, 6.0, 16.0); //Eksempler let v3Look = vec3.fromValues(0.0, 0.0, 0.0); let v3Up = vec3.fromValues(0.0, 1.0, 0.0); let viewMatrix = mat4.create(); mat4.lookAt(viewMatrix, v3Eye, v3Look , v3Up);
Bruk av cuon-matrix.js (Matsuda et al., 2013) biblioteket:
let viewMatrix = new Matrix4(); viewMatrix.setLookAt(eyeX, eyeY, eyeZ, lookX, lookY, lookZ, upX, upY, upZ);
Eye-koordinatene tilsvarer kameraets posisjon. Look- koordinatene tilsvarer punktet kameraet peker mot mens Up-koordinatene definerer hva som er opp/ned på kameraet (som regel upX=0, upY=1, upZ=0).
Når man spesifiserer viewmatrisa er det selvfølgelig viktig at kameraet peker mot modellen(e), hvis ikke vil den ikke vises på skjermen. Som vi straks skal se vil også projeksjonsmatrisa være med på avgrense hva som ender opp på skjermen.
Modelview-transformasjonen
Modell- og viewtransformasjonene er i praksis to like operasjoner i forhold til hvordan den endelige scenen blir seende ut. Det viktige er forholdet mellom kameraet og modellen(e) i scenen. Anta at et kamera og en modell som begge er plassert i origo og at kameraet ser mot negativ z-akse. Dersom kameraet skal «se» modellen må enten modellen flyttes mot negativ z eller kameraet mot positiv z. Begge operasjonene er i prinsippet samme ting.
Enten flytter man modellen i den ene retninga eller så flytter man kameraet i motsatt retning.
Begrepet «modelview» betyr at modell- og viewtransformasjonsmatrisene slås sammen til en matrise.
I enkelte tilfeller kan det være praktisk å håndtere disse som to separate matriser men de må uansett slås sammen for å få utført korrekt transformasjoner på verteksene. I praksis vil man ofte slå sammen disse to matrisene i Javascript-koden og sende resultatmatrisa (altså «modelview-matrisa») til verteksshaderen. Alternativt kan begge sendes inn til shaderen som da får ansvaret for å multiplisere disse sammen.
I tidligere versjoner av både standard OpenGL og ES-versjonen var det ikke støtte for programmerbare shadere («fixed function pipeline») og her opererte man kun med modelview-matrisa.
Projeksjonstransformasjonen
Denne transformasjonen skjer etter modelview-transformasjonen. Transformasjonen sørger for å projisere den delen av 3D-verdene/scenen som kameraet peker mot til en 2D-flate (skjermen). Den bestemmer også hvordan «viewvolumet» ser ut og begrenser dette til en «enhetskube» som strekker seg fra -1 til 1 i alle tre akser (x,y,z).
En vanlig analogi innen 3D grafikk er å sammenlikne modell-, view- og projeksjonstransformasjonene med det å ta et bilde med et kamera. Modelltransformasjonen tilsvarer det å plassere modellene i scenen. View-transformasjonen tilsvarer å plassere og orientere kameraet mot modellene(e) mens projeksjonstransformasjonen tilsvarer det å velge en linse til kameraet. Kameralinsa påvirker hva kameraet ser og til en viss grad hvordan modellene vil se ut.
Det finnes to typer projeksjoner:
- Ortografisk projeksjon
- Perspektivprojeksjon
Disse er omtalt under.
Ortografisk projeksjon
Ortografisk projeksjon kalles også parallell projeksjon siden parallelle linjer fortsatt er parallelle etter projeksjonen. Ortografisk projeksjon betyr også at størrelsen til modeller ikke påvirkes av avstanden til kameraet - man får dermed ingen dybdefølelse. Man får med andre ord mindre realisme i scenen som fremvises. 3D effekten blir mindre om ikke fraværende. Ortografisk projeksjon kan imidlertid være nyttig i CAD (Computer Aided Design) - systemer eller om man ønsker å lage 2D grafikk i WebGL.
Når ortografisk projeksjon brukes vil «view-volumet» være en rektangulær boks. Primitiver (trekanter) som faller innenfor volumet vil projiseres på «near clip plane» (se figur under) og vises i den endelige scenen. Primitiver som er delvis innenfor vil «klippes»/deles opp. Resten vil ikke vises, dvs. verteksene til primitiver som faller utenfor blir ikke sendt videre i «pipelinen».
Man kan f.eks. bruke mat4.ortho(…) funksjonen, definert i glMatrix, til å generere en ortografisk matrise:
mat4.ortho(projectionMatrix, left, right, bottom, top, near, far);
Dette vil gi en ortografisk projeksjonsmatrise, projectionMatrix, som vil sørge for at alle primitiver (/modeller) som ligger innafor volumet, skissert over, projiseres på «near plane» og dermed vil vises på skjermen.
Perspektivprojeksjon
Når man bruker perspektivprojeksjon vil modeller som er langt unna kamera virke mindre enn de som er nærmere kamera. Dette gir en mer realistisk fremstilling og dermed en bedre 3D illusjon siden det er slik våre øyne fungerer – ting som er langt unna virker mindre enn det som er rett ved siden av oss.
View-volumet som genereres ved perspektivprojeksjon kalles et frustum som ser ut som en avkappet pyramide.
Vertekser (og dermed primitiver og objekter) som ligger helt eller delvis innenfor denne pyramiden representerer det som kameraet ser. Denne transformasjonen sørger dermed for to ting:
- hvordan objekter projiseres til 2D (skjermen)
- hvilke objekter eller deler av objekter som skal utelates i det endelige bildet
Etter transformasjonen vil aktuelle vertekser være projisert på near clip plane.
Det er to typer funksjoner man kan bruke til å generere en projeksjonsmatrise:
- perspective() / setPerspective()
- frustum()
Den første av disse har følgende parametre:
glMatrix-biblioteket:
let projectionMatrix = mat4.create(); mat4.perspective(projectionMatrix,fovy, aspect, near, far);
cuon-matrix.js:
let projectionMatrix = new Matrix4(); projectionMatrix.setPerspective(fovy, aspect, near, far);
Parametrene er som følger:
- fovy: vertikal “field of view”. Merk: cuon-matrix sin setPerspective bruker grader, mens gl-matrix sin perspective() bruker radianer.
- aspect: bredde til viewport / høyde til viewport (eks. canvas.width / canvas.height)
- near: near clip plane (f.eks. 0.1)
- far: far clip plane (f.eks. 1000)
- projectionMatrix: resultatmatrisa etter kall på denne funksjonen
Se også figur under:
Matrisa kan beregnes slik:
Man kan også bruke frustum() funksjonen til å generere en perspektivmatrise. Denne har parametrene (glMatrix):
mat4.frustum(projectionMatrix, left, right, bottom, top, near, far);
Left, right, top og bottom tilsvarer bredde og høyde på near-plane, dvs størrelsen på området som 3D-verden skal projiseres ned på. frustum() er mer generisk enn perspective() og perspective() er implementert vha. frustum(). Cuon-matrix biblioteket har en tilsvarende funksjon.
Matrisa kan beregnes slik:
Vi har nå en projeksjonsmatrise. Denne sendes inn til verteksshaderen, på samme måte som modelviewmatrisa. Se kodeeksemplet over.
Perspektivprojeksjon består egentlig av en kombinasjon av skalering og translasjon.
OppsummertHele prosessen kan oppsummeres i følgende figur:
Figuren viser alle transformasjoner som utføres fra modellen spesifiseres vha. modellkoordinater til modellen ender opp på skjermen i skjermkoordinater. Modellkoordinatene multipliseres med modellmatrisa slik at de transformeres til "world" koordinater. Disse multipliseres med view-matrisa og gir "øye"-koordinater (NB! som regel utføres dette i et steg ved at modellkoordinatene multipliseres med modelview-matrisa). Disse multipliseres med projeksjonsmatrisa og verteksene er i "clip"-koordinater som også er det som verteksshaderen leverer fra seg. Resten håndteres av "pipelinen": Neste steg er å konvertere fra homogene koordinater (verteksshaderen opererer med homogene koordinater) til kartesiske koordinater ved å dele på w. Vi har nå normaliserte koordinater (NDC). Disse gjøres til slutt om til skjermkoordinater vha. "viewport"-transformasjonen.
Se Vedlegg1 for komplett gjennomgang og talleksempel.
Mer om clipping og culling
Vertekser og trekanter som faller innafor frustumet vil kunne ende opp på skjermen. En trekant kan ha tre posisjoner i forhold til frustumet:
- Innenfor
- Utenfor
- Delvis innenfor
Når trekanten er innenfor frustumet vil den henge med til neste steg i pipelinen. Trekanter som faller (helt) utenfor ”culles” dvs. fjernes for videre behandling. Trekanter som faller delvis innenfor deles i to. Delen som faller innenfor beholdes mens den andre delen ”culles”.
Det kan nevnes at moderne grafikkort automatisk ”culler” det som faller utenfor frustumet. Men, og dette er viktig, det betyr ikke at WebGL-programmet automatisk vet hvilke objekter som ligger innafor frustumet og hvilke som ligger utenfor (dette bestemmes jo av View og projeksjonsmatrisene). Dette betyr igjen at dersom vi har en stor scene med mange objekter som skal tegnes og kameraet peker en vei vil tegnekommandoen (drawArrays()) bli utført for alle objekter uansett om de ligger innafor eller utenfor frustumet. Grafikkortet/pipelinen vil imidlertid sørge for å fjerne objekter som faller utenfor.
For mer effektiv tegning/rendring kan man allerede i WebGL-koden sørge for at det som faller utenfor frustumet ikke tegnes – dette kalles frustum culling. For enda bedre resultat kan man også sørge for ikke å tegne objekter som ligger bak andre objekter og som uansett ikke skal vises – kalles occlusion culling.
Siste del av graphics pipeline
Her omtales kort de siste blokkene i figuren (over) som viser OpenGL ES graphics pipeline.
Scissor test, Stencil test, Depth test, Blending
Den nest siste blokka kalles «Diverse fragment/piksel-operasjoner». Disse omtales kort her.
Selv om pikselfargene er beregnet og returnert fra fragmentshaderen kan fragmentet fortsatt bli forkastet pga. ulike tester som utføres i dette steget.
Scissor test:
Man kan sette et såkalt ScissorRectangle for å begrense tegning til en mindre del av skjermen/vinduet. Settes på GraphicsDevice-objektet.
Stencil test:
Bruker et spesielt buffer, et stencil buffer, og brukes i spesielle tilfeller til avanserte rendringsteknikker.
Depth test:
Ved hjelp av verteksene beregnes også dybdeinformasjon til hver enkelt fragment – hver enkelt fragment har tilknyttet dybdeinformasjon. Dette lagres i et eget buffer som kalles z-buffer eller bare dybde(depth) buffer. Dette er med på å avgjøre hvilke modeller som ligger fremst i bildet og dermed skal vises og hvilke som ikke skal med i det endelige bildet.
Alpha blending:
Dersom alpha blending benyttes vil fragmentets farge blandes med fargen til andre fragmenter (som ligger over eller under).
Frame buffer
I det siste steget i pipelinen lagres pikslene i frame bufret som også er det som til slutt vises på skjermen.
Eksempel: Fra modellkoordinater til skjermkoordinater
Se gjennomgang i Vedlegg1 . Her gjennomgås et eksempel med alle transformasjonene, med tallverdier, fra verteksene sendes inn til verteksshaderen til trekanten ender opp på skjermen.
En kube bestående av 12 trekanter og 36 vertekser
I dette avsnittet skal vi se hvordan man kan definere og tegne en kube som tegnes i perspektiv ved hjelp av view- og projeksjonsmatrisene. Sidene til kuben skal ha ulike farger og skal se omtrent slik ut.
Vi tar utgangspunkt i følgende figur for å definere nødvendige vertekser:
Her ser vi kuben og verteksposisjonene til kubens hjørner. Det er også antydet at hver side av kuben består av to trekanter. I tillegg er koordinataksene vist. Dersom kuben tegnes vha. drawArrays(gl.TRIANGLES, …) kan følgende verteksposisjonsarray benyttes:
//KUBEN:
//36 verteksposisjoner:
let cubeVertices = new Float32Array([
//Forsiden (pos):
-1, 1, 1,
-1,-1, 1,
1,-1, 1,
-1,1,1,
1, -1, 1,
1,1,1,
//Høyre side:
1,1,1,
1,-1,1,
1,-1,-1,
1,1,1,
1,-1,-1,
1,1,-1,
//Baksiden (pos):
1,-1,-1,
-1,-1,-1,
1, 1,-1,
-1,-1,-1,
-1,1,-1,
1,1,-1,
//Venstre side:
-1,-1,-1,
-1,1,1,
-1,1,-1,
-1,-1,1,
-1,1,1,
-1,-1,-1,
//Topp:
-1,1,1,
1,1,1,
-1,1,-1,
-1,1,-1,
1,1,1,
1,1,-1,
//Bunn:
-1,-1,-1,
-1,-1,1,
1,-1,1,
-1,-1,-1,
1,-1,1,
1,-1,-1
]);
For å få farge på kubens side angir vi også en farge per verteks vha. følgende array:
//36 verteksfarger, bruker ulike farger på hver side av kuben:
let colors = new Float32Array([
//Forsiden:
1.0, 0.0, 0.0, 1,
1.0, 0.0, 0.0, 1,
1.0, 0.0, 0.0, 1,
1.0, 0.0, 0.0, 1,
1.0, 0.0, 0.0, 1,
1.0, 0.0, 0.0, 1,
//Høyre side:
0.0, 1.0, 0.0, 1,
0.0, 1.0, 0.0, 1,
0.0, 1.0, 0.0, 1,
0.0, 1.0, 0.0, 1,
0.0, 1.0, 0.0, 1,
0.0, 1.0, 0.0, 1,
//Baksiden:
1.0, 1.0, 0.0, 1,
1.0, 1.0, 0.0, 1,
1.0, 1.0, 0.0, 1,
1.0, 1.0, 0.0, 1,
1.0, 1.0, 0.0, 1,
1.0, 1.0, 0.0, 1,
//Venstre side:
0.0, 0.0, 1.0, 1,
0.0, 0.0, 1.0, 1,
0.0, 0.0, 1.0, 1,
0.0, 0.0, 1.0, 1,
0.0, 0.0, 1.0, 1,
0.0, 0.0, 1.0, 1,
//Topp
1.0, 0.0, 1.0, 1,
1.0, 0.0, 1.0, 1,
1.0, 0.0, 1.0, 1,
1.0, 0.0, 1.0, 1,
1.0, 0.0, 1.0, 1,
1.0, 0.0, 1.0, 1,
//Bunn:
0.5, 0.7, 0.3, 1,
0.5, 0.7, 0.3, 1,
0.5, 0.7, 0.3, 1,
0.5, 0.7, 0.3, 1,
0.5, 0.7, 0.3, 1,
0.5, 0.7, 0.3, 1
]);
En kubeoppgave
Som vist kan man tegne en kube ved å angi 36 verteksposisjoner og farger og bruke drawArrays(gl.TRIANGLES…) til å tegne kuben. En annen mulighet er å bruke færre verteksposisjoner og drawArrays(gl.TRIANGLE_STRIP, …). Definer så få vertekser som nødvendig for å kunne tegne en kube vha. drawArrays(gl.TRIANGLE_STRIP, …)
Bruker vi indekser til å tegne kuben holder det å angi 8 vertekser i tillegg til 36 indekser.
Tegn samme kube vha. indekser og drawElements(). Bruk følgende figur som utgangspunkt for å definere kubevertekser og indekser:
Kuben består av 8 vertekser der en verteks har sin posisjon, f.eks. [-1,1,1]. Verteksene gjenbrukes vha. indekser. Hver side av kuben består av to trekanter definert av 6 indeksverdier som vist i lista til høyre i figuren. Fronten av kuben er f.eks. definert av trekantene tilsvarende indeksverdiene 0,1,2 og 0,2,3. Her angis verteks(indeksene) til trekantene mot klokka.
