Angoli di Eulero vs. Quaternioni: problemi causati dalla tensione tra memoria interna e presentazione all'utente?

Question

I quaternioni sono probabilmente una scelta appropriata per rappresentare le rotazioni degli oggetti internamente. Sono semplici ed efficienti da interpolare e rappresentano un singolo orientamento in modo inequivocabile.

Tuttavia, presentare quaternioni nell'interfaccia utente è generalmente inappropriato: gli angoli di Eulero sono generalmente molto più familiari agli utenti e i loro valori sono un po 'più intuitivi e prevedibili.

Gli angoli di Eulero soffrono di essere complicati a livello di codice - richiedono che sia memorizzato un ordine di rotazione e comporre un orientamento pratico (sia esso matrice o quaternione) usando questo ordine e gli angoli associati è a dir poco ingombrante.

Le interpolazioni affidabili vengono eseguite nel modo più conveniente usando la rappresentazione quaternione - quindi questo significa che dobbiamo convertire costantemente tra una rappresentazione di Eulero e una rappresentazione di quaternione? È possibile in termini di prestazioni?

Possiamo memorizzare gli orientamenti come quaternioni e convertirli solo per essere visualizzati all'utente? Questo potrebbe non essere possibile perché per ogni orientamento dato esiste esattamente una rappresentazione quaternione ma molte rappresentazioni di Eulero. Come 'scegliamo' la rappresentazione di Eulero che corrisponde a quella che inizialmente definiva quell'orientamento? Sembra un compito impossibile: abbiamo effettivamente perso informazioni durante la conversione in quaternione.

Potremmo memorizzare come angoli di Eulero e poi convertirci in quaternioni secondo necessità? Questo probabilmente non è scalabile: la conversione da un angolo di Eulero a un quaternione, l'interpolazione e quindi la conversione di nuovo sarà probabilmente un codice relativamente costoso.

Potremmo semplicemente archiviare entrambe le rappresentazioni e utilizzare la più appropriata per una determinata situazione? Un costo elevato in termini di memoria (immagina curve di animazione per uno scheletro con circa sessanta ossa) e mantenere sincronizzati questi valori potrebbe essere costoso, o almeno ingombrante.

Qualcuno ha visto, usato o trovato una soluzione intelligente a questo problema? Sicuramente le tre opzioni sopra non sono solo quelle? Esistono altri domini problematici simili a questo che è stato risolto ?

Answer 1

Sono un ingegnere aerospaziale; Ho usato i quaternioni per il controllo dell'atteggiamento dei veicoli spaziali e la navigazione per tre decenni. Ecco alcuni pensieri sulla tua situazione:

1. Eseguire qualsiasi tipo di processo che cambi l'orientamento con gli angoli di Eulero è quasi impossibile. Gli angoli di Eulero soffrono di singolarità - gli angoli cambieranno istantaneamente fino a 180 gradi mentre altri angoli attraversano la singolarità; Gli angoli di Eulero sono praticamente impossibili da usare per le rotazioni sequenziali. I quaternioni non soffrono di nessuno di questi problemi
2. Esistono 12 diverse possibili sequenze di rotazione dell'angolo di Eulero: XYZ, XYX, XZY, ecc. Non esiste nessuno "più semplice". o " giusto " set di angoli di Eulero. Per derivare una serie di angoli di Eulero, devi sapere quale sequenza di rotazione stai usando e attenersi ad essa.
3. Ti suggerisco di eseguire tutte le operazioni di memorizzazione e rotazione con i quaternioni e di convertire un quaternione in angoli di Eulero quando è richiesto l'output. Quando lo fai, devi definire quale sequenza di rotazione di Eulero stai usando.

Ho algoritmi per tutte queste operazioni e molte altre: quaternioni da / verso gli angoli di Eulero di qualsiasi sequenza di rotazione da / verso matrici di rotazione (matrici di direzione del coseno), posizione di corrispondenza dell'interpolazione di quaternioni, frequenza, ecc. ai punti finali o intermedi, dinamica del corpo rigida e flessibile e cinematica mediante quaternioni.

Vi prego di contattarmi se posso essere di aiuto a nhughes1ster@gmail.com

Answer 2

Sono un fan dei quaternioni. Per farli funzionare, potresti riconsiderare la tua presentazione all'utente? Invece di presentare la rotazione all'utente come una serie di angoli di Eulero in forma di testo, potresti invece scegliere un semplice oggetto 3D e applicare la rotazione quaternione all'oggetto per visualizzare visivamente la rotazione in vigore.

Answer 3

Perché non usare i Quaternioni nel codice e convertire la Q in angeli quando necessario per la visualizzazione?

Answer 4

Puoi rappresentare la rotazione come asse + angolo di rotazione, che è essenzialmente uguale al quaternione (fino a un segno)

Answer 5

Non penso che abbia senso usare gli angoli di Eulero internamente: vorrai usare i quaternioni per tutti i tuoi calcoli e di solito non potrai permetterti le conversioni che avvengono ovunque. Per quanto riguarda la sua conversione in angoli di Eulero per l'interfaccia utente - sarebbe così male se l'utente ottenga solo un angolo equivalente all'input originale ma è rappresentato in modo diverso? Se esegui la conversione nel modo giusto, dovresti finire con il "più semplice" Angoli di Eulero per ogni dato quaternione.

Answer 6

Di quante conversioni stiamo parlando. Sembra che tu stia pagando circa due operazioni trascendentali per conversione, che su hardware moderno è disponibile nell'ordine di 100 milioni al secondo. Conserverei entrambi, Quaternions per precisione ed estetica e rotazioni di eulero per preservare le informazioni dell'utente. Forse aggiungi un flag per indicare quale è preferito per un dato oggetto. Inoltre, devi eseguire la conversione una sola volta per membro ruotato. Dopo aver calcolato una matrice di trasformazione, la sua moltiplicazione si aggiunge fino a quando non si esauriscono i vertici.