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.

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.

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.

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.

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.

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

Paladin Jogging

Skeleton Freestyle

Alle animaties zijn gerenderd op 512 x 512 pixels met framerates tussen de 15 en 25 frames per seconde.

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.

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!

Planning 2e semester

Aangezien de deadline voor de thesis dichterbij komt wordt het tijd om een planning op te stellen voor mijn werkzaamheden voor de rest van het semester:

Week 12
* Afwerken van de techniek van guenther.

Week 13
* Afwerken van de techniek van guenther.
* Compileren van een lijst met de analyses die ik wil doen.
* Begin analyse van de technieken.

Week 14
* Analyse van de technieken.

Week 15
* Analyse van de technieken
* Survey van niet onderzochte technieken.

Week 16
* Op vakantie dus geen thesis.

Week 17
* Schrijven van de thesis.

Week 18
* Schrijven van de thesis.

Week 19
* Schrijven van de thesis.

Week 20
* Schrijven van de thesis.

Week 21
* blok/buffer

Week 23
* blok/buffer

Week 24
* 1e examenweek

Week 25
* 2e examenweek/deadline thesis (17 juni)

De deadline lijkt nog lang maar tot mijn grote verbazing/schrik is er niet zoveel tijd meer om nog veel werk te verzetten. Nog 4 weken voor de paasvakantie om echt werk te doen en na de paasvakantie zal er intensief moeten geschreven worden. Hiervoor had ik op 6 weken gerekend maar het zal moeten gebeuren in 4 weken aangezien ik graag nog wat zou blokken voor mijn andere vakken.

Motion Decomposition part 1

Nog steeds bezig met het implementeren van de techniek uit de paper van Günther (Die conceptueel wel duidelijk beschreven is maar waar er weinig gezegd wordt over de implementatiekant van de zaak). Ik ben deze week bezig geweest met een poging om de beweging op te delen in 2 componenten:

• Affine motion: "globale beweging" van het karakter waarbij elke mesh wordt beïnvloed door 1 dominant bot.
• Residual motion: beweging onder invloed van de andere botten, deze beweging is het meest uitgesproken rond de gewrichten waar de "huid" sterk wordt beïnvloed door verschillende botten.

De som van deze 2 componenten is dan de originele beweging. Helaas is dit nog niet helemaal zonder bugs :( Een paar beeldjes om het duidelijk te maken.

Boven zie je de affine motion. Elke mesh wordt beïnvloed door 1 bot. Vooral aan de gewrichten zie je gaten in de mesh. Dit komt omdat rond de gewrichten de meshes worden beïnvloed door meerdere botten terwijl er hier maar invloed is van 1 bot.

Hier zie je de restbeweging. Hier heb je alleen de invloed van de andere botten. Zoals je ziet is het plaatje niet helemaal correct. Sommige delen van de mesh maken een veel te grote swing!

Het probleem zit bij de berekening van de bot/mesh relatie. We kennen een mesh toe aan een bot als de meerderheid van zijn punten het meest wordt beïnvloed door dat bot. Sommige punten worden echter veel meer beïnvloed door een ander bot. Dus deze punten waren beter toegekend aan een ander bot. Dit zijn de punten die worden "meegetrokken" met een ander bot in de mesh.

Een bewijs voor deze redenering wordt hierboven getoond. Hier hebben we punten van de mesh die sterk worden beïnvloed door een ander bot niet mee getransformeerd. Dan zie je een beeld dat meer lijkt op wat we eigenlijk willen bekomen.

De oplossing is volgens mij om in plaats van voor elke mesh een dominant bot te berekenen een dominant bot te berekenen voor elk punt van de mesh. Dus een veel fijnere methode.

Dat wil niet zeggen dat moesten we de methode toepassen op de "foute" restbeweging we een fout beeld zouden renderen. De fuzzy boxes gaan wel heel inefficiënt zijn voor de punten met grote uitwijking. Hoewel het interessant is om te onderzoeken of dit heel veel gaat verschillen in de globale framerate. Dus de vraag is: hoe groot is de invloed van foute bot/mesh toekenningen op de methode?

Hier volgt zeker nog een part 2!

Status Update

Weeral maandag dus meeting met Ares. Een beetje gediscussieerd over mijn "transformatieproblemen" met de Cal3d library en enkele nuttige tips hierover gehad. Verder bezig geweest over het verder verloop van het semester.

De deadline is 17 juni en ik moet 6 weken voorzien om mijn thesis te schrijven. Dit betekent dat ik nog maar tot eind april heb om met de echte inhoud van mijn thesis bezig te zijn. Nog maar een kleine 2 maanden dus! Daarom wordt het tijd om:

• Te beslissen welke technieken ik nog wil onderzoeken en hierin een definitieve keuze te maken.
• Een inhoudsopgave schrijven om een idee te krijgen van de structuur van de tekst.
• Beslissen welke analyses ik wil doen, hiervoor moet ik volgens Ares ook enkele weken voorzien. Het is belangrijker om een grondige analyse te hebben dan een implementatie van verschillende technieken.
• Een planning maken voor de rest van het semester!

Er moet ook nog een paper geschreven worden maar dat kan ik ook doen tijdens het schrijven van mijn thesis.

Interfacen met Cal3d

Door de jobfairs, werkjes en andere afleidingen is mijn thesis wat blijven liggen. Vanaf dit weekend ga ik daar terug verandering inbrengen en weer intensief aan mijn thesis werken! Ik heb niet helemaal stilgezeten dus hier volgt een kleine update.

Ondertussen ben ik nog altijd bezig met het implementeren van de techniek uit de paper van Günther. Voor de karakteranimaties gebruik ik de open-source Cal3d library. Omdat ik Cal3d wil gescheiden houden van mijn eigen code ben ik aan een "interface" aan het werken tussen de ray tracer en Cal3d.

Het is al mogelijk om skeletinformatie en boundingbox informatie uit Cal3d te halen en hier enkele coole animaties mee te renderen. Met de transformaties zit ik nog wat in knoop, hier vrees ik dat ik eens een goed boek zal moeten zoeken over character animation.

De deadline voor de thesis is 17 juni, dat lijkt nog heel ver, maar Ares heeft me aangeraden een planning te maken en eens na te denken over een inhoudsopgave voor mijn thesis. Dus daar zal ik me ook mee bezig houden dit weekend.

Begin 2e semester

Het begin van een nieuw semester dus tijd om er terug in te vliegen. Helaas ben ik tijdens de blok wat lui geweest en heb ik niks gepresteerd voor mijn thesis. Tijd voor een inhaalbeweging dus.

Ik ben begonnen aan het implementeren van een 3e techniek voor het ray tracen van animaties. Deze wordt beschreven in de paper van Günther en is speciaal bedacht voor skinned animations (animaties met een skelet). Op de voorstelling van mijn tussentijdse resultaten heb ik gezegd dat ik de implementatie kon fixen op 6u. Helaas was dat een grove onderschatting van het werk :( Interfacen met Cal3d valt zwaar tegen en daar bovenop is ondertussen de homepage van Cal3d verdwenen van het internet. Gelukkig zit sommige documentatie ook mee in de tarball die je kan downloaden van gna.org.

In mijn huidige implementatie kan ik al bepalen welke meshes worden beïnvloed door wel botten. Daaruit bereken ik voor elke mesh een dominant bot, dit is het bot met de grootste invloed op de mesh. In het volgend filmpje zie je de meshes ingekleurd per bot, meshes met gelijke kleur horen bij hetzelfde bot.