アカウント名:
パスワード:
いろいろな解説を読んでも今一つきちんと腹落ちしてこないんだけど、改めてこれで勉強しなおそう。＃ゲームやCGだけじゃなくて、ロボットの姿勢制御でもやろうかという向きにもきっと参考になるはず。
四元数ってなに?→ジンバルロックの回避ができる→ジンバルロックってなに?→ggrks
豚の数じゃないのか
三元豚?
三元豚にさらにもう一種かけ合わせた四元豚ってのもあるんですよ
白・發・中・
# あと一つなんだっけ。
花、というより「萬子・筒子・索子 # あと一つなんだっけ。」と持っていく方が正しい。
「萬子・筒子・索子」の字面を見ると、今流行りの「NKODICE（んこダイス）」と何か共通点があるような、ないような。
まあ別に、三次元空間での座標変換は虚数使わなくたって出来るけど、虚数(四元数)使うと座標のx,y,zをまとめて一つの式に放り込んで扱えるので「エレガント」(数学者的にはこれがとても大事らしい)だよと言う話だ。
4元数は「向き」しか表現できないので、「3次元空間での座標変換」なんて大きな観点だと、エレガントかどうかは微妙。
「3次元空間での座標変換」では、アフィン変換行列ってのが使われますが、これは4x4の行列で、位置(移動)・向き(回転)・大きさ(拡大縮小)を統合的に取り扱うことができ、さらには「行列の積で、変換をまとめることができる」というのがすごくエレガント。
ちょっと前にストーリーになった「GPU」は、従来のビデオカードに対して、「T&L」(=Transform and Lighting)がハードウェアでできる、というのが売りでしたが、この「T」がアフィン変換機能。「変換行列」と「頂点データ」を渡せば、ハードウェアで座標変換してくれて指定の位置向き大きさで描画される。
で、従来は、向きの表現方法としては「オイラー角」(いわゆるロール、ピッチ、ヨー表現)がよく使われていたんだけど、これはアフィン変換と相性がいいし、静的な状態表現としては問題ありませんが、「アニメーションさせる」といった時間変化に対応しようとすると、補間が汚いという欠点がある。オイラー角表現は特定の軸に依存しているため、相対的な変化は同じでも、絶対的な軸との関係で挙動が変わるし、ジンバルロックとか、特定の向きで自由度が減ってしまって補間できなくなる場面も。
そこで出てきたのが4元数で、「回転」の表現しかできませんが、「向きの補間」が非常にエレガントな式で表現できる。
ですが、アフィン変換では p' = A p という単純な変換行列Aと座標ベクトルpの積で変換計算できるのたいして、4元数による回転変換式は、p' = q p q* という、座標の前後を4元数qとその共役q*で挟む形の式なので、4元数による回転は、そのままでは、アフィン変換による移動や拡縮と統合できません。GPUまかせの描画もできない。
でも、アフィン変換は懐が広い(どんな回転もアフィン変換で表現できる)ので、4元数による回転変換もアフィン変換行列に変換可能。なので、・「内部的な向き表現」は4元数で管理して、4元数で補間などの処理を行い、・「最終的な座標変換」の段階では4元数をアフィン変換行列にしてから、移動や拡縮と統合するって使い方が普通ですね。
3次元空間の計算を行列でやるってのは自分でやってたから知ってるけど例に出てないだけで行列の計算も「何のために勉強するの？」って言われる代物だろう。
数学的にエレガントな状態はプログラムでの実装においてもより簡素(かつ、おそらくは高速)になるので、それはとても重要なことなのでは？
計算量は変わらんよ。
本質的な計算量は変わらなくても、無駄なステップが減って、コンピュータ上の実行命令数は減ったりするような気がします。
なんで「気がする」だけでそう引っ張るのかｗ記述がシンプルになるというのと、計算量は別だ。コンパイラ通した後の処理量は変わらん。
コンパイラが本当にかしこければそうだけどそれは現実的には無理のある仮定じゃないかなー
「十分まともな記述」と「さらにエレガントな記述」だと差はなくとも変な（すなわちエレガントでもない）記述をすることで無駄な計算量を増やす余地はあるもんな！（なんか悲しくなってきた
俺も利用はしてるがよくは解ってない
四元豚は時々食べてる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
四元数 (スコア:1)
いろいろな解説を読んでも今一つきちんと腹落ちしてこないんだけど、改めてこれで勉強しなおそう。
＃ゲームやCGだけじゃなくて、ロボットの姿勢制御でもやろうかという向きにもきっと参考になるはず。
Re: (スコア:0)
四元数ってなに?
→ジンバルロックの回避ができる
→ジンバルロックってなに?
→ggrks
Re: (スコア:0)
豚の数じゃないのか
Re: (スコア:0)
三元豚?
Re: (スコア:0)
三元豚にさらにもう一種かけ合わせた四元豚ってのもあるんですよ
Re: (スコア:0)
白・發・中・
# あと一つなんだっけ。
Re: (スコア:0)
花、というより「萬子・筒子・索子 # あと一つなんだっけ。」と持っていく方が正しい。
Re: (スコア:0)
花、というより「萬子・筒子・索子 # あと一つなんだっけ。」と持っていく方が正しい。
「萬子・筒子・索子」の字面を見ると、今流行りの「NKODICE（んこダイス）」と何か共通点があるような、ないような。
Re: (スコア:0)
まあ別に、三次元空間での座標変換は虚数使わなくたって出来るけど、虚数(四元数)使うと座標のx,y,zをまとめて
一つの式に放り込んで扱えるので「エレガント」(数学者的にはこれがとても大事らしい)だよと言う話だ。
Re:四元数 (スコア:3, 興味深い)
4元数は「向き」しか表現できないので、「3次元空間での座標変換」なんて大きな観点だと、エレガントかどうかは微妙。
「3次元空間での座標変換」では、アフィン変換行列ってのが使われますが、これは
4x4の行列で、位置(移動)・向き(回転)・大きさ(拡大縮小)を統合的に取り扱うことができ、
さらには「行列の積で、変換をまとめることができる」というのがすごくエレガント。
ちょっと前にストーリーになった「GPU」は、従来のビデオカードに対して、
「T&L」(=Transform and Lighting)がハードウェアでできる、というのが売りでしたが、
この「T」がアフィン変換機能。
「変換行列」と「頂点データ」を渡せば、ハードウェアで座標変換してくれて指定の位置向き大きさで描画される。
で、従来は、向きの表現方法としては「オイラー角」(いわゆるロール、ピッチ、ヨー表現)がよく使われていたんだけど、
これはアフィン変換と相性がいいし、静的な状態表現としては問題ありませんが、
「アニメーションさせる」といった時間変化に対応しようとすると、補間が汚いという欠点がある。
オイラー角表現は特定の軸に依存しているため、相対的な変化は同じでも、絶対的な軸との関係で挙動が変わるし、
ジンバルロックとか、特定の向きで自由度が減ってしまって補間できなくなる場面も。
そこで出てきたのが4元数で、「回転」の表現しかできませんが、
「向きの補間」が非常にエレガントな式で表現できる。
ですが、アフィン変換では p' = A p という単純な変換行列Aと座標ベクトルpの積で変換計算できるのたいして、
4元数による回転変換式は、p' = q p q* という、座標の前後を4元数qとその共役q*で挟む形の式なので、
4元数による回転は、そのままでは、アフィン変換による移動や拡縮と統合できません。GPUまかせの描画もできない。
でも、アフィン変換は懐が広い(どんな回転もアフィン変換で表現できる)ので、4元数による回転変換もアフィン変換行列に変換可能。
なので、
・「内部的な向き表現」は4元数で管理して、4元数で補間などの処理を行い、
・「最終的な座標変換」の段階では4元数をアフィン変換行列にしてから、移動や拡縮と統合する
って使い方が普通ですね。
Re: (スコア:0)
3次元空間の計算を行列でやるってのは自分でやってたから知ってるけど
例に出てないだけで行列の計算も「何のために勉強するの？」って言われる代物だろう。
Re: (スコア:0)
数学的にエレガントな状態はプログラムでの実装においてもより簡素(かつ、おそらくは高速)になるので、それはとても重要なことなのでは？
Re: (スコア:0)
計算量は変わらんよ。
Re: (スコア:0)
本質的な計算量は変わらなくても、
無駄なステップが減って、コンピュータ上の実行命令数は減ったりするような気がします。
Re: (スコア:0)
なんで「気がする」だけでそう引っ張るのかｗ
記述がシンプルになるというのと、計算量は別だ。
コンパイラ通した後の処理量は変わらん。
Re: (スコア:0)
コンパイラが本当にかしこければそうだけどそれは現実的には無理のある仮定じゃないかなー
Re: (スコア:0)
「十分まともな記述」と「さらにエレガントな記述」だと差はなくとも
変な（すなわちエレガントでもない）記述をすることで無駄な計算量を増やす余地はあるもんな！（なんか悲しくなってきた
Re: (スコア:0)
俺も利用はしてるがよくは解ってない
Re: (スコア:0)
四元豚は時々食べてる