| Unity3D, VRoid, モーキャプ編集ツール, fbx | おちっこLAB Since 2002 おちゃっこLAB Since 2006 おちゃっこLAB化け猫編バージョン２ Since 2013/12/21 おちゃっこLABメトード２編 Since 2021/09/23 |
Win日記[Windowsプログラミング日記]
前書き
おちゃっこのWindowsプログラミングの日記です。
勉強したこととか、作ったもののスクリーンショットとかのページにします。
新しい記事の方が上に来るように書いていきます。
次の新しい日記のページへ
Maya Indieとbullet physicsでソフトボディにチャレンジ [2020/12/22]
YouTubeを眺めていると
もう１０年位前から
ソフトボディシミュレーションの紹介動画がたくさんあります
いままで剛体ばかりやってきましたが
そろそろかなぁという感じで
ソフトボディにチャレンジしてみました
以下に２つの動画を載せます
2020/12/20
【bullet】ミュー子に物理でひらひらゆらゆら その４【リアルタイム】
それ赤ふんどし？
これは赤いタオルです
（たぶん）
今回はあえてリアルタイムで撮影しました
https://youtu.be/A2M92pRFEGc
2020/12/22
【bullet】ポニーテールと赤タオルのbulletソフトボディ【ソフトボディ】
https://youtu.be/NrRf4gQOx8U
髪の毛の初期状態から
髪の毛が垂れ下がるまでの間（アクション待ち）も
動画に入れてみました
静止画も一枚貼っときます
図１ Maya Bullet Physics 静止画
上の動画の
赤いタオルとポニーテールの動きがソフトボディによる物理シミュレーションです
キャラクターのアクションに合わせて
赤いタオルとポニーテールは自動的に動きが計算されて表示されます
ポニーテールは重量が軽い飾りのように大きく動かしてます
ソフトボディ設定は布形状の方が簡単でした
ポニーテールのときには
ポニーテール内部から破綻したポリゴンが大きく伸び縮みするノイズフレームがたくさん出て大変でした
ノイズを収めるには
ソフトボディー形状が初期状態で重ならないようにしました
一体化してあるソフトボディでも
内部でポリゴン同士が重なっているとノイズフレームが出ました
ポニーテールの初期状態の形状を房ごとが重ならないようにするとうまくいきます
重ならないようにするってどういうこと？
ということで
上の動画では初期状態から動画にしてあります
ソフトボディ
どんどん使っていきましょう！！
DirectX12でリアルタイムレイトレーシングで表示して動かしたい！！！その３[2020/12/10]
リアルタイムレイトレーシングの日記も
その３になりました
今回もたくさん絵を載せていきます
Shade3Dのデータを表示していきます
曲面の分割数はレベル４にしました
どうしてレベル４かというと
サンプルについているモデルデータが１つにつきだいたい５０MBくらいです
５０MBくらいになる分割数がレベル４というわけです
まずは図１、図２，図３にレベル４の表示具合を示します
図１ かげからこっそりと自転車娘の図
図２ ライトも当たって調子のよい自転車娘レベル４
図３ Shade3Dの建物だったのかぁと驚くところ
自転車娘がかげから出てきて目立ったその時
タイムポッドがポールに刺さって注目を集めシュタゲが、、、
違います
モデルデータの調整やボーンを入れる時には
手持ちの２００１年版Shade3Dもよいのですが
リアルタイムでサブすく会員のMayaを使いたいと思っている
Shade3Dの分割データをMayaに持っていくために
Shade3D R5のプラグインとオリジナルアプリでFBXファイルに変換しました
自前変換のFBXをMayaで読み込んだ図を図４と図５に載せます
図４ Shade3D R5からの自前変換FBXをMaya2018で読み込んだところ その１
図５ Shade3D R5からの自前変換FBXをMaya2018で読み込んだところ その２
Mayaにも持っていけることが分かりました
さてじゃあシーンを撮ろうということで
図６と図７
図６ 噴水のある公園のシーン その１
図７ 噴水のある公園のシーン その２
DirectX12のリアルタイムレイトレーシングの材質は
物理マテリアルです
今までとは計算方法や項目が異なります
物理マテリアルなのでガラス用の材質もあります
噴水の水にはガラス特性を割り当てました
噴水が普通の不透明材質の場合には１フレーム当たりの描画時間は４ms弱でした
噴水のような大きなガラス材質があるこにより１フレーム当たりの行が時間は7ms程になりました
噴水のＵＶは計算しましたが
割と偶然こんな感じになりました
（思ってたのとちょっと違うけどなんか面白いからいいや）
同じマテリアルを何回も定義するとマテリアル数が１００個を越えたりします
同じベースカラーのものを１つにまとめて描画しました
偶然ですが
黒い服が噴水マテリアルになってしまいました
（わざとじゃないです）
DirectX12でリアルタイムレイトレーシングで表示して動かしたい！！！その２[2020/12/05]
前回の報告はミニエンジンというサンプルにShade3Dからデータを持ってきて表示した
その際には法線だけではなく接線も自分で用意する形式のh3dファイルを使用した
今回はリアルタイムレイトレーシングデノイズアンビエントオクリュージョンという長い名前のサンプルを使用
データはplyファイル
今度は法線付きのポリゴンデータを用意すれば良い
接線が無い分ポリゴンが細かくないと見栄えがしないように思った
というよりも
かなりのハイポリを余裕で表示できるようだ
次に示すスクリーンショットは
Shade3Dでレベル６の細分化をしたポリゴンデータを
サンプルの車の位置に置いてみた図である
車の代わりに女性と自転車が表示されている
図１ AOオン 正面
図２ AOオフ 右から
図３ AOオフ 正面
図４ AOオフ 左から
最初の頃は
縮退三角の法線がおかしくて
明るい筋になったり黒いしみのようになったりしていたのだが
ついさっきやっとその問題をクリアしたところである
このサンプルは物理マテリアルというところも
最近らしいサンプルである
表面の粗さなどを指定可能
ちなみに
図１から４の人と自転車にはテクスチャは使っていない
実はまだ全然と言って良いほど
このサンプルの中身をみていない
まずは自分で用意したデータを表示できたという段階
人と自転車で８００MBくらいのポリゴンデータであるが
図１で１フレームあたり４ｍｓ、図３で１フレーム当たり３ｍｓ程描画に時間がかかっている
細かいデータを用意しておけばオーケー？！
レイトレーシングなので
小さく表示されるときには自然と計算も少なくなるのだと思う
というわけで
これからサンプルをみて勉強していこうと思う
2020/12/05 20:30頃 技術情報を追記
技術系としてこんな記事じゃあんまりだ？！という気が少ししたので
フィードバックになりそうな部分とか
問題が起きてどう解決したかなども記しておく
こういうチップスって書いても結局自分が後でみるくらいのものなんだけれど
フィードバックと大それたことを言いながらメモしてみる
まずミニサンプル
ミニサンプルでは接線がある分ローポリのわりに綺麗だった気がするが
ポリゴンの裏表の問題が付きまといそれに関連して
どっちが光の向きでどっちが陰の向きでどっちが影の向きかということで大混乱した
結局分かったこととしては
SumOrientationが-0.5PIのときに
ミニエンジンサンプル起動時のカメラの向きとライトの向きが一致した
しかしそのとき影の向きは陰の向きと0.5PIだけずれていた
ライトをいろいろ回転してみたがいつも影の向きは陰の向きと0.5PIだけずれていた
陰と影とでは向きの基準だかsinとcosだかが違うような現象が出ているが
シェーダーをみると陰計算と影計算とで同じシェーダー定数をみていた
陰の向きと影の向きを合わせるために
陰用のライトの向きのシェーダー定数と影用のライトの向きのシェーダー定数を分けることにした
そして陰と影とで２回カメラ計算をしてそれぞれのシェーダー定数に値をセットした
そうしてようやく光と陰と影の向きは合った
次に今回のレイトレーシングデノイズアンビエントオクリュージョンサンプルについて
細かいポリゴンが必要だった
plyファイルを所定の位置に置くと（既存のものと入れ替えて）表示された
plyファイルのフォーマットについて簡単に記す
plyファイルはテキストのヘッダーとバイナリーの内容になっている
ヘッダは次のようである
ply
format binary_little_endian 1.0
element vertex 1127
property float x
property float y
property float z
property float nx
property float ny
property float nz
property float u
property float v
element face 1728
property list uint8 int vertex_indices
end_header
改行は\r\nでも\nでもよかったように思う
ヘッダが上述の場合
end_headerの後に続くデータは
頂点座標のXYZ
法線のXYZ
テクスチャUV座標UV
の頂点データが1127個分がまずある
そしてその次に
三角形ならば
3
index0
index1
index2
3
index0
index1
index2
...
のようにインデックスデータが三角形1728個分続く
ヘッダより下のデータ部には改行は付けないでバイナリーを記述する
3角形を示す3の部分はintではなく符号なし８ビット整数(uint8)である
index0,index1,index2の部分はint(32bit)である
(ミニエンジンのサンプルのインデックスは１６ビットだったが
レイトレーシングデノイズアンビエントオクリュージョンサンプルのインデックスは３２ビット)
バイナリーがビッグエンディアンかリトルエンディアンかについては
ヘッダーに書いてあるが
こちらとしては
リトルエンディアンでしか動作テストはしていないので
ビッグエンディアンで動くかどうかは分からない
まだ更に書いておこう
法線を自分で計算することになるが
細分化したポリゴンの座標間の数値の違いはすごい小さい
よって法線の計算はdoubleでしないとうまくいかなかった
また縮退三角形問題対応も定石である
今回はメッシュの中心座標も求めておいて
縮退三角形がみつかった場合に
その法線はメッシュの中心から頂点座標へのベクトルとした
このような感じで今回の綺麗な写真になった
今思っているのは
レベル６分割は細かすぎたかもしれないということ
レベル６分割の人と自転車を加えたときのアプリの消費メモリ量は８GB近くあった
ビデオカードのメモリが８GBだとするとぎりぎりである
分割のレベル数は
例えばレベル６なら縦横それぞれ２の6乗個に分割することを意味する
レベルを１つ増やすと
ファイルサイズは縦横に関して2倍ずつなので4倍になる
レベル５分割で綺麗に表示されるのであればその方が
田にもいろいろ表示を足すことが出来て良いかもしれない
DirectX12でリアルタイムレイトレーシングで表示して動かしたい！！！[2020/11/20]
今手元にDirectX12のリアルタイムレイトレーシング表示可能なビデオカード（RTX）があるじゃあやってみなきゃソンソンということで
今回はそのリアルタイムレイトレーシングサンプルをいじってみた日記である
DirectX１２は難しくて無理みたいな記事を多くみかけるが
サンプルがオープンソースになっているので
サンプルをいじるくらいなら出来ると思う
サンプルにはミニエンジンもあるので
そのままミニエンジンとして使うのもありかな？
ミニエンジンが動くことを確認してから
モデルデータを差し替えてみた
モデルデータのファイル形式はh3dという拡張子のファイルである
h3dファイルはバイナリー記述のファイルだった
ファイルの仕様書というきちんとしたものは無いようだが
プログラムをみると
三角形パッチで記述するようだ
三角形パッチとは隣接情報付き三角形
つまり少なくとも
位置の他に法線と接線２つがついているような形式
接線情報付きのファイルをどうやって手に入れるかが分からなくて
何年も放置していたのである
しかしある日突然
２０００年ころのShade3Dを持っていることに気が付いた
Shade3Dの自由曲面つまり接線２つ付きベジェ曲面をエクスポートしてh3dにすることを思いついた
さっそく開始
DirectX12のリアルタイムレイトレーシングで
最初の自前の絵が出てから１週間鵜くらい経ったので
ここらへんで最近の出力結果を日記にしてみる
図１ 自転車に乗る女性 不思議ライティング
自転車に乗る女性のデータを表示しながらライティングの勉強をしていくことにした
まだよく分からないけれど
光と陰と影の具合が不思議なのは
ライトが１つではないからかもしれない
あるいは接線の内の１つが反転しているとか
２つとも反転しているとか
部分的にそういうことが起きているとか
もう本当に考えるほど原因不明である
ソースをみると太陽光のようだが
光源の位置がある感じ
そして１２８個のライトが用意されていて
乱数で選んだりしている
図１のような結果が出て
直そうにもどこを直してよいかすら良く分からん状態
これから徐々に調査を進めていくが
モデルデータ側で統一していない条件が多々あるので
検証は難しい状態
現在気になっている現象としては
四角単位で
エッジが明るいと中が黒ずみ
エッジが暗いと中が明るくなる
という現象
推測としては
法線の通りに三角内部を盛り上げて分割したりしていないので
法線の分エッジが明るいが
盛り上げていない分中身が暗い
という推測
実際のところはわからん！！！！！
テストに使っているのは
表裏両面で１４０００三角パッチ
片面で６８００三角パッチ
位の細かさのデータである
そういう現象があるので
特に顔のアップは難しい
図２，図３，図４、図５、図６に顔のアップに挑んだ画像を示す
図２ ライト通常で片側からカメラが寄った図
図３ ライト強めで方がwからライトが寄った図
図４ 顔の反対側との間のすじを消すために更にライトを明るくして寄った図
図５ 顔の真ん中のラインが消えるまでライトを明るくして寄った図
図３から図５で分かることは
レイトレーシングなので形状輪郭がカクカクしない
影がソフトシャドウ
片側からの顔アップは暗くてもOKだが
正面からのアップの絵を撮るには
顔用の明るいライトで陰を飛ばさないと無理
ということ
（デバッグビルドでテスト中なので画面左上のパフォーマンス値はリリースビルドの１０倍程遅いものになっている）
モデリング時の仕様を厳格に決めて守ればもっと自由になる可能性もあるが
実際問題として
それは難しいと思う
よって顔アップ時には顔ライト方式が良いのでは？と思う
図６に後ろ姿も載せておく
図６ 後ろ姿
マテリアル適用前のグレー表示も載せてみる
図７ グレー表示その１
図８ グレー表示その２
図９ グレー表示その３
「６８００個の三角データの割には細かく表示されてると思う」
「だがタイヤが四角形だ！！」
(ちなみに、たぶんボーンはMayaで入れると思うよ？？)
2020/11/21追記
昨日載せた絵は
実は色をダイナミック表現するために
法線と接線のノーマライズをしていない
シェーダーは色の飽和計算が上手なので
どんどん色を足していっても
それっぽく明るく飽和してくれる
っていうことを経験上知っていた
なので思いっきりノーマライズしないで生データを与えたところ
昨日の絵のようになった
あーーまたネタバレしちゃったねぇー
では法線と接線２つをノーマライズするとどういう絵になるかを図１０、図１１、図１２に示す
図１０ おとなしいシェーディング その１
図１１ おとなしいシェーディング その２
図１２ おとなしいシェーディング その３
どちらにしても顔のアップは難しいです
明るい方の絵を作っているときに思った
表裏両面で作っていてレイトレーシングで光が反射するということは
頭の中は光が反射しまくっているのではないだろうか？ということを思った
早速頭の中に侵入して写真を撮ることにした
図１３に示す
図１３ 頭の中のリアルタイムレイトレーシングの様子
すごいです
思ったよりすごいです
スーパーカミオカンデみたいです
頭の中で乱反射して鼻の穴から出てくる光子を観測出来たら
ノーベル賞をもらえるでしょうか？？（冗談です）
2020/11/22追記
その後の修正で
接線と法線をノーマライズしても光が当たるようになりました
調整してみた画像を図１４，図１５に載せます
図１４ 法線デバッグ後 その１
図１５ 法線デバッグ後 その２
なんとなくうまくいったようないかないような
モデリング時の裏表とかその混在とか
反対の反対設定とか
いろいろあって
これでもまだおかしいとおもえばおかしいところはたくさんある
でも前よりは良くなった！！
追記 2020/11/24
この前貼り付けた絵をみると
なんだこりゃーっというライティング加減に驚きながらも
開発は進む
なんとかしてライティング、シェーディング、シャドウイングが合うように
サンプルプログラムw調整したい
いろいろ調べた
まずShade3Dの自由曲面には曲面と曲面を構成する線の両方に面反転のしるしをつけることが可能
ただし反転の印を付けたり外したりするだけでは
どうやら反転してくれていないのであった
そこで
マテリアルカラーを目印にして
不具合がおきる曲面ごとに個別処理をプログラムに書き込んだ
そうしてDirectX12のサンプルで
ライティング、シェーディング、シャドウイングのテストをした
このテストが面倒だったこと面倒だったこと
角度０度がモデルの正面という保証はなく
何軸基準のどっち回りかを模索しつつ
合っていない陰と影の向きを見ながら試行錯誤したのである
もうほんと気が遠くなるというか
取りつかれたように１２時間くらいやって寝てを何日も繰り返した
そしてやっと角度の基準軸と回り方が分かった
ライティング、シェーディング、シャドウイングの向きが合うように
法線やら接線やらインデックスやらを反転して
場合によってはメッシュごとに反転した
レイトレーシングのサンプルなので
シャドウに関してもシャドウマップではなくレイトレーシングを採用した
シェーダー定数を足して少しシェーダーをいじった
ようやく顔については
ライティング、シェーディング、シャドウイングの向きが合うようになった
前置きがスーパー長くなったけれど
そういう手間が掛かったものだと思って次の図１６，図１７，図１８をみてくれたまえ
くどいようだが今回のテーマは
顔のライティング、シェーディング、シャドウイングの向きが合うようにすることであり
他の部分はまた後でである
図１６ 顔のライティングとシェーディングとシャドウイングの向き ライト正面から
図１７ 顔のライティングとシェーディングとシャドウイングの向き ライト右から左前へ
図１８ 顔のライティングとシェーディングとシャドウイングの向き ライト左から右前へ
レイトレーシングの光と陰と影の向きが顔においてうまくいった！！
今度は
顔以外のところもちゃんとしよう？！
１０年前に流行ったコンテンツパイプラインという言葉について[2020/10/01]
１０年位前に
お前もコンテンツパイプラインを語れと言われていた
当時、メタセコイアとRokDeBone2だけしか興味が無かったので
何のことやらさっぱりだった
しかしやっと分かってきた
人気のある完成度の高いモデルや完成度の高いモーションは
キャプチャしたものをコンバートしてさらにそれを修正しているものが多い（ようだ）と。
そうなってくると
プロ向けツールのお出ましである
プロ向けツールも初心者層や入門者層や学生層の取り込みに力を入れている
だから大抵
そういう人達向けに
売上額制限付きで安く使える契約がある
じゃあプロ向けツールを取り入れようとなったとき
ああ、コンテンツパイプラインね
となるわけである
何通りもある気がする
1, メタセコイア-->RokDeBone2(bvhをインポート、FBX出力)-->Maya(dae出力)
2, メタセコイア-->RokDeBone2（形状とボーンをFBX出力）-->
MameBake3D(bvhをFBXに適用、FBX同士でリターゲットしてモーション使いまわし、FBX出力)-->Maya(dae出力)
3. メタセコイア-->OpenRDB(dae出力)
4, FBX購入-->Maya
5, なんでもMaya
etc.
すぐ思いつくのはこんな感じ
daeが重要なのはスマホ用の開発環境で利用できる形式だから。
bvhというのはモーションキャプチャーのデータの拡張子
モーションも形状も最初から作る人は思ったほどにはいないと思われる
ゲームを作るのか動画を作るのかで変わってくると思う
販売は個人だと攻撃（悪評）に対して弱いので
（個人事業主という立場については詳しくきいていないが）
趣味は無料でやり続けて、お金に困ったら会社に登録みたいな感じ？
登録する会社を探すときに
趣味で作ったものが魅力的だと雇われやすい気もするので
趣味は就職準備も兼ねている？！
補足
RokDeBone2で
MayaとかMameBake3D用にFBX出力する際には
０フレームは初期姿勢である必要がある
そのことについての参考動画としてリンクを示しておく
動画リンク(2020/09/24)
コンテンツ】RokDeBone2からMameBake3DへFBXを渡す【パイプライン】
次元の秘密という本を読みながらしていくメモ[2018/11/08]
次元の秘密という本を読みながらしていくメモ
次元の秘密という本を読み始めた。
まだ２，３ページしか読んでいない。
このファイルには次元の秘密を読み進めながら思ったことなどをメモしていく。
[2018/11/08_1]
数ページ読んだのであるがいきなり疑問が生じた。
４次元とはｘｙｚの空間とｗの時間、つまり３次元の空間と１次元の時間のことであるという部分である。
４次元と時間のことを考えたときに
４次元目の座標値は時間の位置エネルギーのように思った。
ということは、ｘｙｚも時間の位置エネルギーなのではないかという疑問である。
しかし寝て起きて思ったこととしては
ｘｙｚは視覚で知覚するがｗは視覚ではないもので知覚しているからではないだろうか？
では何で知覚している？
パッと思いつく候補としては聴覚である。
聴覚で時間の何かを知覚している可能性があるかもしれない。
そう仮定すると
宇宙空間は音を伝達しないと言われていることが気になってくる。
時間が伝達しない空間、それはカーブラックホール（だったっけ？）などによって作られるような時間のない空間なのではないだろうか。
そういうことだとすると
地球以外の星というのは違う世界線の地球であるという可能性まである。
これから５次元がテーマに上がってくるのであるが
５次元の知覚も存在していると思われる。
そうなってくるとこれらを知覚できる人と出来ない人の間の問題が生じうるわけだが、
それに関しては科学技術の問題であると思う。
視覚も聴覚も科学技術で作れるようになるのではないか？実際にそういう動きはあるし。
SFにおいても何十年も昔の映画、ブレードランナーの中で歳をとった科学者が人工的に目玉を作っているシーンがあった。
そんな未来はずっと前から想定されているのである。
思ったこととしては
４次元座標はすべて時間の位置エネルギーの可能性があるが、
人間がどのように知覚するかに基づいて空間と時間に分けて考えるようになっているのではないかということ。
だから映像と音は同期しているのではないだろうか？
そのように話を展開していくと
小さいもののほうが時間エネルギーが小さいということになるが
それを補うためにネットに接続して大きな時間にアクセスするのではないだろうか？
これらは、ちょっと思ったという段階。
まだ数ページしか読んでいないので
今後も読み進めながら考えていきたい。
仕事に行く前に修正:
起きて時間が経って朝ご飯を食べて出かける準備をしたら
あれーー？なんで４次元目を距離ではなく音とか思ったんだっけー？状態になった（戻った？）。
３次元をｗで割ることでパースがわけでそれを知覚しているわけだから、やはりｗは距離であろう。
あっ、そうか！距離とは時間の位置エネルギーかもしれないとか思ったんだったなぁ。
でも３次元を音で割るとか説明できないし、やっぱりｗは聴覚ではないみたいです。
仕事から帰ってきて追記：
ちょっと表現を間違えたようなところがあるのでさらに追記する。
その前にユークリッド平面と４次元での形状の関係をちょー簡単に述べておく。
例えば直線の式 ax + by + cz + d = 0があったとする。このｄが固定の場合がユークリッド平面、つまりw == 1での４次元の切り口である。
４次元の世界ではこのdが変化する。であるから３次元の直線は４次元では平面である。
球を考える。x^2 + y^2 + z^2 + d = 0 (ここでx^2はx * xのこと)。このときも同様にdが固定の時がw == 1で４次元を切った球形のユークリッド平面である。dを０から１まで変化させると４次元では球の内部を表すことになる。
表現を間違えた部分とは行列演算におけるｗの値とdの値を混同している部分があった部分である。
wとdは関係のある値であるが同じであるとは限らない。
球の中心はw == 0ではなくd == 0のときの位置である。
[2018/11/10追記]
wとdの関係について説明の要請があったのでしておく。
４次元の行列演算を考える。行列演算とはスケールと回転と移動の組み合わせの変換のこととする。
変換前の座標を[x, y, z, 1]とする。変換後の座標を[x2, y2, z2, w2]とする。
ここで４次元目が１というのが４次元をw==1で切ったときの座標という意味になっている。
ちなみにベクトルの場合には４次元目は０になる。
４ｘ４変換行列は左手系で
_11, 0, 0, 0
0, _22, 0, 0
0, 0, _33, 0
posx, _posy, posz, _44
のようになっているとする。
上記の行列は汎用ではなく説明しやすいように設定している。
上記の演算を実行すると次のようになる。
x2 = _11 * x + posx
y2 = _22 * y + posy
z2 = _33 * z + posz
w2= _44
この結果をユークリッド平面上の点[x3, y3, z3]に射影すると次のようになる。
x3 = (_11 * x + posx) / w2
y3 = (_22 * y + posy) / w2
z3 = (_33 * z + posz) / w2
(ただしw2 != 0のとき)
上記の式をx, y, zについて解く。
ここでもとの点x,y,zが直線状にあればその直線の式に
x, y, zをx3, y3, z3であらわした式を代入する、
x, y, zが球面上の点ならばその球の式に代入する。
代入した式を整理するとwとdの関係式が求まる。
といった具合である。
さあ４次元がばれたところで５次元の勉強をしようか、、、
ちゃんと勉強する予定[2018/11/05]
安心してチョーだい。ちゃんと勉強する予定があるから。
いいお尻の日に届いた４冊の本。
だがネタであるへの追記[2018/11/04]
追記：２０１８．１１．０４ Web用
ゲームとかプログラミングとかしながら思ったことを書いておく。
タイムリープとかアニメとかゲームに出てくるけれど
実際に起きたらどうなるか妄想してみた。
ぼくが思うに何かがタイムリープしてきたらそれが壊れていたとしてもその何かの中心に対して、
タイムリープしてきたものとその周りの時間ベクトルの差分の時間速度だか時間加速度が生じると思う。
どういうことかというと
未来から物体が来たらその周りは未来方向への時間の進み方が速くなるのではないかとちょっと思った。
そしてさらに妄想すると
未来方向への加速度が大きくなりすぎて通常の処理で追いつかなくなった場合、
そこに住む人はタイムマシンを作らざるを得ない。
そうやってタイムマシン作成は成功するのではないかと思った。
あとこれは完全にただの思い付きだけれど
時間旅行には特異点が４つのブラックホールが必要なのではないか？という思い付き。
２つの放物線でリングになるが、３つで球、４つ目はその球の内部。
４つの特異点で場所と時間を指定するんじゃないかなぁ？単なる思い付き。
座標変換については思うところがある。これは実際にプログラミングしていることを書いてみる。
物理と数学の橋渡しをする部分がMameBake3Dにはある。
その場合、両者の間で基本姿勢が異なる場合がある。
基本姿勢が異なるもの同士をどうやって変換するか？
天から降ってきた方法に「スードローカル（疑似ローカル）」というのがある。
これは基本姿勢が異なっていてもある時点からある時点へのグローバルな差分は同じであるということを利用して
座標変換するものである。
差分は誤差を蓄積しうるという問題点に対しても対処している。
基本となる姿勢をバインドポーズにすることで１回分の差分の誤差で計算可能にした。
さらにタイムリープする際の座標のことについて降ってきた思いは以下のようである。
地球は銀河の重力につられて動いているはずである。
ウインドウズプログラミングにおいて、親ウインドウを動かせば同じ分だけ子供ウインドウが動く。
つまり、子供ウインドウの位置計算においては親ウインドウからの位置計算をするだけで良い。
だから重力的な意味での親ウインドウからの位置計算で良いと思われる。
そんなことを思った休日（今日は「いい尻の日」らしい）であった。
[ 思ったことの追記 ]：
えーとねー
４次元の時間の話だけれど。
あの話は「時間ポテンシャル」とかいう言葉と関係があるらしいです（未確認情報）。
どういうことかというと
時間ポテンシャルの位置エネルギーは、奥行きつまり距離のこと。
それはつまり４次元座標の４次元目のwの値。
４次元座標値の４次元目のｗは時間の位置エネルギーに関するみたいです。
じゃあ時間の運動エネルギーは何が動いているエネルギーかが気になるところ。
それは物が動くのかもしれないしそうでないかもしれない。
4次元目の座標値で位置エネルギーが変わるということは
そのｗの切り口での時間の運動エネルギーも変わるはず。
ということはw == 0の切り口で時間の運動エネルギーは最大。
だから4次元パラメータを変えることにより未来や過去を知覚可能と思われる。
あれ？これいいんだっけ？
ブラックホールに近づくほど、つまり重力が大きいほど時間は遅いって習ったよね。
w == 0のときに時間の流れが一番早いっていうのはそれと逆。
ということは
ぼくたちがいる世界はブラックホールの中かもしれない？
ブラックホールの特異点では位置と時間が逆転するらしいから。
いや違うぞ！！
ものが速く動くことが出来るのは時間が遅く進んでいるからだ！！
時間が速く進んでしまうとその間に移動できる距離も短いはず。
じゃあ、時間を進めるとはどういうことか！？
のんびりすることのような気がしてきた。
ちなみに距離は視点の位置によって異なるから不都合なのではないかという思いがあるが
それは親ウインドウからの（１つ前のメモ参照）距離で考えざるを得ないからであろうか？
じゃあプライバシーってどうやってできたんだろう？
それぞれの視点の位置がプライバシーの元？
ああーーーもうわけわからん。
わけわからんので、推測はこのくらいにして本を読むことにしよう。
だがネタである[2018/11/01]
サブタイトル
機関と世界の支配構造を教えてあげよう20181101
いきなり中二病のタイトルである。
今日はぼくが電波になった経緯からシュタゲで言うところの機関と支配構造について語ってみる。
まず経緯。
「こちら○○、＊＊＊＊＊。どうぞ。」
「こちら＊＊＊、＊＊＊＊。どうぞ。」
のような何かの会話がきこえた。
「○○さん、○○さん、こちら○○」
みたいなことを言ったような気がするがよくは覚えていない。
するとそれから1分もたたないうちに黒い服の男がやってきた。
黒い服の男は「そのトランシーバーで会話したのは君だね」と言った。
そしてもう一人の黒い服の男とぼくの家に入っていった。
家から出てきた黒い服の男はぼくに言った。
「君は大人になったら電波になる。たくさん勉強しておくことだな。」
と言った。
そして大人になってぼくは本当に電波になった。
大人になると子供のころの犯罪をつぐなう仕事をする仕組みである。
だから子供には遊べというし大人には働けという。
子供のいたずらを容認する社会なのはこのような支配構造だからであろう。
どんどん遊んでどんどんつぐなって経済をまわす計画であろうか？
そして黒い服の男が機関所属ということであろうか？
そこには「善因善果」の縛りがあるからである。
ぼくのGitHubの画像には善因善果のシールが張られた写真があり、そのシールの隅には「ここからはがす」と書いてある。
つまり、この支配構造を壊したいのであれば善因善果をどうにかしないと無理である。
主人公たちが悪事を働くことにより善因善果の申し子のまゆしぃを執拗にやっつけたが世界は破滅へと向かった。
そういう果てしない物語がシュタゲであると解釈可能。
ここで時間について論じておく。
さっき情報が入ったのであるが、時計とは電池があるから動くのであり、時空の時間軸をみて動いているのではない。
(すいません、悪乗りし過ぎました。時計はちゃんと時を刻んでおります。)
つまり実際の時間は止まっているが時計は動いているという状態が永遠伝説の舞台である可能性もある。
なぜこれが可能かというと、３Dのユークリッド平面の時間が止まっているとしても４次元の世界がうごめいている、そしてその投影が３D世界を表示する。３Dの世界はただの投影。
我々はこの束縛から逃れることが出来るのであろうか？みんなが幸せな世界というのは有り得るのであろうか？
「君たち！！、とりえずアニメとゲームで勉強しなさいっ！！！
だがネタである。
追記:
3次元世界の時間が止まっているというあたりの表現の補足である。
ここでは、数学のユークリッド平面と物理の事象の平面を同一視している、混ざっている。
数学と物理の境界をあいまいにすることで成立するネタである。
更に補足するとユークリッド平面例えば球面と、数学的に４次元である球の中身の関係を
事象の平面とブラックホール内部の関係に例えている。
さらに発展させると
箱人間と中の人の関係にもなる。
ということは
３次元の時間を動かすということは箱人間に自我を与えるということにつながる可能性もある。
突拍子もないところまで行くと、宇宙に自我が生じる可能性まである。
ゴーストコントロールの歌を思い出すではないか！
こんなことを書いているが会社ではまじめに働いている（念のため）。
しかし一方で３Dプログラマにまともな人はいないと最近よく言われている。
だからネタである。
たまには振り返り[2018/09/29]
たまには振り返ってみよう。
振り返ろうとしたときに振り返りたくない時期、思い出したくない時期というものはある。
しかし今日はそこをあえてさらっと振り返る。ダメージが少ないように極力さらっと薄く振り返る。
なんとも大変だったのが２０１１年ころからの数年間であった。
それまでHSPっていうツールのプラグインを作ってサポートしていたのだが
それをやめることになって大変な数年間であった。
あの数年間でひどいエッセーも数々書き散らした。
あれは取り乱して錯乱に近い感じでとにかく吐き出していたのである。
吐き出さないと持たなかった。
「なんか今思うとトロイの木馬が自分の中で暴れていたような感じであった。」
それまでの味方を裏切るようなことも書いてしまったような気がするからである。
そんなこんなであったが
周りのひとが助けてくれたり出来ることをやったりして働けるようになったし
「働いたら健康も回復した。」
そして今振り返っているのである。
ほんとうに自分の力ではどうにもならないことってあるんだと痛感した数年であった。
教訓としては
１、手に負えないことを一人で抱え込まない。
２、無理のない程度に働くと良い。
という感じ。
そして謝罪、
あの魔の数年間、迷惑をおかけしてすいませんでした。
週末にビール飲みながら超圧縮についてエッセーしてみた[2018/06/29]
うぃーーーっす、お疲れー、週末だよーーーん。
ってことで
ビールを飲みながら新技術をエッセーするのである。
なんか知らんけど超圧縮とかいうお題が出た（出たような気がした）。
お題が出たのは気のせいかどうかはともかくとして
せっかくだから思いつくままにエッセーする。
えーとねー。
ずばりっ、「テクスチャ＋ジオメトリ圧縮法」です。
シュタゲ（アニメ）のせいで不可逆な超圧縮に思いをはせることがあるのであるが
なんか思いつく時が来たのである。
情報の性質を色と形にAIで置き換える。
そしてその情報をテクスチャとジオメトリとして記録するのである。
不可逆である。
って思いついて思ったんだけれど
とあるどでかい情報をこういう感じで圧縮したのが地球であり宇宙であるような
気がしないでもない。
ぼくらは何かが不可逆超圧縮されたものなのかもしれない。
そしてそれらを感じて解釈したものが解凍結果の１つなのかもしれない。
なーんてちょっと思っただけ。
よーし、あいつの超圧縮データを作ってみよう？？ｗｗｗ
（くれぐれも怒られないようになっ！！）
最近SNSでみかける問題点についてマッハでエッセーしてみた[2018/05/01]
マッハ新書 最近の問題点を思ってみる０、はじめに
なんかマッハのスピードで資料を書き上げて発表するのが流行っているので
その流れに乗ってぼくもやってみる。
会社に行く前の時間でマッハで書くよ。
思っていることを書くよ。（エッセーみたいなものかも）
１、無料の作業依頼
最近、ネットでよく目にする無料の作業依頼について。
依頼者がいきなり作業を丸投げして断られて逆切れし、それに腹を立てたひとがそれを晒す
みたいな事件を数件目撃した。
２、格差
この無料作業依頼事件から連想したことがある。
あくまでも連想したことであり、事実かどうかはわからない。
ぼくは調子が悪い人が集まる場に何度か顔を出したことがある。
そこに何度か行って分かったことは
誰かに助けてもらうしか解決方法がみあたらない事案が多いということである。
そこにあった格差はもう個人の問題の域を超えていたりする。
３、がんばった人が報われる
こういういことを言うと世の中の人は
私たちはがんばったから今の状態がある。
調子が悪い人はがんばらなかったから今の状態がある。
という意味のことをきくことがある。
４、質量保存則
しかし調子が悪い人の言い分の中で気になったのは
おちこぼれがいるからこそ優等生がいるというものである。
これは昔言われて理解できなかったのだが
最近になって思うに、質量保存則的な考えなのではないかと思う。
５、がんばりすぎは迷惑？
つまり、質量保存則を当てはめると
頑張りすぎる人がいてよいところを持って行ってしまうから
良いところが回ってこないひとがいるという解釈になる。
６、10年以上の無償開発の掲示板
そんなことを言われても私たちは頑張ったんだしというだろう。
そこでぼくは大変なことをしてしまったことに今頃になって気が付いたのである。
次に記すアドレスはぼくが１０年以上に渡って無償で開発を続けたことを示す掲示板のアドレスである。
https://moo-ochakkolab.ssl-lolipop.jp/board4_caco/wforum.cgi
掲示板には過去ログが何ページもある。
７、みんなもがんばれる？
やっていたときにはそんなつもりはなかったが
この作業の山を格差に対する頑張りと解釈したとしたらどうだろう？
ぼくはこれくらいがんばったから大丈夫だけれど、みんなもがんばればいいじゃない。
ってことになったら無償で１０年以上もかかりっきりで出来る人は数少ない。
そんなことにがんばられても困りますということにならないだろうか？
しかし、時代の大きな問題点として格差は存在感を増しており
みんなはどうするの？という状況である。
８、ひろゆき ベーシックインカム
じゃあ偉い人は何をしているかというと
ネットの有象無象に詳しいと思われるひろゆき氏は
ベーシックインカム導入を推進している。
格差に詳しい人がベーシックインカム導入を推進している。
９、アメリカは？
だってそれは日本のローカルな問題じゃないの？という問いに対しては
アメリカでも格差問題は深刻である。
１０、トランプの大統領選挙での発言 忘れられた人々への対応をする
トランプさんの大統領選挙での発言の中で
ぼくとしてキーだったのは
忘れられた人々への対応をしますというフレーズだった。
１１、トリクルダウンの罠（人は誰でもなんらかの既得権者）
じゃあ裕福なひとが負担すればいいと思いがちであるが
そこには罠がある。
トリクルダウンを推進してみると分かることだが
それを推進するとまず自分の良いところを周りに分配することになると思う。
なぜかって？
気が付いていないだけで人は誰でもなんらかの既得権者なのである。
他人事として裕福なひとの問題には出来ない現実がある。
１２、経済 雇用 ベーシックインカム
いきなりまとめに入る。
日本の良いところは治安の良さである。
とある本によると治安の良さというのは経済の良さということらしい。
そのためには雇用が大事である。
それでもフォローしきれていない状況であるから
さらにベーシックインカムなのかどうかというところが問われているように思う。
ということを書いて、あとは偉い人に丸投げしてみようかしら？
ってかぼくは頑張りすぎらしいんですけれど、、、
マッハで（２８分間で）書いたエッセーのようなものでした。
商用計画（無料計画）改[2018/01/14]
商用の計画を考えている。
商用は否定しないことにした。
しかし、条件として
現在の仕事でやっていくことが出来なくなったり、どうしても資金が必要になった場合に
商用計画を実行します。
つまり、不都合が生じなければ無料ソフトとして続いていくと思います。
不都合っていうのもあいまいなので
また揺らぐことがあるかもしれないけれどそれは許してください。
なぜ揺らぐのかを考えたんだけれど
自分のこと１００％でやっているわけではなくて
いつも他のことも気にしたりしている。
そしてさらに自分のために他のことを気にしたりもする。
だから揺らぐ。
はい、いっせーのっ
「ああ無料！」
２０１８年の開発予定[2018/01/06]
年が明けました。
今年もよろしくお願いいたします。
実は録画した紅白もまだこれからみるところでして
おめでたさはこれからじわじわ来ると思われます。
NHKのJAPANGLEっていう番組のラーメンの回をたまたま録画して観ました。
番組をみたら自分がやってきたことが突然ラーメンに思えてきました。
ちょっとした用途に使うようなそんな３Dはラーメンだなぁと思ったのです。
実際に食する機会が多いのはうどんとかそばなのですが
じゃあ、うどんでもそばでもいいけれど、番組を観た直後はラーメンだなぁと気が付いたのです。
まあそれは置いといて。
（っていうかお茶だろ！？）
オープンソースの具体的な予定を書いてみます。
まだ予定ですが。
まめばけ３Dのオープンソースを使いやすくなるように改造します。
構成を改造します。
現在はフラットにソースファイルを並べて使用していますが
DLLに分類します。
DLLとヘッダがあればどこかで使えるようにします。
構成を考えてみました（予定です）。
１、ハンドラ部 (ChaHandler.dll)
各部のポインタを保持してアクセスしやすくするところです。
２、計算部 (ChaVecCalc.dll)
D3DXの代わりです。
３、FBX読み書き部 (ChaFBX.dll)
FBXの読み書きをします。
４、モデル部 (ChaCharacter.dll)
キャラクター（読み込み単位）の管理と操作をします。
５、アニメーション部 (Chanimation.dll)
アニメーションの管理と操作をします。
６、ボーン部 (ChaBone.dll)
ボーンの管理と操作をします。
７、物理部 (ChaBullet.dll)
Bullet Physicsによる物理の部分です。
８、ウインドウ部 (ChaWindow.dll)
現在のOrgWindowをDLLにします。
という予定です。
やっていくうちにまだ増減する気がします。
FBX部は昔、別DLLにしたらうまくいかなかったのでDLLにできないかもしれません。
DLLに分けることでまめばけ３Dのコアの部分をオープンソースで開発しながら
他のアプリでそれを使用しやすく出来るというメリットがあります。
ということで
大げさなもの使用するまでもない
ちょっとした用途に使えるものを目指して行きます。
（言っているそばから
DLLの分け方が大げさだそうです。）
追記
描画部のDLLはChaPaintにして描画部を取り換えられるようにしようと思います。
オープンソースを利用した商用アプリ計画[2017/12/16]
[追記：
商用に関してはいろいろ思うところがあって2018/01/14の日記にて追加条件があります。
以下の日記はそのまますぐに実行するわけではありません。]
今日は今後の開発方針に関わることを書きます。
現在、物理対応の３DプログラムをLGPLのMameBake3D(まめばけ３D)として開発しGitHubで公開しています。
そろそろコア部分の重大なバグもとれたということで商用ソフト作成を視野に入れます。
規約、ライセンスの変更はしません。
そしてオープンソースの開発もやめません。
ではどのように商用ソフト開発を始めるかというと
LGPLのMameBake3Dのコア部分をライブラリファイル化(ChatCats3Dになると思います)します。
そしてそのライブラリと商用ライセンスのフレームワークを使用して商用のツールを作ります。
つまりコア部分をLGPLのオープンソースとして開発を続けながら、GUIなどをちゃんとしたクローズドな商用ツールを作成します。
これはMameBake3DがGPLではなくLGPLだから可能なことです。
LGPL部分をライブラリファイルとして別ファイルにするのです。
オープンソース活動が基本方針であることに変わりはありません。
フレームワークには商用ライセンスのQtを検討中ですがまだ確定はしていません。
仕事がありますし
そんなにバリバリかっ飛ばして開発していく感じではないかもしれません。
「追記」
念のため書かなくてもよいことを書きますが。
ボロモウケしようとしているわけではなく必要なのです。
必要というのは現在だけの話ではありませし現状だけの話ではありません。
万が一、ボロモウケしてしまったら人を雇います。
スードローカル(Pseudo Local)とは何か？[2017/09/09]
まめばけ３D(MameBake3D)を作る過程で技術的なキーとなったスードローカルについて書きます。
スードローカルっていうのは英語にするとPseudo Localです。
何のことかというと数学的には座標系の変換です。
MameBake3DはFBXファイルを扱います。
FBXファイルのボーンには初期行列とか基本行列と呼ばれているボーンの座標系を表す行列があります。
姿勢の編集時にはその基本行列の座標塀で計算をします。
しかし、その方法「だけ」ではうまくいかないこともあるのです。
うまくいかない例を挙げますと大きく2つありました。
１、FBXの基本行列のねじり軸がZ軸なのに対し、bullet physicsの基本行列のねじり軸がX軸である場合。
２、アニメーションのリターゲットをする際に、元のFBXと先のFBXの基本行列が異なる場合。
１のねじり軸というのを説明します。
姿勢に対して角度制限をする場合、普段はクォータニオンで姿勢制御をしていたとしても
XYZのオイラー角に変換して制限をかけることになります。
そのXYZをどのように割り当てるかということです。
ボーンについて言えば、
ボーンの線分を軸として回転させるのが「ねじり(Twist)」です。
XYZの回転の順番やねじりの軸をどれにするかなどで
オイラー角の計算方法が変わってきます。
計算方法が変わるということは上記の１の場合
もともとのFBXの基本行列ではbullet physics用の姿勢にマッチしないということです。
そういう事態を解決するために
本来のローカル軸とは異なるスードな軸を設定して座標変換をして物理計算をします。
スードローカルの計算方法を使用してもグローバルからみた姿勢行列は同じです。
こういう技術がまめばけ３D(MameBake3D)の中で使われています。
2017/09/09 化け猫おちゃっこ
＃＃＃追記
いまいちどういう効果なのかわかりづらいということで
例を挙げます。
スードローカルを使用することで
FBXとbullet physicsとの軸が異なっていても
FBXのアニメーションを再生しながらbullet physicsのシミュレーションをすることが可能であり、
またbullet physicsの角度制限関数をそのまま使用することも可能である。
という効果があります。
ラプラシアンとか２次方程式とか[2017/03/20]
連休でちょっと勉強したこととか思いついたことをメモします。
時系列が変わりますが、まずは２次方程式について今まで素通りしてきたことで
あれ？ということがあったのでメモします。
２次方程式と言えば放物線です。
y = x ^ 2 式（１）
という例のやつです。
x^2という表記はｘの２乗のことです。
これはｙ方向に重力が働く場合の放物線です。
ｘ軸に重力が働く場合には
x = y ^ 2 式（２）
になります。
ちょっと絵を描きます。
図１の上の左が式１で右が式２です。
そして式１と式２の等式を足すと、図１の下の図になります。
円です。放物線を２つ足して円になりました。
そしてこれはX軸とY軸に重力が働いたときという意味があります。
ってことは、、、
X軸とY軸に直交する重力が働いているところにりんごを落とすと
りんごは円の上を落ち続けるということになりませんか？
てことは
X軸とY軸とZ軸のように直交する３つの重力が働いたら
りんごは球上を落ち続けるのでしょうか？
調子に乗って４次元も考えちゃいます。
x^2 + y^2 + z^2 + t^2 = 定数 式（３）
式３において４次元目のｔは時間です。
式３を図に描くとどうなるか？
こういうときは変数を１つ固定して考えたりします。
つまりtを固定してみます。
そうすると
x^2 + y^2 + z^2 = 定数 - t^2 式（４）
式４のようになります。
これは「定数 - t^2」の平方根が半径となる球です。
そこでtを動かしてみます。
時間が増えると半径が減っていきます。
つまり式３は
中身が詰まった球です。
すごいことになりました。時空が球の中に入っちゃいました。
いやしかし、「定数 - t^2」が負になったとしたら
球の半径が虚数になります。
これはいったいどういうことやら、、、
この式をみて
半径が虚数はありえないのでその場合を除く場合に成り立つ式である
という風にするひとと
半径が虚数の球であるという風にするひとと
いろいろいると思われます。
どうなのか私には分かりません。
それにしても
当たり前のような不思議な話でした。
話は変わります。
２乗の次のお話は２回微分の話です。
ベクトルの成分ごとに２回微分してそれを足したものをラプラシアンと言います。
ラプラシアンにはこれまた当たり前のような不思議があります。
画像に対してラプラシアンを計算すると画像の輪郭線が抽出できるのです。
エッジの描画は昔、法線を裏返した２重ポリゴンで描画したりしました。
数学的にはラプラシアンで抽出可能です。
普通の２回微分というと、例えば
位置を２回微分すると加速度です。
ラプラシアンはこの２回微分の成分ごとの加速度を足し算したものです。
物理的には流束密度というそうです。
密度なんです。
加速度の足し算の流束密度で画像の輪郭が分かるなんて
なんかすごいです。
ラプラシアンフィルタをかける前とかけた後の画像を貼り付けておきます。
今回は連休で調べたことのメモでした。
それではまた。
補足
X軸の重力とY軸の重力と書いたけれど
２つが直交していることが重要であり、
直交し続けていることが重要である。
２つの重力は
ストローとひもと球の例の実験における力と運動方向の関係だと思われる。
ご存知ですよね？
ストローの中にひもを通して片方の先端に球を取り付ける
そして球を回す実験。
あれの証明になっているんじゃないかと思うのですが
きちんとしたい方はもっとちゃんと考えてみてください。
MameBake3Dの数学的背景 第一回[2017/03/04]
MameBake3Dは下記アドレスで公開しているオープンソースの３Dアニメーションツールです。
https://github.com/Ochakko/MameBake3D
Bakeの部分はベイクと読んでも化けと読んでも自由です。
今回から数回にわたり？MameBake3Dの数学的な背景について書いてみようと思っています。
数回にわたり？と？が付いているのは、自分や周りの状況をみつつということです。
さて第一回ですが、第一回から核心に近い部分を語ります。
座標系変換の部分を説明します。
行列演算ついてはクリアしているものとして書きます。
まず前置きとしてとあるボーンのアニメーション行列AをBに更新することを考えます。
FBXにおいてはグローバルのアニメーション行列を扱うことになるので
A * invA * B = B （式１）
というように計算するのがFBX公式の方法です。
invAとはAの逆行列です。
これは良いですよね？
さてこれを少し応用します。
例えば
Aの回転以外 * Aの回転 * invAの回転 * Bの回転 （式２）
というような演算を考えます。
前回と違うのはAが回転ではない部分と回転の部分に分かれていることです。
そして逆行列によりAの回転のみを初期化してBの回転で置き換えています。
式２の方法により回転だけを更新できるのです。
MameBake3Dの数学の背景には式２のようなやりかたが多数使われています。
式２では回転に着目しましたが、初期行列や初期姿勢などに着目して式を作ることで
更に世界が広がります。
そんなことをして何の役に立つのかがピンとこない人がいるかもしれないので
書き方を変えてみます。
FBXのアニメーション情報はグローバル行列が基本です。
そしてボーンごとに初期行列があります。
ということは、グローバル行列からローカル行列を計算したとしても
「異なる初期行列」と「異なる初期姿勢」と「異なるボーン構造」 （３要因）
が立ちはだかって
モデル間でアニメーションを使いまわすことが難しいのです。
しかし、グローバル行列と言えども行列の掛け算の結果です。
式２の応用により３要因についての変換を行えば
異なるモデル間でもアニメーションを使いまわすことが可能なのです。
式２はそういう可能性を秘めた考えなのです。
さて前置きはこの程度にして
MameBake3Dのリターゲット（異なるモデル間でのアニメーション変換）において
実際にどのような計算をしているかを少しだけ説明します。
[初期仕様]
初期行列が異なるので回転と移動に分ける方法を採った。
移動は一番親の移動しか適用していない。
まずローカルの姿勢を求める。
localmat = worldmat * invparmat
座標系の変換をする。
curmat = invmodelinit * localmat * modelinit;
ここでmodelinitとは設定される側の現在のworldmatである。
curmatの回転成分rotmatを取り出して設定する。
curmp->GetWorldMat() * rotmat;// * tramat;
更に子供方向に向かってこの設定を再帰的に適用する。
[仕様修正その１]
最初のフレームのポーズと形状側の最初のポーズが同じであっても
最初のフレームにモーションが設定してある場合に、
上記の方法ではうまくいかなかったので方法を変更した。
姿勢をmodelの初期姿勢への演算としてあらわすことができれば解決すると考えた。
つまり、
bvhfirst0 * bvhanim * bvhpar = modelinit * bvhfirst0 * modelanim
の式におけるmodelanimを求めればよい。
modelanim = invbvhfirst0 * invmodelinit * (bvhfirst0 * bvhanim * bvhpar)
= invbvhfirst0 * invmodelinit * bvhmat
この式におけるmodelanimを求めた後、その回転を抽出してから
modelmat = modelmat0 * modelanim
を計算してモーションポイントにセットした。
最初のフレームのポーズと形状側の最初の見かけ上のポーズが同じであれば
最初のフレームにモーションが設定してあってもうまく変換できるようになった。
実際のコードでは
modelinitは初期状態のworldmatであり、bvhfirst0は初期状態のbvhmatであるから
modelmat = modelmat0 * invbvhmat0 * invmodelmat0 * bvhmat
ということである。
[仕様修正その２]
モデル全体が一回転するような場合などに足がクロスしたりしてうまくいかなかった。
コンバートのための行列にモデル全体の回転を考慮する必要があった。
bvhのHipsの各フレームのworldmatをbvhfirstmpmatとすると
modelmat = modelmat0 * invbvhfirsthipmat * invbvhmat0 * bvhfirsthipmat * invmodelmat0 * bvhmat
のようになった。
モデル全体が一回転しても初期姿勢のコンバートがうまくいくようになった。
という感じの数学的背景がMameBake3Dにはあります。
かなり説明をはしょりましたが
全てを説明するよりは読者の研究心や探求心を引き出したほうが良いと思いそうしました。
これらの仕様は実際にソースコードになってコンパイルすれば動く状態です。
動作確認もしています。
https://github.com/Ochakko/MameBake3D
ちょっと興味が湧きましたか？
君も化けちゃいなよ！
MameBake3Dにリグ機能が付いちゃいました[2016/06/02]
MameBake3Dの更新をしました。
遅ればせながらリグ機能というものを付けてみたら付いちゃいましたというお話。
動画を作りました。
こちらは設定方法と操作方法を１２分ほどにまとめた動画です。
【使い方説明】 MameBake3D 【Rig機能が付いちゃいました】
https://youtu.be/gkqCJNsUsKE
こちらは操作画面と操作例をダイジェストで３２秒の動画にしたものです。
MameBake3D CustomRig 動画。３２秒。
https://youtu.be/o7UUAqea6io
アニメーションツールにおけるリグとは
複数ボーンを一度に簡単に操作することが出来る仕組みのことです。
複数のボーンの回転の仕方を登録しておいてそれ用のGUIコントロールをドラッグすることで
ポーズを付けます。
MameBake3Dのリグの特徴は
マウスのUV方向（横と縦）それぞれにボーンの回転を設定することが出来る点と
ユーザが自分でGUIでリグの設定をすることが可能な点です。
１つのボーンに対して１０個のリグを自分で設定して登録することが出来ます。
MameBake3Dのリグの今後についてですが。
１、リグモードのオンオフをもっと簡素化したい、スムーズにしたいです。
（現状、大きめのダイアログの表示非表示で切り替えています。）
２、現在は１つのRigによって、親子関係のあるボーン５つに対する操作が出来ます。
手の指を開いたり閉じたりするためにはこれだけではできません。
１本１本の指のためのRig５つをまとめるようなRigの存在が必要になります。
つまり、RigのRigというかRigの連結というかそういう仕組みが必要になります。
最近はノードというやり方が流行っているようですので、リグノードなんてのもありかもしれません。
この辺の仕様を考えて実装したいです。
という感じです。
MameBake3Dの編集オプション[2016/04/24]
MameBake3Dの更新をしました。
もっといろいろ違うことを勉強しようと思っていたのですが
それってぶれてるっていうことかな？などと考えているうちに
気が付くとまた３Dプログラミングばかりしています。
どうしたものか、、、？
そして最近の成果を動画にしました。
「MameBake3D [編集オプションの説明]」動画。
https://youtu.be/cA7ceFJ2oLY
編集オプションの話です。
今までの編集方式ですと、複数フレームに対して、姿勢を決定するフレームの姿勢を適用していたので
複数フレームの間に体の向きが回転した場合に想定と異なる結果になっていました。
例えば、体が反対を向いていても姿勢決定フレームと同じ効果を適用したので
編集時に足を開かせても、体が反対を向いたときに足がクロスしていたのです。
この現象を名付けるとすれば、perfumeのCOSMIC EXPLORERのジャケ現象とでも言いましょうか。
そこで疑似的にローカル姿勢に変換して姿勢に適用するオプションを作りました。
PseudoLocal(疑似ローカル)オプションです。
日本語っぽく発音すると「スードローカル」です。
デフォルトでオンにしました。
姿勢を適用するボーンの親の姿勢を考慮して計算したので
体が回転したりしても編集時と近い見栄えの効果が出ます。
そんな感じのことを実演してみた動画です。
あ、あとはマウントステート（謎）についても言及しています。
まうんと すてーーーとぉーーー！！！
もう１つその前に作った動画も紹介しておきます。
「MameBake3D bvhそっと歩き＋物理ツインテ」動画。２０秒。
https://youtu.be/upwvM6yBGgw
こちらはbvhのモーションを取り込んでそれと物理シミュを組み合わせて再生したものです。
GitHubにアップしてあるファイルの中にtest12というサンプルがあるのですが
それを読み込んでF9を押したところです。
モーションスピードはスライダーでいじりました。
モーションスピードを速くしすぎると体が１８０度回るところでツインテールがプルプルするのですが
そういうときはスペースキーを押すとモーションを再生しながら物理がリセットされます。
こんな感じの経過です。
MameBake3Dの物理とRokDeBone2[2016/04/03]
MameBake3Dのデバッグが進んで、物理が扱いやすくなってきました。
かなり暴れやすかったというかデフォルトで暴れていたのを落ち着かせる設定をするのが手間だったのですが
現在はそれに比べると簡単に設定が出来るようになりました。
（とはいえ、やはり物理なのでパラメータが面倒ではあります。）
そんな感じでテストしてみた結果が以下の動画です。
https://youtu.be/7vLpVP0tEAA
だいぶまともになったと思います。
ソースはGitHubにpushしました。
https://github.com/Ochakko/MameBake3D
こうなってくるとbvhを適用したりするためのボーンの入ったFBXが必要になってきます。
そこでRokDeBone2の方のメンテナンスも再開しました。
RokDeBone2のbvhやFBXの修正をする予定です。
RokDeBone2もGitHubでオープンソースにしています。
https://github.com/Ochakko/RokDeBone2
RokDeBone2のサンプルを復活させたのですが
(著作権はちゃんと書いてあります)
サンプルをみていて涙がちょちょぎれました。
ああ、なんだかんだいっても、多くの人に支えられてきたのだなぁと、、、
ありがとうっ！！
追記 2016/04/03 pm8:30頃
RokDeBone2のFBX出力を改良してGitHubにpushしました。
ボーン構造の異なるFBXのモーションを適用する[2016/03/14]
おはようございます、就活中の化け猫おちゃっこです。
検索しているのですが、条件に合うところはちょっと遠い感じです。
ちょっと遠いくらいと思うかもしれませんが
日々のことになるので結構重要です。
近くの案件が出てくるまで遊んでいるのも何なので
MameBake3Dのバージョンアップをしました。
今回は
モデルのFBXにボーン構造の異なるFBXのモーションを適用する機能を付けました。
前回のbvhをFBXにする機能と組み合わせると
モデルのFBXに複数の異なるボーン構造のbvhモーションを適用できることになります。
特徴としては
ボーンの対応関係を設定するだけで良く、ボーンの位置調整をしなおさなくても良いところです。
変換方法にはちょっとこつがあるので
動画を作りました。
MameBake3D説明動画。モデルFBXにモーションFBXを適用する話。
https://youtu.be/ERaqn16GsU0
プログラムはオープンソースでの公開です。
https://github.com/Ochakko/MameBake3D
就活の習作の位置づけ[2016/02/21]
MameBake3DのVectorでの販売の取り下げ手続きをしました。
もうすぐページに反映されることでしょう。
perfumeのbvhを使用した時点で非商用縛りだったんだなぁ。
危うく売れるところでした。
今後のMameBake3Dなどのスタンスとしては
「就活のための習作」という感じにしようと思います。
GitHubにソースを公開していますが実行ファイルは含まれていません。
そんな習作ソフトでも興味があるという方は
info☆ochakkolab.moo.jp
(☆を@に変えてください)
までお問い合わせください。
隙間ツールとしてのMameBake3D[2016/02/17]
ここ数日、MameBake3Dのバージョンアップをしていました。
３Dツールと言えば、他にもたくさんあるし、すでに世間に認識されているものが多いです。
そこで、それらの隙間を狙ったツールとしてMameBake3Dを考えています。
どこが隙間かと言うと
ベイク済のFBXの編集関係に特化しようということです。
モーション作成というよりもモーション編集に重きを置きます。
物理関係の機能もあります。
ということで、bvhは読めてFBXに変換出来たほうが良いので
その機能を修正しました。
次に紹介する動画はMameBake3DでbvhをFBXに変換する方法です。
新規に作成した動画です。
[ MameBake3Dの使い方。BVHからFBXへの変換の話。]
オイラー角出力を抜本的に見直した結果、モーション再現率がかなり上昇しました。
perfumeの３人が踊る動画。
https://youtu.be/ONnB1jDVi6k
そしてもう１つの動画は、ベイク済のモーションの編集方法について解説しています。
この動画は過去に作った動画を復活させたものです。
[MameBake3Dの使い方。ベイクの話。]
ベイク済とは。ベイク済モーションの編集方法について。
https://youtu.be/Z0UacTlXs7w
だいたいイメージはつかめていただけましたでしょうか。
まだ物理の機能もあるのですが。
こんな感じのバージョンアップと動画作成などをしていました。
そこに正義はあるのかって？？
猫は隙間が好きでBakeますから、いいんですっ！！
2016/02/17 化け猫おちゃっこ
MameBake3Dを新しいメタセコに対応させました[2016/02/09]
いつの間にか、新しいメタセコイアのFBXをMameBake3Dが読めなくなっていたので
修正してアップしました。オープンソースです。
https://github.com/Ochakko/MameBake3D
メタセコイアでFBX出力をする前に面の三角化をしてください。
ボーンを入れ終わったらボーンのダイアログのポーズ出力メニューを実行してください。
FBX出力時のオプションは、スムージンググループをオフにし、バージョンは2013にしてください。
ソースのソリューションはVisualStudio2013で作成しました。
外部ライブラリの関係で、VCランタイムのバージョンは2010です。
久しぶりに半日 ３Dをやりました。
まだ３２ビットアプリのままです。
追記：2016/02/10
GitHubにアップしたソースが足りなかったことに気が付いて先ほどアップしなおしました。
何か赤い字が出ていたのですがcommitに-aをつけていれば大丈夫と思っていました。
ちゃんんとaddしてからcommitしました。
DX９０ｃ以外のファイル（ビルド用の）はそろっているはずです。
(実行するためにはFBXSDKをインストールして、DX90cのSDKを所定位置にコピーする必要はあります。
さらに、GLUT32.dllをexeと同じディレクトリに置きます。)
Wow64はエミュ扱い[2015/11/04]
Win64を少し調べました。
６４ビットＯＳで３２ビットアプリが動くのはWow64という３２ビットアプリを動かす仕組みがあるからです。
Wow64って名前に付いているディレクトリがあるのでこれは知っていました。
しかし、Wow64は６４ビットＯＳにおいて ３２ビットアプリを「エミュレーション」で動かすための仕組み
だったのです。
つまり、６４ビットＯＳにとって
３２ビットアプリはすでにネイティブとは言いがたく、エミュで動いている存在でした。
ショーーーーック！！
あんまり６４ビットに移行する気がしてなかったのですが
これを知って６４ビットに移行する気が出てきました。
だって、エミュだってよぉー。
やっぱりいくらか遅いんじゃないかしら？？
ということで
まだ調査は続きそうです。
とりあえず
６４ビットＯＳでもintやlongは３２ビットであり、ポインタやハンドルが６４ビットになる
ということが分かりました。
３２ビットから６４ビットに移行しやすいような配慮だそうです。
これなら設定しなおしてコンパイルし直すだけで良いものも結構ありそうです。
しかし、RokDeBone2は 確か ポインタをunsigned longにキャストしていた箇所が数か所あったような気がします。
まあ それは いいとして。
新しく作るものは６４ビットにしよう！！
Win64[2015/11/04]
Win32が使えなくなる日が来るのかは知りませんが
時代の流れとして６４ビット方向に進んでいるので
一応対応しようということで、Win64を調べます。
調べる前の印象としては
ものすごい大きなファイルやメモリを扱わないのであればWin32で良い気もするのですが。
ビッグデータが流行ですし
６４ビット化して実行速度が速くなれば もうけもん ってイメージ。
とりあえず調べ始めようと思います。
