Implementace skeletální animace

[TeaTime]

Ahoj, implementuji teď skeletální animaci a nějak mi to nejde. Meshe jsou povětšinou nesmyslně zkřivené. Abych to mohl pořádně zdebugovat, tak bych potřeboval vědět na jisto, jak přesně se má spočíst pozice vertexu - tedy jaké transformační matice mám použít a v jakém pořadí je znásobit.

Pro zjednodušení je zatím každý vertex transformovaný jen jednou kostí. Data modelu načítám pomocí assimpu.

Zatím to mám tak, že pozice vertexu se spočte takhle:

gl_Position = projection * view * model * boneOffset * boneCombined * vec4( position, 1.0f );


boneOffset - "Matrix that transforms from mesh space to bone space in bind pose. ", viz aiBone. Chápu to tak, že to je inverzní matice k transformaci z prostoru modelu do prostoru dané kosti.

boneCombined - je vytvořen rekurzivní funkcí, která prochází strom kostí od kořene. spočte se takto:

boneCombined = this->transform * this->scaling * this->rotation * this->translation * parent->boneCombined

this->transform je defaultní transformace kosti oproti rodiči. scaling, rotation a translation jsou transformace kosti podle fáze animace.


Jak by to mělo být správně? Tohle jsem tak nějak splácal podle různých návodů, ale moc se mi to nezdá. Sám bych to udělal trochu jinak, ale tak se mi výsledek zdál ještě horší, tak to zatím mám takhle. Klidně se nebojte podat mi to trochu teoretičtěji, chtěl bych v tom mít jasno, abych to mohl udělat tak, že si tím budu jistý.

Díky,

[TeaTime]

Teď mě napadlo: nemůže se lišit hodnota quaternionu při použití stupňů a radiánů?

Já načtu quaternion rotace keyframu pomocí knihovny assimp a vytvořím glm quaternion za použití hodnot 'w', 'x', 'y' a 'z'. Poté použiji glm funkci, která zkonvertuje quaternion na mat4 a tou znásobím transformační matici.

Takže mě napadlo, že kdyby se rotace quaterniou interpretovala různě ve stupních a různě v radiánech a glm používal jinou jednotku pro úhly než assimp, tak by to byl problém.

Quaterniony nemám teoreticky vůbec zmáknuté, takže bych se chtěl zeptat, jak to tedy je.

Díky.

[perry]

[TeaTime]

Díky moc, aspoň tohle nemusím řešit.

Ale pořád mi to nefunguje, já se z toho asi už poseru. To je prostě normální sviňárna, jinak to není možný. Já prostě nechápu, když udělám v Blenderu jednoduchou skeletální animaci s jedním keyframem, který má jednu rotaci a pak to vyexportuji do formátu .x, tak proč je v něm najednou 21 keyframů a assimp mi tvrdí, že jich je 250. A ještě k tomu jich většina zahrnuje nějaké podivné translace, které jsem tam vůbec nenastavoval.

Assimp předpočítává offset matici pro jednotlivé kosti. Tak proč proboha když jí spočtu znovu sám, tak mi vyjde úplně jiná matice? To prostě nedává smysl. A proč nejsou transformace animace dány relativně k defaultní transformaci kosti už vůbec nechápu.

Buď mi tohle někdo vysvětlí nebo už na to seru.

[TeaTime]

Hmm, tak jsem to tak nějak vyřešil. Hlavní problém byl při kopírování matic z assimpu do glm. Assimp používá row-major řazení, kdežto opengl a glm používá column-major řazení. No pořád to ještě musím trochu vyladit, ale už by to mělo jít.

To řazení matic má tedy být:

gl_Position = projection * view * model * boneCombined * boneOffset * vec4( position, 1.0f );

kde boneCombined se počítá rekurzivně pro kost takhle:

boneCombined = parent->boneCombined * this->translation * this->rotation * this->scaling;

[perry]

Já používám v OpenGL taky row-major Vzhledem k tomu, že si píšu shader sám (žádná fixní pipeline), tak je to celkem jedno pak.
_________________
Perry.cz

[TeaTime]

[VODA]

[TeaTime]

[perry]

Ten parametr transpose tam sice je, ale myslim, že v OpenGL ES nefunguje
Nicméně, ten parametr je stejně k ničemu. Pokud víš, jak je matice orientovaná, tak pak akorát změníš pořadí operací v shaderu a není problém.
_________________
Perry.cz

[TeaTime]