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!