zondag 31 mei 2009

Schrijven

Ondertussen is mijn volledige implementatie klaar en zijn de resultaten binnen. Op dit moment ben ik volop bezig met het schrijven van mijn thesistekst. Op de inleiding en conclusie na is de eerste draft zo goed als klaar. Hopelijk kan ik morgen mijn eerste draft naar enkele chinese vrijwilligers sturen die alles grondig zullen nalezen.

donderdag 7 mei 2009

Motion Decomposition Part 4

Ondertussen staan we op ongeveer een maand van de deadline. Dat betekent dat ik ondertussen al bezig ben met het schrijven en het verzamelen van resultaten. De resultaten van de motion decomposition techniek zijn er ook al maar deze lijken wat tegen te vallen. Het blijkt dat deze techniek een pak trager is dan alle andere bestudeerde technieken.

De volgende tabel geeft de framerates voor onze 9 testanimaties:

Animatie FPS
Cally1 5.24
Cally2 4.87
Cally3 3.33
Skeleton1 11.89
Skeleton2 7.38
Skeleton3 12.98
Paladin1 1.97
Paladin2 2.77
Paladin3 3.16


In vergelijking met de andere technieken is dit een pak trager. De reden hiervoor is het hoog aantal bounding box en driehoek testen zoals te zien in de volgende tabel (#BBox = aantal bbox testen, #TLBBox = aantal bbox testen in de top level tree, #LLBBox = aantal bbox testen in de locale trees, #Cluster = Aantal local level trees):

Animatie #Clusters #BBox/#Hit #Tri/#Hit #TBBox/#Hit #LBBox/#Hit RenderTime TopTime LocalTime
Cally1 33 166 85 38 127 0.19 0.014 0.16
Cally2 33 135 86 41 129 0.21 0.015 0.17
Cally3 33 161 77 38 122 0.20 0.015 0.17


Ik ben volop aan het uitzoeken of het probleem ligt bij mijn code of dat de techniek fundamenteel slechter is. Hoewel ik vermoed dat het aantal driehoek testen sowieso te hoog ligt.

woensdag 29 april 2009

Motion Decomposition Part 3

Alweer een tijdje geleden sinds mijn laatste bericht. Dat betekent niet dat ik heb stilgezeten. Ondertussen is het me gelukt om de techniek van Günther correct te implementeren. Dit heeft een tijdje langer geduurd dan gepland maar ik heb wat last gehad van bugs.

Tegen de verwachtingen in is deze techniek niet zo snel als rebuilds of refits. Mijn code moet nog een beetje geoptimaliseerd worden maar ik weet niet of het hieraan ligt. Op het eerste zicht lijkt het dat er een pak meer BoundingBox testen worden uitgevoerd bij deze techniek. Dit ga ik nog wat verder onderzoeken.

Voorlopig kunnen we renderen aan volgende framerates:
  • Cally Animaties (3342 driehoeken, 37 botten): 7 fps
  • Paladin Animaties (3422 driehoeken, 54 botten): 3 - 5 fps
  • Skeleton Animaties (4604 driehoeken, 23 botten): 7 - 11 fps
Hieruit kunnen we al uit besluiten dat de performantie afhankelijk is van het aantal botten.

woensdag 8 april 2009

Animaties voor Analyse

Om een grondige analyse uit te voeren heb ik verschillende 9 animatiesequenties gemaakt. De sequenties zijn een combinatie van 3 modellen (cally/skeleton/paladin) en 3 bewegingen (wandelen/lopen/freestyle). Hierop kan ik dan de 3 verschillende algoritmes loslaten.


Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic

Image and video hosting by TinyPic


Al deze animaties zijn gemaakt met mijn eigen raytracer met een resolutie van 512 bij 512 pixels. Framerates schommelen tussen de 15 en 25 fps.

maandag 6 april 2009

Packet Ray Tracing

Zoals gezegd een tabel met de benchmark van de packet implementatie. Deze implementatie is nog niet optimaal (nog geen frustum culling) maar omdat het tijd wordt om een analyse te doen moet ik mijn implementatie afronden. Hiermee zal ik het dus moeten doen:



Er is geen optimale pakketgrootte voor elke scene maar de beste lijken 4x4, 8x8 en 16x16. Voor te grote pakketten is er minder coherentie tussen de rays in een pakket en daalt de performantie voor alle scenes. De speedups zijn wel bevredigend en schommelen tussen 2.5 en 4.

Begin Analyse

De kogel is door de kerk, voor mijn thesis zal ik 3 technieken bespreken voor het renderen van animaties:
  1. Rebuild (elk frame herbouwen van de versnellingsstructuur)
  2. Refit (elk frame aanpassen van de versnellingsstructuur)
  3. Fuzzy (1 versnellingsstructuur bouwen voor alle frames)
Met de implementatie van de Fuzzy structuur ben ik nog niet helemaal rond maar de andere zijn al klaar.

Om het allemaal wat sneller te laten gaan heb ik mijn ray tracer omgebouwd naar een packet ray tracer. Dat geeft een significante snelheidswinst, benchmarks zal ik weldra posten.

Om een grondige analyse te doen beschik ik over 3 verschillende modellen:
  1. Cally (37, 3342 driehoeken)
  2. Skeleton (23 botten, 4604 driehoeken)
  3. Paladin (58 botten, 3422 driehoeken)
En voor deze 3 modellen heb ik 3 verschillende animaties gedefinieerd:
  1. Walking (rustig wandelen en wuiven)
  2. Jogging (joggen en een pijl afvuren)
  3. Freestyle (een funky beweging)
Elk met net iets meer "beweging". Met 3 modellen en 3 animaties kunnen we 9 verschillende testcases maken voor de 3 algoritmes.

Om het allemaal wat sneller te laten gaan zal ik de filmpjes maken met een resolutie van 512 x 512 pixels. Om op te warmen zijn er hier al 3:

Cally Walking
Image and video hosting by TinyPic


Paladin Jogging
Image and video hosting by TinyPic


Skeleton Freestyle
Image and video hosting by TinyPic
Alle animaties zijn gerenderd op 512 x 512 pixels met framerates tussen de 15 en 25 frames per seconde.

zondag 29 maart 2009

Motion Decomposition part 2

Dankzij de hulp van Johannes Günther ben ik al een stuk verder met de implementatie van de door hem beschreven techniek. Het gaat niet zo snel als gehoopt maar ik kan natuurlijk niet van hem verwachten dat hij mijn emails onmiddelijk beantwoord.

Het scheiden van de beweging in 2 componenten is ondertussen gelukt en ook de fuzzy boxes kunnen gebouwd worden. Hieronder zie je de restbeweging waarover we de fuzzy boxes bouwen.

Image and video hosting by TinyPic

Om aan elke driehoek een bot te koppelen berekenen we het gemiddelde bot. Dit is niet altijd optimaal zoals te zien is aan de handen. Beter zou zijn om een exhaustieve zoektocht te doen tot alle beweging minimaal is.


Boven zie je de fuzzy boxes van de vertices. Om de fuzzy boxes te bereken nemen we random 1000 samples per vertex.

Het einde van de tunnel (implementatie) komt in zicht!