rotatie-ellende!

[Verwijderd]

niet echt een programmeerprobleem, maar dit forum kwam volgens mij het dichst in de buurt, iig zullen hier mensen met de juiste kennis rondwandelen (modjes, verplaats gerust als jullie em beter in een ander forum vinden passen)

ik heb een 3D wereld waarbij +Z = up.

ik heb een poppetje, dat standaard face forward naar -Y gericht staat, zijn linkerkant is dan gericht naar +X.

ik heb 3 variabelen met radialen waarmee het arme ventje geroteerd gaat worden: een voor de hoek die elke as moet worden geroteerd.

C++:

radian rotX, rotY, rotZ;

stel nu dat rotY = 0.25 * pi.

gevolg is dat het mannetje 45 graden naar rechts helt. (een beetje een onnatuurlijke houding, maar laten we stellen dattie net wat teveel heeft gedronken en naar rechts aan het omvallen is )

so far so good, maar n00by als ik ben heb ik er ooit voor gekozen om een nare volgorde van rotatie te bedenken:

C++:

Quaternion quat_rotX, quat_rotY, quat_rotZ;
quat_rotX.SetAngleAxis(rotX, Vector3(1, 0, 0));
quat_rotY.SetAngleAxis(rotY, Vector3(0, 1, 0));
quat_rotZ.SetAngleAxis(rotZ, Vector3(0, 0, 1));
ventje->SetRotation(rotX * rotY * rotZ);

het quaternion gebeuren mag je vergeten, maar het komt er op neer:

1. eerst wordt het ventje om de X-as gedraaid: hij helt naar voren of naar achter
2. dan wordt het resultaat om de Y-as gedraaid:
   • als de X rotatie 0 was betekent dit een helling naar links/rechts, maar
   • als de X rotatie bijvoorbeeld 1/2 * pi was (ventje achterover 'liggend') betekent het een draaing over de absolute Z-as, immers, de relatieve Y-as was al geroteerd door de X rotatie.
3. daarna hetzelfde verhaal om de Z-as.

terug naar het voorbeeld: we beginnen opnieuw, en stel nu weer dat rotY = 0.25 * pi. het mannetje helt weer naar rechts. echter, we nemen voor rotZ deze keer pi.

gevolg is dat het mannetje nu andersom, richting +Y kijkt, maar hij helt nu (relatief tov. z'n eigen face-forward) niet meer naar rechts, maar naar links!


toegepast in mijn spel was dit eerder niet zo'n probleem: de Z rotatie deed ik via een hogergelegen 'node', waardoor eerst om die Z as geroteerd werd, en pas daarna over de X Y Z'en van mijn ventje-animatie. de animaties bouw ik in een zelfgemaakt animatieprogramma, waardoor de rare volgorde van roteren me niet zo opviel: ik zorgde er gewoon, op zicht, voor dat de animaties er natuurlijk uitzien, ongeacht welke vreemde X Y Z hoeken hier voor nodig waren. in die animaties worden overigens dus de 3 radialen - voor elke as 1 - opgeslagen.

nu ik m'n spel aan het uitbreiden ben wordt dit echter een probleem: vanwege $lang_verhaal wil ik de Z rotaties nu in dezelfde 'node', en om rare X/Y rotatie effecten te voorkomen moet de volgorde dus andersom (tenminste, dat leek me het meest logisch): eerst Z, dan Y, dan X. [zie *edit onderaan!]

probleem is nu dat ik al een huge database aan animaties heb gemaakt, die bij zo'n verandering allemaal zwaar broken gaan zijn nu wil ik die animaties dus gaan omzetten, maar ik weet niet precies hoe ik de nieuwe hoeken bereken.

mijn vraag samengevat dus:

ik heb 3 radialen, rotX, rotY, rotZ, die ik met volgorde X Y Z toepas.
ik wil deze omzetten naar 3 nieuwe radialen die hetzelfde resultaat moeten opleveren als ik ze met volgorde Z Y X toepas.

hoe bereken ik deze 3 radialen?


ik hoop dat het zo een beetje duidelijk is, t blijft lastig om zoiets goed uit te leggen en zeker ook om het te begrijpen als je dit als buitenstaander leest. nu weet ik dat er hier de nodige mensen rondhangen die een stuk slimmer zijn dan ik, dus eej, ik dacht ik vraag het gewoon

sowieso bedankt voor het lezen, en hopelijk voor het antwoord!


** edit: eigenlijk zou het veel logischer zijn als die rotaties elk gewoon onafhankelijk van elkaar werden toegepast (dus dat de relatieve Y as niet door de X rotatie wordt aangepast etc) .. mits ik ga snappen hoe ik dat ga fixen qua quaternions, maar dat moet te doen zijn.

dan wordt de vraag: hoe zet ik mijn radialen om naar 3 nieuwe radialen die op deze onafhankelijke manier toegepast hetzelfde resultaat opleveren?


_{waar koop ik meer inzicht in dit soort ogenschijnlijk simpele dingen die ik maar lastig begrijp}

[ Voor 7% gewijzigd door Verwijderd op 02-04-2010 23:51 ]

[Verwijderd]

*update: heb mn systeem nu aangepast zodat de rotatie-assen niet veranderen door voorgaande rotaties.
op zich zien de animaties er nog steeds aardig uit, alleen als bepaalde lichaamsdelen over 2 assen roteren kloppen ze nu niet meer, zoals verwacht.

voor de liefhebber, het nieuwe quaternion stukje:

C++:

Quaternion quat_rotX, quat_rotY, quat_rotZ;
quat_rotX.SetAngleAxis(rotX, Vector3(1, 0, 0));
quat_rotY.SetAngleAxis(rotY, Vector3(0, 1, 0));
quat_rotZ.SetAngleAxis(rotZ, Vector3(0, 0, 1)); 

Quaternion totalRot(QUATERNION_IDENTITY);
totalRot = quat_rotX * totalRot;
totalRot = quat_rotY * totalRot;
totalRot = quat_rotZ * totalRot;
ventje->SetRotation(totalRot, false);

nu nog de radialen converten dus

[ Voor 16% gewijzigd door Verwijderd op 03-04-2010 01:16 ]

[dusty]

Waar heb jij exact je rotatie punt van je popetje gezet?

[Verwijderd]

dat lijkt me niet relevant voor dit probleem, maar ergens in het midden.
de rotatiepunten van de ledematen zitten gewoon bij hun gewrichten (dit hele probleem geldt ook voor de ledematen)

[ Voor 14% gewijzigd door Verwijderd op 03-04-2010 02:59 ]

[dusty]

Kleine duw in een betere richting:

"Ergens in het midden" is je eerste probleem, je zal precies moeten weten waar je roteert en ook wilt roteren. Bijvoorbeeld als ik omver val blijft maar een punt op zijn plaats en dat is toch echt niet ergens in 'het midden' (tenzij ik dus op ijs sta)

Tweede punt wat ik zie is dat je inzicht in drie dimensionaal onvoldoende is op het moment, in plaats van een poppetje, ga eerst eens met een kubus en dan een pyramide spelen en roteren. Ik neem aan dat je in een drie dimensionaal wereld iets wilt neerzetten, dat betekent dus dat je uiteindelijk twee rotaties nodig hebt: Een X-Rotatie en een Y-Rotatie. En alleen een Z-verandering hebt zodra je de rotatie plaats van 'je object' veranderd. Doo rgebruik te maken van een pyramide zal je zien dat je met slechts die 2 rotaties je de pyramide-top naar elke punt in je wereld kan wijzen.

[engelbertus]

met 2 rotaties kun je wel de top naar alle richtingen laten wijzen, maar dan is wel de twee rotatie slechts in staat om altijd dezelfde dijkant van de piramide schuin te zetten, terwijl je misschien ook wel een aangrenzend vlak wilt schuin zetten.( bijvoorbeeld schuin naar voren)

of je moet eerst de rotatie in het horizontale vlak kiezen, en vervolgens een rotatie opgeven die door het cenrtum van het poppetje loopt, en in een bepaalde richting wijst, anders dan de x of y as


ik snap dus wel wat TS voor ogen had bij zijn systeem waarbij de rotaties voor x,y,z in eerste instantie dus de directe shuinte voorstelde van het poppetje.( zoveel graden naar links of rechts tov zijn kijkrichting, die in eerste instantie een bepaalde kant uit is, en vervolgens zoveel naar voren en zoveel omhoog of omlaag)

dus eigenlijk gewoon de gemeten waarden in de x y z tov het "beginpunt"

nu dat beginpunt is verandert, kun je dat "trucje" niet meer uitvoeren.
je moet vanaf dan steeds de reeds verkregen x, y, z aftrekken van de gewenste x,y,z


dus een rondje draaien is dan steeds de rotatie met een bepaalde waarde verhogen,zodat de absolute rotatie van het poppetje wordt opgegeven, en ipv elke keer dezelfde waarde opgeven om een elke keer dezelfde waarde verder te draaien.

ik denk dus dat je wel de 3 rotaties nodig gaat hebben.

anders kan je ook zeggen.. probeer je inzicht te vergroten door met een bal te beginnen. je zult zien dat bij elke rotatie de bal in elke richting kunt laten wijzen ( omdat je het verschil niet kunt zien lijkt het te kloppen)

ik neem aan dat hetzelfde probleem ontstaat voor de lichaamsdelen. dat probleem is toch net zo groot als de plaatsing van het poppetje.. dat is bij TS dan nu toch net zon probleem als dat waar het nu om gaat?
je kunt anders nog net doen alsof het poppetje een lichaamsdeel is dat op een bol staat, en je elke keer als laatste die bol in de ruimte plaatst. ( de "virtuele bol" kan een stip midden tussen de voeten zijn, maar ook bijvoorbeeld het zwaartepunt / paar cm achter de "navel" van het poppetje.

[dusty]

uiteindelijk heb je wel 3 totaties nodig, Immers wil je ook rond je eigen as draaien. Maar om je weg te vinden hoe je 3D berekeningen maakt en uitvoert is het handiger om eerst bij de eerste twee te blijven, zodra men die twee onder de knie heeft is het makkelijker om de derde rotatie erbij te nemen.

En je moet de rotatie punt niet verwarren met de zwaarte punt! Zodra je physics-regels erbij haalt moet de zwaarte punt recht boven of onder de rotatie punt liggen anders hoort je object dus te gaan roteren om die rotatie punt. (invloeden van andere objecten even daarbuiten gelaten)

[engelbertus]

zwaartepunt / rotatiepunt is maar net hoe het absolute tselsel van het popptje gaat zijn denk ik?

[Zoijar]

Wat je wil kan wel, maar is een beetje een lastig probleem... (matrix decompositie in elementaire rotaties, dat kan je op 24 manieren doen) Wat eigenlijk het probleem is, is hoe je met je animaties omgaat. Een object in een scene graph heeft gewoon een pose, en dat is de combinatie van al die hoeken. Dat sla je op als een quaternion (of matrix) en niet als 3 hoeken. Dan kan je nog steeds je oude animaties gebruiken.

[ Voor 10% gewijzigd door Zoijar op 04-04-2010 19:52 ]

[.oisyn]

dusty schreef op zaterdag 03 april 2010 @ 04:04:
Kleine duw in een betere richting:

"Ergens in het midden" is je eerste probleem, je zal precies moeten weten waar je roteert en ook wilt roteren. Bijvoorbeeld als ik omver val blijft maar een punt op zijn plaats en dat is toch echt niet ergens in 'het midden' (tenzij ik dus op ijs sta)

Zijn probleem is het terugkrijgen van euler angles gegeven een rotatie in een bepaalde representatie (quaternion danwel matrix). Wat rotatiepunt daar in hemelsnaam mee te maken heeft ontgaat me compleet.

@TS: X Y Z wil je met Euler angles in jouw assenstelsel doorgaans ook niet (je noemt het Z Y X maar het is precies andersom, q1*q2 is een transformatie over q2 gevolgd door een transformatie over q1). Je wil een yaw-pitch-roll systeem waarbij je met yaw (rotatie over de Z-as in jouw assenstelsel), pitch (X) en roll (Y) de orientatie van je object kunt bepalen. Dit doe je door eerst de roll transformatie te doen, daarna de pitch en vervolgens gevolgd door de yaw. Oftewel, Y-X-Z.

En er is op het internet wel code te vinden die van een quaternion (of matrix) de yaw, pitch en roll componenten eruit kunt halen.

[Verwijderd]

bedankt voor de reacties mensen


@dusty & engelbertus:

wat ik begrijp is dat je 2 rotaties nodig hebt om elke mogelijke orientatie te bereiken, TENZIJ het rotatiepunt NIET het middelpunt is? (correct me if i'm wrong)

punt is dat het rotatiepunt van de ledematen natuurlijk onmogelijk in het midden kan zitten, dat lijkt me wat onnatuurlijk sowieso is het in mijn editor handiger om alle 3 assen te kunnen gebruiken; anders moet ik wel erg gaan klooien met de X en de Y voor een simpele rotatie over de Z.

overigens zijn physics niet van belang; ik kan naast de rotatie ook de positie (van het ventje, niet van zijn rotatiepunt) instellen in mn animatieprog, dus ik zorg er gewoon manual voor dat het er enigzins realistisch uitziet qua physics.


@zoijar:

je hebt helemaal gelijk, maar ik vind het handiger om de rotaties op te slaan als 3 radialen. zo kan ik namelijk ook heel makkelijk bepaalde zaken uitlezen in het spel zelf: 'hoeveel graden is het hoofd van het poppetje over de Z-as gedraaid?' etcetera.

verder heb je helemaal gelijk dat het een lastig probleem is.. een behulpzame gast op irc (MacGyver op piratpartiet.se, fyi) is me aan het helpen met de formule voor de omzetting. hij heeft duidelijk een stuk meer kaas van matrices ed. gegeten dan ik, en toch vindt ie het ook maar lastig. hoop dat ie slaagt!

mocht het allemaal niet lukken ga ik gewoon de animaties met de hand aanpassen. een fikse klus, maar niet onoverkomelijk, want eigenlijk valt het wel mee met de schade na de omzetting naar het nieuwe systeem; zoals gezegd gaat het alleen mis als bepaalde ledematen/het ventje zelf over meer dan 1 as wordt geroteerd, en dat gebeurt op zich niet eens zo heel vaak.

mocht iemand ook alsnog een poging willen wagen of beter begrijpen wat ik bedoel, kan ik evt nog een filmpje maken van een animatie met zowel het oude als nieuwe systeem, misschien is dat duidelijker dan mn first post..


iig, bedankt voor alle inzichten, en hoewel ik nog steeds niet 100% begrijp wat iedereen bedoeld (zoals het verhaal van jullie over rotaties, rotatiepunten en 2- of 3 rotaties gebruiken) is het me de afgelopen dagen iig een stukje helderder geworden.

[.oisyn]

Verwijderd schreef op zondag 04 april 2010 @ 21:31:
bedankt voor de reacties mensen


@dusty & engelbertus:

wat ik begrijp is dat je 2 rotaties nodig hebt om elke mogelijke orientatie te bereiken, TENZIJ het rotatiepunt NIET het middelpunt is? (correct me if i'm wrong)

Nee daar klopt niets van, en het punt dat dusty naar voren brengt heeft geen zak met je probleem te maken, dus vergeet wat hij gezegd heeft

Heb je mijn vorige post overigens wel gelezen? Als je gewoon googled op [google=quaternion to euler angles] vind je bijvoorbeeld http://www.euclideanspace...aternionToEuler/index.htm

[Verwijderd]

eej oisyn! je post idd gemist

ik dacht dat het onmogelijk was de rotatieradiaal van een quat over de afzonderlijke asjes op te vragen? immers, dat is toch ook afhankelijk van de volgorde van rotaties? *edit: of gaat die code op die link dan uit van die Y-X-Z?

wel erg relaxed iig als het zo kan.. scheelt een hoop gedoe zo eens even proberen!

overigens, ik had nog een filmpje gemaakt voor de duidelijkheid van mijn probleem (al is dat niet echt meer nodig als het zo kan, maar voor de liefhebber): http://www.youtube.com/watch?v=uS3Ylf7BTLo

[ Voor 50% gewijzigd door Verwijderd op 04-04-2010 22:37 ]

[dusty]

Zoals, .oisyn al aangeeft nee, met 2 rotaties lukt dat niet.. je kunt wel een pyramide elke punt laten aanwijzen. Ik kreeg het idee uit je post dat je nogal wat 3D-kennis mist, vandaar dat ik je eerst in de richting wou duwen voor "normale" rotaties, zonder matrix berekeningen, heb je die namelijk onder de knie is het begrijpen van matrix berekeningen een stuk makkelijker te volgen. (In mijn ervaring dan.)

[Verwijderd]

ah ok, ik snap nu wat je bedoeld denk ik, je kunt met die piramide elk punt aanwijzen, maar de 'ronddraaing' van de piramide is dan verder niet instelbaar?

ik heb op zich aardig wat 3d kennis, alleen als het te lastig wordt qua rotatiegrappen dan snapt mijn hoofd het niet meer iig weer flink wat geleerd de afgelopen dagen

[ Voor 36% gewijzigd door Verwijderd op 05-04-2010 17:59 ]

[engelbertus]

daarom zei ik ook dat je ze all drie nodig had.
en zei ik ook dat het anders wel een rare vergelijking werd, piramide met een poppetje. en gaf ik een voorbeeld van de bal.

die doet ook precies wat je wilt als je hem om 1, 2, of 3 assen draait, maar het beeld ziet er dan niet uit zoals je wilt
wat ik begrepp was idd dat je eerst je poppetje vormgeeft door ledematen in een hoek te zetten tov van een uitgangspositie tov het scharnier zeg maar, dat is een simpel iets
en dan vervolgens de hele groep elementen die samen het poppetje vormen ergens in je 3D wereld plaatst op x,y,z en aangeeft hoe het poppethe dan gedraaid is tov van zijn insertionpoint zeg maar. de aanpassingen die je daarin doet zijn steeds tov het lokale poppetje, waardoor draaien over de Z-as het poppetje opeens naar voren leunt. en zo de Z as schuin blijft staan. je wilde eigenlijk het poppetje in het globale assenstelsel laten draaien, dan gebeurt er wat er in het nieuwe systeem gebeurt iig.

doordat je draaing in het eerste geval steeds ook de assen van het poppetje verdraaien, raak je de orientatie zeg maar kwijt en kun je niet meer kijkend naar je beeld zeggen, "oh, nu steeds 1 graad over die as draaien en dan gebeurt dat"


je wilt dus je beeld draaien om de globale assen, maar kunt alleen de draaing tov het lokale assenstelsel van het poppetje besturen.
het is erg lastig om dan te zeggen welke globale lokale veranderingen tot gevolg gaan hebben wat je eigenlijk wilt zien.

in het tweede systeem heb je dat opgelost, maar nu moet je dus je data voor het maken van de oude animaties veranderen idd.
een formule wordt nu wel erg lastig omdat die ook steeds moet kijken wat de "huidige" verdraaiing van de lokale assen is, en dan moet aansturen, en weer iets teruggeven dat de verdraaiing in het globale stelsel (3D wereld) weergeeft

ik heb verder geen programmeer achtegrond of verstand van spelletjes maken, maar een CAD teken achtergrond, waar je zulke probleempjes soms ook tegenkomt als je iets gaat extruderen langs een 3D "pad" een tekenprogramma houdt er gen rekening mee dat jij het logisch vind dat de onderkant onder moet blijven en bijvoorbeeld een bepaalde as horizontaal moet vlijven. neem bijvoorbeeld een 3D spiraal/veer/schroefdraad als pad. je object zal verdraaien over de as van de richting van je spiraal
toen ik dat voor het eerst zag was ik ook onaangenaam verrast, hoewel ik het wel meteen begreep. het pakket dat we gebruikten had daar ook geen oplossing voor,
gelukkig was het niet voor een animatie, dus kon ik toch op een andere manier makkelijk toch de benodigde coordinaten bepalen, na wat hulp van iemand met een programma om die spiralen aan de hand van wat gegevens voor me te tekenen.

[ Voor 53% gewijzigd door engelbertus op 06-04-2010 01:51 ]

[Verwijderd]

begin na wat geklooi en het zien van dit (damn, check die titel mijn daar een potje pwnen ) toch te twijfelen of zoijar's idee van het opslaan als quaternion ipv 3 angles niet slimmer is.

kan daarna op zich via wat .oisyn zegt immers gewoon weer de Z hoek opvragen in mn game ('welke richting kijkt meneer naar?')

@engelbertus (waarom posten jullie steeds terwijl ik iets aan het replyen ben ): het coordinatensysteem van de ledematen is wel weer relatief aan de 'parents', dus dat zou geen probleem moeten zijn.. zo is het onderbeen ook weer relatief tot de stand van het bovenbeen etc.

[ Voor 24% gewijzigd door Verwijderd op 06-04-2010 01:49 ]

[engelbertus]

ok.. dat zei ik. alles is relatief tov de parent, waarom gaat dat wel makkelijk, en het besturen van het poppetje in je 3D wereld niet?
volgens mij moet je dus je poppetje ook relatief maken tov bijvoorbeeld een punt tussen zijn voeten, of zijn zwaartepunt. dat is dan ook het draaipunt van je poppetje. dat punt kun je vervolgens door je 3D wereld bewegen?

misschien zeg ik nu wel hele rare dingen, en zijn daar al lang systemen voor
wat een quatermoin is, of hoe en wat je in die matrices stopt, heb ik geen idee van.

wat ik me wel nog afvraag de ledematen zijn allemaal in slechts 2 richtingen te verdraaien, die de ledematen in alle richtinen kan laten wijzen.

wat dus het evrschil idd is dat je het poppetje ook om zijn eigen as draait... dat is ook je bedoeling, terwijl dat dat eigenlijk bij het poppetje niet uitmaakt? hoe doe je dat dan met het hoofd bijvoorbeeld? of boven lichaam verdraaien tov de heupen?

[.oisyn]

Verwijderd schreef op dinsdag 06 april 2010 @ 01:45:
begin na wat geklooi en het zien van dit (damn, check die titel mijn daar een potje pwnen ) toch te twijfelen of zoijar's idee van het opslaan als quaternion ipv 3 angles niet slimmer is.

In dat artikel praten ze over de properties van een object in de engine zelf, niet van de opgeslagen content. Ik zou ook afraden om euler angles te gebruiken in je hierarchie van transformaties, omdat dat nogal onhandig werkt, en je niet alles met euler angles wilt besturen (een physics engine heeft er bijvoorbeeld niets aan, die werkt typisch met matrices). Alleen hoe de content op disk opgeslagen staat kan op zich prima met euler angles. Scheelt ook kwa hoeveelheid (3 floats, ipv 4 voor een quaternion of 9 voor een matrix)