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.