Screenshots fra onsdagens fremvisning

Her er lige et par sceenshots fra vores terrain-motor:

Terrain rendering

Vi har som vores selvvalgte emne valgt at lave en terrain-motor der skal understøtte følgende features:

• Level Of Detail
• Streaming a store terrain-heightmaps for nærmest uendelig store terræner.

Vi startede simpelt ved at lave en extension til OpenEngine som loader et heightmap fra en fil givet i constructoren og derved genererer et terrain over det og sender det til grafikkortet til senere rendering.

Den første test tegnede kun prikker for hver pixel i vores heightmap.

Vi har i skrivende stund mulighed for at oprette vilkårligt mange terrain-objekter med hver deres skalering og position:


Når vi loader vores heightmap laver vi en triangle strip som simpelthen kører fra venstre mod højre og tilbage igen ned igennem hele vores heigtmap.
Dette giver et slags zig-zag mønster hvis man ser det i wireframe, men kan ellers ikke ses. Vi synes dette var den simpleste metode for at lave en hurtig rendering af vores terræn. Man kan måske argumentere for og imod metoden, men den tegner ret hurtigt. Vores 2 heightmaps er hver 256x256 store, hvilket giver ialt 4*256² polygoner (262.144 polygoner) som den tegner i realtime på omkring 150 FPS.

Derefter var det relativt simpelt at tilføje en texture til terrainet.





Vi er dog igang med at finde en bedre metode til at udregne normalerne til polygonerne så det bliver mere behageligt at se på.

Uge 5

Der er ikke så meget at rapportere fra denne uge, vi fik fysikken til at virke
uden alt for store problemer.

Vi stødte dog på en træls ting, vi brugte ikke en boost::shared_ptr ordenligt.
Det var godt nok vores egen skyld at vi ikke læste dokumentationen ordenligt,
men det er også lidt et problem at bruge sådan en halv løsning; rigtig garbage
collection eller en mere eksplicit memory management ville nok være bedre end
en skrøbelig reference counting.

Tror ikke der er meget at sige om vores fysik implementation, tror vi har lavet
det på samme måde som de andre grupper. En kasse med 9 punkter og en masse
distance constraints imellem de punkter. Vi nåede ikke at tweake det helt så
det er stadig ret ustabilt.

Netværksmodul til OpenEngine

Ud over de opgaver vi skulle lave til denne uge, har vi også lavet et lille netværksmodul. Tanken bag dette er at hvis man skal få følelsen af at det er et spil vi sidder og arbejder på, så skal man også kunne konkurrere løbende, så man kan få en oplevelse af om de enkelte elementer man arbejder på, giver det ønskede resultat - rent spillemessigt. Dertil syntes vi det kunne være sjovt at dyste mod hinanden gruppevis, uafhængig af hvilken modifikationer vi har lavet på OpenEngine. Derfor er udgangspunktet for modulet også at man blot tildeler en Transformation node til modulet. Modulet vil så selv sende ændringer om denne Transformation node videre til serveren og derved alle andre spillere. For at bevare en cross-platform mulighed er SDL_net valgt som netværksbibliotek.

Til alle de andre grupper der ønsker at forsøge sig med vores netværksmodul, så er der en patch her.

BSP træer

Screenshots:
1: Wireframe udgave af den originale FutureTank
2: Wireframe udgave af FutureTank splittet op efter at have genereret BSP træ over den.
3: Gennemsigtig tank tegnet back to front (korrekt rækkefølge for gennemsigtighed)
4: Gennemsigtig tank tegnet front to back (forkert rækkefølge)

Generering af BSP-træet

Vores BSP generering udvælger stadig ikke helt den mest optimale face at splitte med først. Lige nu tager den bare og splitter med den første face i hvert FaceSet den finder. Dette er overhovedet ikke balanceret og genererer en hel del unødige splits, men det er til senere optimering med en langt bedre algoritme.

Rendering af BSP træet

Efter at vi har genereret vores BSP-træ kan vi så rendere modellen ved hjælp af den. Vi traverserer rekursivt ned igennem alle BSP-Nodes fra roden af træet, og besøger altid den BSPNode som er længst væk fra kameraet og derefter den anden rekursivt. Det giver en sortering fra "back to front" (screenshot 3). Hvis man besøger den BSPNode som er tættest på først vil man lave en "front to back" gennemgang og det vil resultere i screenshot 4.

Vi fandt ud af at Resource Manageren var buggy da den ikke kunne finde ud af at hente resourcer fra BSP træer så det resulterede i en helt hvid model (ingen texture). Et fix ville være at tilføje den funktionalitet til Resource Manageren men da den efter sigende skulle være mere buggy end som så, da har vi valgt en midlertidig løsning hvor vi i hvert af bladene på BSP træet har en GeometryNode indeholdende et enkelt Face da Resource Manageren godt kan finde ud af at hente resourcer ud fra GeometryNodes.

Quad Tree

Det lykkeds os at implementere Quad-Træet, men det skete over to omgange. Første omgang kiggede tildelte vi rekursivt hvert face til kun én ny Quad. Selvom dette teoretisk burde give fejl ved manglede faces, oplevede vi et utrolig effektivt og flot resultat. Der var ingen fejl og spotte og frustrummet skar rigtig pænt på afstanden. Den anden løsning blev dog senere implementeret, da der som sagt teoretisk vil være fejl samt vi fik oplyst fysikken senere skal benytte Quad-Træet til mere effektiv kollektion. Her blev hver face der var på grænsen imellem to eller flere Quads splittet op og fordelt ud imellem de forskellige Quads. I starten gav dette et voldsomt problem ved bygningen af træet, da vores count i QuadNode var sat til 100. Dette var simpelthen for dybt at gå ned i træet og antallet af faces steg eksplosivt. Vi erfarede en stigning i ram forbruget på op til 1 GB før end vi manuelt lukkede programmet igen. Ved at efterfølgende ændre denne værdi til 200 blev resultatet fint igen. Dog er effektiviteten ikke så god som før og beskæringen i distancen er ikke helt så pæn.

Den efterfølgende performance af brugen af et Quad-Træ var overvejden. Antallet af faces der blev tilføjet til systemet dræbte den effekt man fik ud af det før og hvis man står et sted i banen hvor at man kan se ca. det hele(altså med en høj distance), så er performance lavere end før.

Uge 3: Shaders og Transformation nodes

Parallax shaderen

Parallax-shaderen faktisk den shader der tog kortest tid at skrive.
Vi har ikke så mange kommentarer til den, vi brugte bare approksimations-metoden.

Oily shaderen

Denne shader gav os store hovedpiner da vi ikke kunne få det til at se rigtigt ud.
Først og fremmest fandt vi ud af at man ikke kunne loade en 1D texture så vi måtte loade ColorRamp.tga som en 2D texture og så læse fra den via 2D koordinater.

Derefter kunne vi ikke få oliefarverne til at få den "thin-film" effekt som vi ønskede: farverne gentog sig mange gange og så ikke realistisk ud. Vi fandt fejlen (forkert udregning).

Den sidste men sværeste fejl var da vi ville have Cetatta'ens egen texture neden under Oily-effekten. Ingen metoder så ud til at virke ordentligt (evigt roterende textures eller textures der sad statisk fast uanset hvor kameraet pegede hen).
Fejlen lå dog ikke i pixel shaderen, men i vertex shareden.

I pixel shaderen indlæser vi texture farver med koden:

color = texture2D(diffuseTex, gl_TexCoord[0].xy);

Grunden til at det ikke virkede helt var at vi manglede at definere gl_TexCoord[0].
Det rettede vi ved at tilføje linien:

gl_TexCoord[0] = gl_MultiTexCoord0;

i vores vertex shader.

Spørgsmål 3

Hvis man ville udvide med support for DirectX skal man udvide Renderer
interfacet kraftigt eller man skal lave to af alt ting. Fra dennes uges
opgaver
ville man skulle have to visitTransformationNode en som bruger
glPush/PopMatrix
og en der gør tilsvarende med DirectX API'en. visitGeometryNode bruger også
nogle kald direkte til OpenGL(glVertex3f, glTexCoord2f osv).

Det ville nok ikke være en lille opdatering at udvide med DirectX, men heller
ikke umuligt. Det hele er dog nemmere hvis man antager det altid er OpenGL, så
slipper man også for at have HLSL udgaver af sine shaders f.eks.

Desuden kører OpenGL fint på alle platforme, DirectX kører kun på Windows.