| Unity3D, VRoid, モーキャプ編集ツール, fbx | おちっこLAB Since 2002 おちゃっこLAB Since 2006 おちゃっこLAB化け猫編バージョン２ Since 2013/12/21 おちゃっこLABメトード２編 Since 2021/09/23 |
Win日記[Windowsプログラミング日記]
前書き
おちゃっこのWindowsプログラミングの日記です。
勉強したこととか、作ったもののスクリーンショットとかのページにします。
新しい記事の方が上に来るように書いていきます。
今度こそ 完成度極大だ！[2023/03/11]
３月に入ってやっと暖かくなってきました
なんかもう調子に乗ってTシャツとパンツのときもあります
私は最近はあまり深く考えすぎないようにしていて とにかくどんどん作業をしておりました
その結果 人生の問題点置き去りのまま ツールの完成度がどんどん上がりましたｗｗ
数か月前に 完成度極大のおまとめ版宣言してリリースしましたが
予想もしていなかったような 怒涛の修正の日々により
今 やっと宣言通りの完成度極大バージョンが出来たような気がしています(気がしています)
何が変わったのかを メモに残したいと思います
文章で説明しながら動画を４つほど貼り付けます
まずは基本機能の動画
動画１：基本機能 モーキャプの動きを盛れ！
EditMotのIKは
元の動き全部を置き換えるのではなく 加算するアディショナルIK
アディショナルIKにより 元の動きを潰さないように 動きを盛ることが可能
絵でたとえると 元の動きの上にブラシで塗るイメージです
モーションを作成に挑戦したての頃は
ジョイントをドラッグしてIKしてみても 結果がイメージから悪い方にかけ離れていて幻滅したりしました
自分でIKしても 格好良い動きにしやすいツールを目標にしました
ぶっちゃけると 元のモーキャプが格好良ければ 無理をしなければ何をしても格好よくなります
そんなIKの説明を少し
IKによる姿勢編集について すごい簡単に印象を変えることが出来る例を動画にしたものです
ブラシ設定と２ドラッグだけで 動画のみえ方が変わりました
Unityのアニメーションカーブという言葉はきいたことがあると思います
EditMotでブラシと呼んでいるものは アニメーションカーブに似ています
違うところは ブラシは角度の値そのものではなく 編集効果の大小つまり重み(ウェイト)であるところ
編集効果の大小を 色の濃淡に例えて ブラシと呼んでいます
EditMotのブラシにはプラグインSDKもあって ユーザにより重み曲線を自由に定義可能
動画ではブラシの設定時に リピート回数３回 奇数回時にV方向反転 を指定しています
V方向に反転すると IK方向と反対向きに編集効果が現れます
動画では ２ドラッグするだけで 両腕を上げて 下げて 上げるという編集をしました
制限角度をオンにするためにLimitEulボタンも押しました
次に簡単そうで難しかったイメージに近い物理機能の動画
動画２：いろいろ直った物理でボクシングの動画
最初の頃は 物理計算の軸とモーションの軸が違っていて
相互の姿勢交換に変化分適用計算をしていました
その後１度軸合わせをして変化分計算のまま完成したような扱いでした
最近になって 試行錯誤の末に モーションの軸をMayaと同じ計算にすることが出来ました
そしてそれと同じ軸で物理計算することも出来て
更に 差分計算ではなく回転情報をそのままやり取りできるようになりました
それが一体何なんだ！？ということを動画にしたものです
いろいろ直った後の物理の動きは 以前よりも設定値の効果が反映されやすく イメージに近いものになりました
次は これがないとモーション付けが実質不可能とも言われている位置コンストレイント機能
指定ジョイントの位置を固定しながらＩＫする機能です
動画３：作り直した位置コンストレイント機能
作り直しました
一度は物理機能を使って位置コンストレイントをやってみたのですが
話題性がある一方で 不安定で困難でした
思い直して ＩＫ精度が上がった今なら 普通に数学で出来る気がしました
結構うまくいきました
動画４：変な風には曲がらない位置コンストレイント
位置コンストレイント機能は 角度制限との併用が必要でした
例えば手のひらの位置を固定して 腕を動かす場合を考えます
腕の形は Ｗ型にもなりえますし Ｍ型にもなり得ます
つまり 指定ジョイントの位置を固定するだけでは 姿勢は１通りには定まりません
Ｗ型とＭ型で 可能な姿勢ならまだ良いのですが 姿勢として不可能はポーズは みたくありません
そこで角度制限と位置コンストレイントは併用できる必要があります
併用が成功することによって 動画４のように動かすことが出来ました
EditMotの完成度が上がったことについて 動画４つで説明しました
EditMotのインストーラはVector様で配布していただいてます
現時点での最新版1.2.0.16は 2023/03/15夕方に配布開始予定
オープンソースの方は
GitHubのOchakkoのページのMameBake3Dというレポジトリで公開中
完成度が上がったEditMotを足掛かりに
山積みの人生の問題点も 好転するでしょ？(と思います)
2023年 今年もよろしくお願い申し上げます[2023/01/03]
今年もよろしくお願いします
何か日記を書いておこうということで
年末年始にみた夢の話と 1/2夜のバージョンアップについて書こうと思います
年末は こまごまとしてお手伝いをいつもよりたくさんしたように思います
もう箇条書きしちゃいます
１，換気扇
キッチン換気扇取り外し取り付け
風呂の換気扇フィルター洗浄
トイレ換気扇分解掃除機かけ
２，風呂の窓取り外し取り付け
３，キッチン窓取り外し取り付け
４，玄関ドア水拭き
５，玄関床水掃除
６，風呂カーテン注文取り付け
７，自分の部屋の掃除機かけ
８，トイレと脱衣所のカーテン取り付け
９，掃除機ゴミパック交換
１０，カレンダーゲット
１１，堀こたつ掃除
１２，天井下すす払い
１３，階段雑巾カラ拭き
１４，玄関にささやかなお飾り設置
１５，年に１度のテレビセッティングと紅白予約
結構しました！？
とアピールしておいてからの
大みそかの ”昼寝の話” に入ります
初夢というのは１月１日の夜とか明け方にみる夢のことらしいですが
私はよく大みそかの昼寝の時に 暗示めいた夢をみることが多いです
今年の昼寝のゆめはどんなだったか 書いてしまいましょう
技術を同じ会社の人に教える夢でした
教えるといっても 自分でもやったことがないことを教える夢
あーでもない こーでもない と試行錯誤の後に あっ出来た！
とそこに表示され浮かんできたキーワードは
”Contrinique”
実在しない単語ですが すぐに読めました
コントリニキュー
と読みます
コントリビュートでもなく こんがり鶏肉でもなく コントリニキューです
それでこの試行錯誤の成果を人に教えるのですが
やっと出来たという高めのテンションで
要するに！ contriniqueがね、、、
と説明します
相手は は？ と困惑
私は相手の持っている資料を覗き込み 原因把握
あれ？そっちの資料はコントリニキューになってない？
なんて書いてあります？
みると
〇〇〇 = o mg ... []
のようなスペース混じりのスクリプトっぽい 自分が普段使っているよりもモダンで高級言語っぽいものがみえます
そしてそれをみたとたん
はっと我に返り
コントリニキューってなんだっけ？
という夢でした。
いろいろな暗示が含まれていて 反省しどころだらけです
造語とかオリジナル性だとか高級言語への移行があまり進んでいないなど いろいろ問題だらけです
そんな感じの暗示の夢でした
夢の中でまでプログラミングだったのですが
EditMot1.1.0.10を
2022/12/31に完成させるために 結構しんどい作業をしまくりました
甲斐あって 2023/01/02の夜に オープンソース先行リリース出来ました！
（Vector様で公開させていただいているインストーラは2023/01/11夕方 公開予定）
2023/01/11夕方 公開予定1.0.0.35から1.1.0.10へと中位のメジャーバージョンアップしました
オイラー角の数値をMayaライクにするために 苦労しました
ほんともう試行錯誤の回数はもう分からないくらいです
でも出てきた結果が ３Ｄ業界の正義であるところのMayaというソフトと同じ数値というところが
反省を踏まえていて なかなか感慨深いものがあります
オイラー角をMayaライクにしてなにが良くなるかについて少しだけ説明しておきます
今までは+-180度の範囲内の角度でした
どういうことかと言いますと
+180度は+180度ですが +181度の場合は-179度という扱いでした
三角関数は３６０度角度が違うと同じ数値になるので 姿勢としては同じです
しかし オイラー角の変化として +180度が-179度へと変化する場合
その途中の姿勢の表示方法によっては 体全体が くるんと回ってしまうこともあります
Mayaライクなオイラー角の場合には
+181度はそのまま+181度であり +180度から+181度の変化の途中の角度も連続します
そのような改善効果があります
問題点というと
今回のバージョンアップにより制限角度設定を設定し直さなければならない点です
この問題に対しては
制限角度設定ダイアログのボタン１つで簡単に制限角度を設定可能にしておきました
そのボタンには
From All Retargeted Motionsと書いておきました
制限角度を設定したいモデルデータにいくつかモーションを読み込んでおいた状態で
From All Retargeted Motionsボタンを押します
読み込み済のモーションの可動範囲をスキャンして制限角度として設定します
つまり既に動くことが出来る範囲を動かすような設定がワンボタンで可能です
もう１つ書いちゃいます
今回のバージョンアップの目玉機能の１つに
回転操作時に移動成分も回転する というのがあります
どういうことかと言いますと
例えば
Hipsという名前のジョイントは通常 体全体の回転や移動を設定するためのジョイントです
そのHipsを回転しただけでは
体の向きと違う方向に移動してしまうのです
体の向きと移動の向きを合わせるためには 移動成分も回転します
実装方法は、、、
要するに TraAnim(トラあにむ)がね、、、
なんです
え？正夢？
ウサギ年だしー
ええいっ 正夢ついでに 説明してしまいましょう！！
行列計算はSRT形式つまり Scale(拡大) Rotation(回転) Translation(移動)の３要素で計算するのが流行っているようです
この方法でも良いのですが
Translationの部分が問題なんです
SRT方式の場合には アニメーションとしてTが設定されていない場合にも ジョイントの位置が数値として入ります
その結果 アニメーションだけに着目した計算編集がしにくいという問題があります
そこで自然発生的に出てくるのがTraAnimなんです！
私は昔ながらの行列計算が好きでして
PrevPivot Scale Rotation PostPivot TraAnim 式１
のように計算します
どういうことかと言いますと
式１のように表現して計算することにより
アニメーションとしての移動が設定されていない場合にはTraAnimは０になるのです
アニメーションだけに着目可能になります
話をもとに戻します
移動成分も回転するという話は つまり 移動のアニメーション分(TraAnim)を回転することです
具体的には
行列を SとRとTraAnimに分解する関数と
SとRとTraAnimから行列を組み立てる関数を作りました
そして回転部分だけを入れ替えたりすると望みのことが可能でした
詳しくは 動くものをオープンソースにしましたのでご覧ください
このような年末年始でした
何が言いたいかと言いますと
要するに 、、、
EditMot 1.0.0.34をコンフィデンスバージョンとしてリリース[2022/11/16]
EditMotの おまとめ版 出ました
ここまでの作業の成果のまとめという意味です
何が出来たのか？ まず何と言っても ブレなくなったIKが挙げられます
EditMot 1.0.0.34 公開
オープンソースも同時公開
(https://github.com/Ochakko/MameBake3D)
今までにもIKがブレなくなったバージョンはあったと思うのですが
fbxの読み込み方を変えたり いろいろ他の部分を変えることで いつのまにかブレていました
今回のバージョンは マニピュレータの軸を ボーン軸にオートフィットします そしてIK中にそれがねじれません
オートフィット(自動的 向き合わせ)は ボーン軸がバインドポーズに対して傾いていても 機能します
更に ０フレームにモーションが設定してあっても 機能します
今回の IKのブレの無さと 数式のシンプルさと 複数モデルでの検証結果は 本物っぽいです！
以前にも書いたことがあったとおもいますが
ブレないIKは RokDeBone2という作品が有りながらも 新しいソフト開発に踏み切った 大きな課題でした
やっとです ほんとに やっと
なぜ ブレないIKにこだわるかというと
IKをプログラミング制御に使用する場合に こうすればこうなるという 確かさが必要だからです
IK軸がブレたときにどういう不具合があったかと言いますと
ジョイントをドラッグするたびに IK軸が変化してしまい 操作の連続性を保つことが出来なかった不具合
軸がねじれると 曲げたい方向へ曲げることが難しくなる不具合 などがありました
上記の２つの不具合が解消されました
今回のリリースにあたり
チェックしている項目とチェックしていない項目が どうしてもあります
EditMotチェックリストに書いてある項目が EditMotの使いどころ
リリースの度にチェックリストは作ってきたのですが 1.0.0.33と1.0.0.34のチェックリストだけ 載せてみます
図１ 1.0.0.33のチェックリスト
図２ 1.0.0.34のチェックリスト
1.0.0.34のチェックリストはこの後 ２項目ほど修正して全てチェックが入りました
そのあたりが使いどころです
EditMot 1.0.0.34というまとめを出した後の予定ですが
メンテナンス中心の作業から 新しい技術の勉強中心へと 時間配分を変えていく予定です
それから お知らせとしては
YouTubeのチャンネルのハンドルというものを設定しました
https://www.youtube.com/@ochakkolab
上記アドレスから おちゃっこLABのソフトの使い方動画にアクセス可能です
動画ごとにたくさんアドレスを列挙しないでも 上記の覚えやすいアドレスで済むようになりました
まとめ版を作るまで 制作作業を続けてくることが出来たのは みなさんの応援のお陰です
どうもありがとうございます
これからも磁気が狂ったクジラにならないように(体調に気を付けながら)
活動をしていくことが出来れば良いなと思います
よろしくお願い申し上げます
RokDeBone2 6.0.0.0とEditMot 1.0.0.29のオープンソースについて[2022/10/02]
2022/09/29に約半年分の更新をGitHub( https://github.com/Ochakko )にpush
その更新の説明をしてみます
RokDeBone2もEditMot(MameBake3D)もプロジェクトファイルを統合してビルドしやすく
ソリューション１個をビルドするとプラグイン含め全部ビルド出来る
ただしDirectX SDKとFBX SDKは別途入手
#################
RokDeBone2について
#################
RokDeBone2は１つのオープンソースでForE3DとForUnityの両方をビルド可能になっています
違いはオイラー角の回転順序
ForE3D : オイラー角ZXY
ForUnity : オイラー角XYZの２種類
ForE3DとForUnityのビルド切り替えはver6.hの#define文を有効にするかコメントアウトするかによって切り替えます
ForE3Dで保存したファイルはForUnityで読めるが
ForUnityで保存したファイルはForE3Dでは読めない
プログラムのバージョンは
ForE3D : 5600
ForUnity : 6000
ForUnityはオイラー角を汎用性の高い順序ＸＹＺにすることにより
Unityで読み込んだ時のトラブルを減らしている
オカルト部部長の歩くモーションがなぜかUnityで傾く現象に気が付いていた人もいると思うが
オカルト部部長をUnityに持って行っても軸がぶれなくなった
##########################
EditMot(MameBake3D)について
##########################
EditMotのオープンソース名はMameBake3D
名前の履歴(最初のバージョンは2010年頃)
ChaFuBX(名前にFBXが入っているからざわつくに決まっていると言われた)-->
PiyoAnim(決めたときには同名ソフトは見つからなかったのだが決めてから改めて検索したら昔から同名ソフトがあったらしいので変更)-->
MameBake3D(今もオープンソースはこの名前)-->
MotionBrush(シェアウェアとして実行ファイル配布用の名前)-->
MotionBrushFree(インストーラ形式のフリーウェア化)-->
EditMot(商標トラブル事前回避のためにこの名前に改名 現在の名前)
プロ用のモーキャプライブラリRokokoのfbxを読み込み保存可能に
読み込み方改善によりリターゲットの式も修正
リターゲットの式は読み込み時の条件に依存するので読み込み変更により修正
リターゲットの条件はモデル側とモーション側の０フレームにおける見かけ上のポーズが同じこと
バンドポーズの無いfbx読み込みのオイラー角について
バインドポーズが無い場合には
ジョイント位置を推測計算することになる
その場合にバインドポーズと０フレームのアニメを明確に切り離して計算することは難しい
EditMotではシンプルに推測計算している
ローカルのオイラー角表現はバインドポーズ依存なので
推測計算の場合ローカル表現の仕方はいろいろあり得る
頂点に対して演算した時に変換後の頂点位置になるような表現になっているなら合っているという解釈
１８０度裏返り防止機能について
裏返り防止機能は複数回処理を行うと何もしないときよりも不安定になる
様々な機能がある中で自動で１回だけ処理するのが難しかった
ver1.0.0.29では１８０度裏返り防止機能をコメントアウトした
使った方が良いケースはあるので
将来のバージョンでToolWindowのボタン機能化する
バッチ処理のリターゲットでは起きたことが無かったが
ＧＵＩで１つずつリターゲットしたときに体が伸びたような結果(不具合)になることがあった
Hipsジョイントを名前で探す処理を付け加えることによりその不具合は起こらなくなったようだ
アンドゥリドゥ改良
１万フレームのモーキャプを読み込むとジョイントの選択変更に数秒間かかっていた
原因はジョイント選択時にアンドゥ処理用の自動保存をしているためだった
自動保存が悪かったのではなくてモーション全体を自動保存してるのが遅かったと解釈
パーシャル(部分的)アンドゥリドゥに改良
１万フレームモーキャプ読み込み時にも編集範囲が数十から数百ならレスポンスは快適
アンドゥリドゥ用のＧＵＩボタン表示
選択フレーム表示の改良
プレビュー時にフレーム選択表示が解除されたりアンドゥ時に選択が自動で戻らないことがあったのを修正
プレビューしても選択が外れなくなりアンドゥ時にも選択状態復元
マルチスレッド処理を改善
CThreadingBaseをベースクラスとして処理を共通化
CThreadingLoadFbxとCThreadingUpdateMatrixを派生
UpdateMatrixについては
メインウインドウのＧＵＩのhigh rpm(高回転)チェックボックスとThread numスライダー(１から４)に対応
スレッドの数はモデルごとの数
hight rpmのチェックを入れると速くなる
Thread numの最適な数は環境による
こちらで試したところ(core 8個)
Win10ではThread num 1のhigh rpmが一番速い
Win11ではThread num 4のhigh rpmが一番速い
描画速度はメインウインドウのテキストとしてfps : ***のように表示
fpsは１秒間の描画回数
(アニメーションとしては24fpsとか30fpsが最低でも必要と言われている。テレビモニタの周波数と同期するのが基本。
ひと昔前は60fps表示がもてはやされていた。最近は可変周波数同期が流行？)
マルチスレッド改善後に更にプレビュー高速化
こちらの環境で２０％の高速化に成功
１０％は計算範囲絞り込みによる計算量削減による
もう１０％はオイラーグラフの８００個の四角描画を４本のラインに変えたことによる
既知の問題点
リターゲットをバッチ処理で行うと
モーションの数分モデルが出来る
その状態でThead num 4のhigh rpmにすると
ＣＰＵのコア数に対するスレッド数が多すぎてマウスのレスポンスが悪くなった
スレッド数は全モデルに対して４つまでにするべき？
リリースしてからもテストをしていたのだが
アンドゥーが戻らないもしくは同じ状態がたくさん保存されているような状態になったことがあった
まだ原因を特定していないが
モデル削除やモーション削除と関係している可能性がある
調査修正の必要有
半年分の更新を振り返りました
不思議に思っている人がいるかもしれないので触れておきますが
モーション再生の高速化についてはGPUを使えば速くなるのは周知
モーキャプの場合にはモーションデータが大きくて全部をビデオメモリに置けないことがあるのでCPUのマルチスレッド計算にしています
これについては今後も同じ方針かどうかはわかりません
ちなみに私の開発マシンのメインメモリは１２８GB積んでいます(６４GBでは足りなかったことがあります) ビデオメモリ８GBです
追記 2022/10/06
EditMotは4Kテレビ接続時には
大きいウインドウで起動するか小さいウインドウで起動するかを選ぶダイアログが出ます。
fpsは環境依存の数値なんですが
大きいウインドウ(高解像度)にするほどfpsは小さな値になります
単純に考えても塗りつぶす画素数が増えると遅くなるので直感的にも納得することでしょう
大きなウインドウはウインドウサイズが縦横２倍で表示します
つまり塗りつぶす画素数は２ｘ２で４倍になるのでfpsもそれなりに小さな値になります
そのような状況だったので
マルチスレッド処理に手を入れて1.6倍高速化し
更に計算量削減などで1.2倍高速化しました
こちらの環境では大きいウインドウでも60fps出るようになりましたので
これ以上の高速化はあまり興味が無いようなあるような感じです
EditMotはモーキャプデータをfbxに変換してトリミングしてUnityへ持っていく部分が主な使い道
ぶっちゃけ個人的には見栄えはモーションを確認できる程度で良い
しかし動画やスクリーンショットでアピールする場合にその見栄えも影響するので
最近は手を入れていなかったシェーダーの勉強もしていく予定です
追記 2022/10/07
うれしいニュースです
MicorosoftのWindows11の22H2大型アップデートの後にまたアップデートが出ました。
アップデートにより
全てのCPUの稼働率を１００％にしてもマウスレスポンスは快適でした。
モデルごとのスレッド数管理のままでEditMotが上手く動きました。
ソフト名が変わったり配布形式がインストーラになったことについて[2022/09/30]
前回の日記から４か月も経ちました。
その間にいろいろありました。
説明が必要と思われる部分を少し。
MotionBrushというソフト名は商標トラブル事前回避のために
EditMotというソフト名に変わりました。
おちゃっこLAB内の古いソフト名をEditMotに置き換えたので
コンテンツの名前の不一致が一部生じています。
仕方ないです！
それからEditMotとRokDeBone2とuMotTreeEditorの配布形式が
インストーラ形式になりました。
プログラムがきちんとCドライブのProgram FilesのOchakkoLABフォルダに入るのが
気持ち良いです！
昔の日記に古いリンクが書いてるので
新しいリンクを書いておきます。
EditMot
モーキャプをトリミングしてFBX出力
https://www.vector.co.jp/soft/winnt/art/se524654.html
RokDeBone2_ForUnity 6.0.0.0
https://www.vector.co.jp/soft/winnt/art/se524614.html
uMotTreeEditor
Unityツリービューでモーション切り替え
https://www.vector.co.jp/soft/winnt/art/se524615.html
オープンソース
https://github.com/Ochakko
まずはシンプルに説明必要な変更についてのお知らせでした。
次回の日記は
EditMotのオープンソースの(こちらとしての)みどころなどについて触れたいと思います。
EditMotのオイラー角についてのメモ[2022/05/22]
約半年ぶりの日記です。
あの後MayaとUnityをいろいろいじって時間が経ちました。
Mayaをいじっていて分かったのですが
Mayaがすごい便利なのでEditMotとしての使いどころはすごい限られることが分かりました。
例えば姿勢の編集について
Mayaが便利なので
EditMotの姿勢編集機能はもうアップデートする必要もないと思いました。
それでもせっかくEditMotを作ったので使いどころを考えました。
EditMotとしてはモーションキャプチャファイルbvhを互換ファイルfbxに変換し
Humanoid互換モデルにリターゲットする部分が使いどころ。
そんなことを考えていると
EditMotの計算式ではうまくいかないモーキャプデータに遭遇しました。
XYZ軸の内の１つまたは複数が９０度またはー９０度をまたぐ場合に
オイラー角計算が乱れることが分かりました。
EditMotのオイラー角計算方法は
一般的な行列成分と三角関数による計算方法ではなく
クォータニオンステップバイステップ回転計算法(今、書きながら付けた名前)です。
オイラー角計算が間違っているとEditMotとしての使いどころが無くなってしまいます。
オリジナルの方法なんてやっぱり役に立たないのかぁと落胆の日々でした。
しかしある日突然頭が冴えてぴきぴきーんとオイラー角計算を直してしまったのです。
この直った計算方法でMayaの計算結果と比べたところ
９０度をまたぐようなモーションでも計算結果が一致しました。
さらにEditMotの方が１８０度裏返り対策も成されることが分かりました。
１０年位も開発してきたEditMotの面目を保つことがなんとか出来たと思います。
オイラー角修正版EditMot(実行ファイル)はVer1.0.0.24
2022/05/25(水)夕方に下記リンクにて公開予定です。
https://www.vector.co.jp/soft/winnt/art/se523002.html
(Mayaとは比べ物にならないくらいの些細なおもちゃですのであしからず)
オープンソースですので下記の場所にソースもあります。
MameBake3D (実行ファイルは付いていない)
https://github.com/Ochakko (2022/05/18 Updated !!)
今日の日記のここから先は思い付きの余談です。
一般的な行列成分と三角関数による計算方法とは異なる方法であるところの
クォータニオンステップバイステップ回転計算法に利点はあるのかどうかについて。
計算結果が同じであるのにわざわざ異なる方法にする意味があるのかについて。
本当に余談なんですが
３次元の回転におていはあまり利点は無いです。
あるとすれば、１軸ずつ回転する方が分かりやすい人がいるはずくらいのもの。
しかし４次元以上の回転を考える場合において
連立方程式を解くよりも１軸ずつ回転する方が分かりやすいのと
ジンバルロック対策が楽なことが利点になります。
では４次元以上の回転とは何なのか？
思い付きなんで聞き流してもらいたいのですが
4次元目は虚軸 i、虚軸と垂直な3つの実軸XYZがあるとします。
3次元の回転は回転平面で表すと
(YZ平面回転)(ZX平面回転)(XY平面回転)と表せます。
同様に4次元回転については
(YZ平面回転)(ZX平面回転)(XY平面回転)(i Y平面回転)(i Z平面回転)(i X平面回転)と表せます。
この連立方程式を解きつつ多数のジンバルロックの場合分けをするのは大変です。
しかしクォータニオンステップバイステップ回転計算法ならば
回転の種類が増えた分だけ線形にプログラムソースの量が増えるだけで済みます。
更に単純明快。
4次元回転はさらに発展する可能性があります。
虚軸iに対して垂直な虚軸が２つj, kがある場合です。
その場合は多分１５次元だと思います。
１５回回転した行列の連立方程式を解きたくはないです。
という感じで
無理やり利点を思ってみました。
１０年位も開発してきたEditMotの面目を保つことがなんとか出来たと思います。
オープンソースなので４次元以上で回転して利点があることを実感してください。
たわごととしての追記
４次元以上で回転することは物理的にはどういうことなのか？
X軸と呼んでいるものは実はXの実軸とXの虚軸から成る
それは数式的には
どちらかがcosX軸であり他方がsinX軸である
どちらが実でどちらが虚かについてはフーリエ変換を参考にすると
X軸については実軸がsinX軸であり虚軸がcosX軸となる
つまり物理的に４次元回転は可能である
１５次元と上で書いたことの補足
回転には回転平面があり回転平面は２つの軸で決まる
回転自由度として何次元になるかというと
sinX,sinY,sinZ,cosX,cosY,cosZ軸の６つの軸の中から２つの組を選ぶ場合の数は
6C2=(6*5)/(2*1)=15通り
よって１５次元であろう
１５次元の回転をジンバルロックを回避するためのデータ構造は１６元数であろうか？
回転いろいろ
更に追記
１５次元で回転計算をしても表示するときには３次元にしようね！！
も１つ追記
虚軸回転を３次元で表示するとどうなるかについて
推測としては
位相がずれた回転になるのではないだろうか？
電気で言うとコイルやコンデンサのような位相がずれた電流が流れる
それは物理で言うと何なのか？
ひょっとしたら慣性のことかもしれない？
そういえば
(当時のアニメに出てきていた)慣性装置を作ってくれと
中学生の時に友達から頼まれていたのを思い出した(笑)
追記〆
なんかいろいろ思いついてしまうときはときどきあるものです。
そんな思い付きメモが大半を占めてしまった今回の日記ですが
〆として
普通にMayaとUnityいじりに戻ります。
今回は難しいファイルを読むことで発覚した大きな不具合をオープンにしたまま放ってはおけなかった修正ということで。
いざ戻らんっ普通の社会へ！！
EditMotの物理ブラシについてのメモ[2021/12/09]
EditMotの物理ブラシの使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)
EditMot ver1.0.0.22では４つのブラシを追加した
４つのブラシの共通点としては
ボクシングのモーキャプデータのオイラーグラフを観察して
パンチの部分のグラフの形を近似した形のブラシにしたところです
モーキャプグラフの近似の際には
簡単な高校物理レベルの曲線で近似しました
教科書に載っていた放物線とか自由落下とか空気抵抗のあるときの運動とか
そんな感じのあの懐かしの数式です
観察して
だいたい４種類あるとおもいました
（アバウトな感じで）
新たに足した４つのブラシは
物理挙動の曲線を真似たものなので
物理ブラシと呼べるでしょう
では４つの物理ブラシを紹介します
図１：Punch_1ブラシ
図１にPunch_1ブラシで腕をIKした時のキャプチャを載せました
オイラーグラフの赤い線がX軸、緑の線がY軸、青い線がZ軸の回転量を示します
Punch_1ブラシは
パンチの出し始めと引っ込み始めの部分で速度があまり大きくなく
同じ方向への運動時間が長くなるほどスピードが速くなる物理ブラシです
図２：Punch_2ブラシ
図２に示すPunch_2ブラシは
パンチの出し始めと引っ込み始めに速度が速く
動きの方向が変わるまたは止まる前の速度が遅くなるような物理ブラシ
図３：X2Capブラシ
図３に示すX2Capブラシは
おなじみの放物線ブラシです
物を投げたときの近似曲線
運動の向きと反対側に同じ加速度つまり重力が掛かっているときの曲線のブラシ
図４：X2Needleブラシ
図４のX2Needleブラシは
パンチが当たる付近のパンチを出す側とパンチを引っ込める側の両方の速度が速いような物理ブラシ
４つ足しましたが
だいたい網羅出来たのではないかと思います（そんなアバウトなぁ！！）
ちなみに今回のテストは
まず肘を曲げた状態を作っておきました
そこから階層数に02を指定して手首ジョイントをマウスでドラッグしてテストしました
物理ブラシを選んでドラッグするだけで
好みの場所に好みの長さ好みの大きさの物理挙動を作ることが出来ます
え？パンチのグラフの形しか観察しなかったのかって？
物理パンチは世界を制するですよ？！
（物理ブラシのように舞い物理ブラシのように刺す！！）
EditMotのカスタムリグについてのメモ[2021/12/08]
EditMotのカスタムRigの使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)
まず大まかに説明
MationBrushのカスタムRigはユーザーが自由に作成と設定と実行を行うことが出来る
Rigへの入力としてはマウスの横方向と縦方向の移動量の２種類
この場合の横と縦の移動量というのは
カメラの位置や向きに関わらず常に目の前の画面に対しての横と縦
Rigの効果としては
２つの入力それぞれに対してXYZどれかの軸に関する回転
または
他のリグへ２つの入力を伝達すること
それぞれのリグに関して５つの出力先を指定可能
リグの所有ジョイントとそのジョイントから４階層親のボーンまでの
合計５階層のジョイントの回転制御をするいことが出来る
入力に対して正負の符号と倍率を指定することで
ひざが正の向きに1.5倍で真がっと時にはももが負の向きに1倍で曲がるなどの設定が出来る
Rigの操作は赤青緑の球をマウスでドラッグすることで行う
リグのマークを横と縦の移動量に気を付けながらドラッグするだけで
設定した向きと角度倍率でポーズを作ることが出来る
概略としてはこんなところ
では実際の画面をみてみる
図１：RigボタンとRigモード
図１はRigボタンを押したときのRigモードの画面
Rigボタンは画面の向かって右側のサッカーのキックをしているマークのボタン
押すたびにオンとオフが切り替わる
リグモードにすると作成済のリグが全て表示されて操作可能になる
リグマークはXYZ軸の色をしている
色と表示位置は指定可能
リグマークの大きさは指先に表示しても邪魔にならない位を基準にしている
操作するときにはカメラを人物に寄せて大きくみることを想定している
サンプルには手の甲の部分に３つのリグ、指の先端に１つずつのリグが設定されている
手の甲の赤い球をドラッグすると手のひらを閉じたり開いたりする
指先の球をドラッグすると指を曲げたり伸ばしたりする
１つ１つのジョイントをドラッグしなくても
球をドラッグするだけで開いたり閉じたり出来るところがリグを使う理由だと思う
明るさ的にリグマークがみえにくい場合には
BasicSettings1の一番上のスライダーでライティングを暗くする
モデルデータが暗くなることでリグマークの明るさが目立ちみやすくなる
図２：リグの作成メニューと設定メニュー
リグの作成と設定は３Dウインドウでジョイントを右クリックするか
あるいは図２のようにツリービューの項目を右クリックしてメニューを出して行う
メニューの下の方に
CreateNewRigとあるのがリグの作成メニュー
その下には作成済のリグの名前（自分で決める）が作成してある分だけ表示される
メニューの作成済のリグの名前にマウスを当てると
SettingOfRigメニューがある
これがリグの設定メニューである
図３：リグ設定ダイアログ
リグ設定メニューを選択すると
サイドウインドウにリグ設定ダイアログが出る
自分を入れて５階層までのボーンツリー
もしくは
５つのリグに対して
マウスの横と縦に対する回転軸と角度倍率と有効無効を設定する
ボーンを指定したいときには
ボーンorRigのコンボボックスでRegularBoneを選ぶ
そうすることにより
自動的にリグの所有ジョイントから５階層上までのジョイントに対する設定になる
表示場所（軸）、表示場所（番目）、マイナス位置の設定項目は
リグのマークを表示する位置についての設定
軸はXYZ選べてそれぞれの色
番目は０から３までで数字が大きいほど原点から離れて表示される
０番目は１つしか設定しない（なぜならXYZとも０番目は同じ位置だから重なってしまう）
マイナス一は軸のどちら側に表示するかの設定
図４：RigからRigを呼び出す
図３ではマウスの移動量に対応するのはボーンという設定だった
カスタムリグではリグからリグへとマウス移動量を伝達することが可能
リグからリグを呼び出す場合には
図４のように
ボーンorRigの項目の場所にリグの名前を指定する
指定する際にはコンボボックスに作成済のリグの候補が全て表示されるのでそこから選択すれば良い
ボーンorRigの項目に表示されるリグの名前としては
所有ジョイント名の後ろに自分で付けたリグの名前が連結されているような文字列で表示される
図４では手の甲のリグから指先のリグを５つ呼び出している
BasicSettings2のLimitEulチェックボックスにチェックを入れておけば
リグの操作時にも制限角度が効く
例えばTestフォルダに入れてあるサンプルでは
指が反る方向には曲がらないようにしてある
こんな風に軸と符号と倍率だけで使い物になるのかどうか心配かもしれないが
割と便利だと思う
設定していて気が付いたこととしては
足を前に出すときのリグと足を後ろに蹴るときのリグは別々に設定した方が良いということ
リグからリグは何階層呼び出せるかについてだが
リグから呼び出されたリグから呼び出されたリグから呼び出されたリグから呼び出されたリグから呼び出された
リグから呼び出されたリグから呼び出されたリグから呼び出されたリグから呼び出されたリグを実行可能である
EditMotのアンドゥとリドゥについてのメモ[2021/12/06]
EditMotのアンドゥとリドゥの使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)
まずは用語の説明
アンドゥ(Undo)とは保存してある操作履歴の中の昔の状態を復元すること
アンドゥをどのように実装しているかというと
２００回分の操作を保存できるメモリに操作をするたびに操作結果を保存していきます
アンドゥ機能が呼び出されるたびに過去の方向に向かって操作結果を復元します
リドゥ(Redo)というのは過去の時点を指しているメモリ位置から未来方向に向かって操作結果を読み取って復元すること
２００回分しか保存できませんが一番最後に達した場合は一番最初に戻ります
一番最初に達した場合は一番最後のメモリを指すようにします
このようなメモリの使い方をリングバッファと言います（大体の意味です。リングバッファの正確な意味を知りたい場合にはきちんとしたサイトで調べなおしてください）
それではUndoとRedoの仕方をメモします
図１：IK操作をしました
まずテストとしてIK操作をしました（図１）
図２：Ctrl + ZでUndo
キーボードのCtrlキーを押しながらZキーを押すとUndoします
図２が図１の状態からUndoした後の画面です
ver10022ではフレーム選択状態が復元されませんでした。
2022/01/19公開予定の10023では
アンドゥーリドゥでフレーム選択状態も復元されます。
UndoすることによりIK操作前の状態に戻りました
次にこの状態からRedoしてみます
図５：RedoすることによりUndoで取り消した操作が画面上に復元された
RedoするにはCtrlキーとShiftキーを押しながらZキーを押します
RedoすることによりUndoで取り消したIK操作が復元されました。
フレーム選択範囲の復元はUndoのときと同様に行いました
まとめ
Ctrl + Z --> IK操作のUndo
Ctrl ＋ Shift + Z --> IK操作のRedo
２重Vマークボタン--> フレーム選択のUndo
２重の屋根マークボタン--> フレーム選択のRedo
S+マウスホイール--> タイムライン時間表示範囲シフト
仏の顔も３度まで
Undo Redoは２００回まで！！
EditMotの制限角度の設定と制限角度下でのIKについてのメモ[2021/12/05]
EditMotのコピー制限角度の使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)
今回のメモは2021/12/08夕方公開予定のEditMot 1.0.0.22(2nd Completed Version)についてのメモです
図１：起動直後のスイッチ連続投入の図
EditMotを起動したら
私はいつもスプライトプレートスイッチをひとつずつ全部押してGUIを表示します
演出としてはコクピットに乗ったパイロットがスイッチを素早くオンにしていって
起動音がきゅうぃーーんと鳴るあの感じです
嘘です
今回は制限角度についてのメモです
図２：制限角度ダイアログを出す
GUIのカエルボタンを押してLimitEulプレートをクリックして制限角度ダイアログを出します
図３：モーションが制限角度で制限されている様子
制限角度ダイアログの見方を説明します
一番上にはどのジョイントの制限角度なのかがわかるようにジョイント名が書かれています
マウスでクリックしたジョイントの１つ親のジョイント名が書かれています
なぜかというと設定しながらIK(子供ジョイントをドラッグして親ジョイントを中心に回転する)する場合に
わかりやすいからです
制限角度ダイアログにはスライダーが９つあります
X軸Y軸Z軸にかんしてそれぞれ３つずつの合計９個です
３つの内訳は
制限角度の下限値スライダー、制限角度の上限値スライダー、現在のフレームにおける現在の値
の３つです
この３つがXYZそれぞれにあります
制限角度が効いているので
現在値の値は下限値と上限値とで囲まれた範囲内しか動きません
その状態をオイラーグラフで見ると制限の範囲外がカットされている部分はそれ以上変化できずに平らに見えます
図４：制限角度を掛けない場合のオイラーグラフの確認
制限角度はオンオフ出来ます
図４に示すようにGUIのLimitEulチェックボックスのチェックを外すと制限角度はオフになります
制限角度がオフの場合のオイラー角は
制限の範囲外にも動けるので制限で平らになっていた部分もカーブに見えます
図５：制限角度下でのIK操作
制限角度はモーション再生時だけでなくIK操作時にも効きます
デフォルト状態では
GUIのWallScrapingIK(壁すりIK)がオンになっています
壁すりIKとはIK操作中にXYZどれかの軸が制限値に達しても
制限値に達していない軸がマウスドラッグに近い姿勢になるように動きます
この際にも可動範囲内だけを動きます
壁すりIKをオフにすると
XYZ軸のどれか１つの軸でも制限値に達すると
いくらマウスをドラッグしてもうんともすんとも動かなくなってしまいます
可動範囲内だけを動かしたいのだから
壁すりIKをオフにして１つの軸でも違反したら動かなくて良いと思うこともあります
私も最初はそう思いました
しかし
多数のモーションを読み込んでテストした結果
IK操作開始時点の姿勢が既に制限角度の外にある状態の場合
すでに制限角度違反している状態なので
WallScrapingIKをオフにしていると
マウスをどちらに動かしても度の軸を動かそうとしても動かなかないことが多かったのです
壁すりIK(WallScrapingIK)をオンにしておくことで
制限角度下においても可動範囲内をIK操作可能です
図６：モーションの制限角度をベイクして保存
保存に関してですが
普通にプロジェクトを保存すれば制限角度ファイルも保存されます
fbxのモーションとして制限角度が掛かった状態の動きを保存したい場合には
プロジェクト保存時に制限角度をベイクするにチェックします
次に制限角度の設定が簡単になったのでその説明をします
図７：制限角度設定前の初期化
制限角度を設定する前にまったく動かないように制限角度を０度に初期化します
制限角度ダイアログのReset 0ボタンを押すと全てのボーンの制限角度が０度になります
図８：現在のモーションの可動範囲を制限角度として設定
次に制限角度ダイアログのFormCurrentMotionボタンを押します
このボタンを押すと
読み込み済で現在選択中のモーションの全フレームのオイラー角の最小値と最大値を検索して
それを制限角度として設定します
ワンボタンで出来てしまいます
１つのモーションの可動範囲だけでは汎用的な制限角度にはなりにくいです
モーションを選びなおしてからFromCurrentMotionボタンを押すと
現在設定されているよりも大きく動いた分が制限角度として更新設定されます
モーキャプデータを読み込んでFromCurrentMotionボタンを押してそれを制限角度として設定することで
実際の動きからリアルな制限角度設定が可能です
手の制限角度について
モーションキャプチャデータには手の指のキャプチャデータは入っていないことがあります
その場合には自分で手をパーからグーにするモーションを作りFromCurrentMotionボタンを押します
リアルな制限とリアルな動き
変な風に動かしたくないという長年のストレスの原因がかなり解消されました
EditMot 1.0.0.22は1.0.0.7に続き2nd Completed Version(２度目の完成版)です
もっとバージョンアップしたらもっと良くなるよ！？
もう、いいっ！！(Vuぅーーん、バリバリバリっ)
EditMotのコピー履歴機能の使い方メモ[2021/12/03]
EditMotのコピー履歴機能の使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)
図１：モーションのコピー
モーションのコピーは複数フレームをマウスドラッグで選択してToolWindowのコピーボタンを押します。
するとコピー情報入力ダイアログが出ます。
このダイアログの項目に設定をしなくてもコピー自体は出来ます。
ダイアログの項目に設定をしてメモを書いておくことにより
コピー履歴一覧にそれらの情報が表示されるので検索しやすくなります。
設定項目による検索機能があるからです。
図２：コピー履歴選択ボタン
ToolWindowのコピー履歴選択ボタンを押します。
右側のサイドウインドウにコピー履歴選択ダイアログが表示されます。
最初の状態では
ダイアログの最新のコピーを選択するチェックボックスにチェックが入っています。
このチェックが入っているときには
過去をさかのぼってコピー結果を選択することは出来ませんが
自動的に常に最新のコピー結果をペースト時に使用します。
コピー履歴はWindow(OS)指定のTempフォルダの中に保存されていきます。
自分でファイルを消さない限り履歴は蓄積されます。
図３：最新のコピーを選択チェックを外す
コピー履歴選択ダイアログの最新のコピーを選択チェックを外します。
グレーになっていたダイアログ上部がみえるようになります。
項目として表示されているものの中にコピー時に設定した項目やメモがありますので
それを目印に探します。
図４：コピー履歴検索
コピー履歴選択ダイアログの上２段には履歴検索のためのコントロールがあります。
一番上の段には
fbxファイル名、モーション名、bvh typeがあります。
指定は必須ではありません。
二段目には検索開始日時と検索終了日時の指定項目があります。
コピーした時の日時の範囲を指定できます。
検索実行ボタンを押すと条件に合う履歴だけが表示されます。
条件を変えて検索を繰り返す場合
履歴全体からの検索になります。
複数回検索による絞り込み検索ではないです。
履歴項目の右側のdeleteボタンを押すと
Tempフォルダの中の該当する履歴ファイルが削除されます。
履歴の中からペーストに使用したいコピー結果を選択したら
OKボタンを押し忘れるとペーストしようとしてもペースト出来ません。
OKボタンを押さなくても選択がペーストに反映されます。
図５：コマンド対象ボーンボタン
次にすぐにペーストしても良いのですが
ペースト対象とするボーンを選択する手順も説明します。
コピー操作は全ボーンに付いてコピーが行われて保存されます。
部分的なコピペはペースト時に対象ボーンを選びます。
ペースト対象ボーンの選択をすることにより
体の一部分だけの動きのコピーペーストが可能です。
図５では上から２番目のボーン以下を対象として選択しています。
このとき一番上のボーンの動きはペーストされません。
一番上のボーンには体全体の移動と回転と拡大縮小の動きが入っています。
体全体のモーションをペーストせずに残りの全てのモーションをペーストすることにより
体全体が同じ位置同じ向きのまま動きをペースト可能です。
指定方法は
左側のツリーから項目を選んで右側のペーストするボーンの選択の追加ボタンを押すか
または
右側のペーストしないボーンの選択の追加ボタンを押します。
追加された項目とその子供全てが対象となります。
図６：ペースト実行
ペーストしたいフレーム範囲をマウスドラッグで選択し
ToolWindowのペーストボタンを押します。
体全体の位置と向きはそのままでコピー結果の動きがペーストされました。
手順としてはこんなところです。
意味合いとして
複数モーションとしてのモーションライブラリがある一方で
コピー履歴としてのモーションライブラリもあるという感じです。
bvh typeは1から144まで指定可能ですので
好きに分類できます。
重要度の指定もあります。
メモも書くことが出来ます。
メモが一番区別しやすい情報だと思いますので後でわかりやすいように利用します。
コピー結果が自分で消さない限り蓄積されて部分的にも使用出来る。
モーションライブラリとしての利用可能性は無限大？？？
無限の可能性のモーションライブラリの分類方法を構築してみてはいかがでしょうか？
たかがコピペされどコピペ
Unity上でVRoidのvrmにbvhモーションキャプチャを適用する手順[2021/11/14]
今回は複数ソフト間の連携の手順の日記です
まずは主要リンク先を提示します
Unity3D(3D統合ソフト) https://unity3d.com/jp/get-unity/download
VRoid Studio(キャラクター作成ソフト) https://vroid.com/
UniVRM(Unity用vrmインポーターパッケージ) https://github.com/vrm-c/UniVRM/releases
カーネギーメロン大学モーキャプ(bvh) https://sites.google.com/a/cgspeed.com/cgspeed/motion-capture
EditMot(モーキャプデータコピペ編集ツール) https://www.vector.co.jp/soft/winnt/art/se523002.html
EditMotOSS版MameBake3Dのプログラムソース(実行ファイル無し) https://github.com/Ochakko
手順通りに変換設定したUnity上のvrmの動画
https://twitter.com/ochakkolab/status/1459615015875473411?s=20
では手順説明です。
図１：VRoidでキャラクターモデル作成してエクスポート
かわいいキャラクターをすぐに作れるVRoidが正式版になったそうなので試してみました。
ライセンスとしては作成したモデルをUnity上でゲームに使用しても良いそうです。
図１はVRoidで作成したキャラクターです。
この日記のページの都合上画像ファイルが小さくて圧縮表示で残念ですが実際もっとすごいかわいいです。
今回の日記はVRoid正式版のvrmファイルをUnity上で表示して
モーションキャプチャファイルbvhの動きをさせる手順を書きます。
図１に示すようにキャラクターが完成したらVRMエクスポートメニューを実行。
次にモーションキャプチャファイルfbxにしてUnityに持っていく準備をします。
EditMotというソフトを使います。
https://www.vector.co.jp/soft/winnt/art/se523002.html
図２：bvhフォルダ
図２のようにモーションキャプチャファイルbvhを１つのフォルダに入れます。
モーションキャプチャファイルはカーネギーメロン大学のMotionBuilder Friendlyタイプを推奨。
モーキャプデータには回転の順序だけでなく座標系がいろいろ異なるものがあるので
適切な種類を選ぶことが重要。
retarget.rtgというファイルはEditMotというソフトのTestフォルダの中に入っています。
retarget.rtgファイルをbvhファイルと同じフォルダにコピペします。
図３：bvh2FBX batchメニュー実行
EditMotを立ち上げてFile-->bvh2FBX batchメニューを実行。
図４：bvh2FBX batchでbvhフォルダーを指定
bvh2FBX batchメニューを実行してbvhが入ったフォルダの場所を指定します。
図４はbvhフォルダ指定画面です。
図５：bvh2FBX batchの結果
bvh2FBX batchが成功すると図５のようにbvhフォルダの中にfbxファイルが生成されます。
次にUnityへ複数モーション入りのfbxを持っていく準備として
１つの形状fbxにbvh2FBXで作成した複数のfbxモーションをリターゲットします。
図６：MotonBrushでサンプルプロジェクトを読み込む
EditMotのFile-->Openメニューを時こうして
EditMotのTestフォルダの中にあるサンプルプロジェクトを開きます。
図７：EditMotのTestフォルダのプロジェクトを読み込んだところ
図８：サンプルプロジェクトの形状にbvh2FBXで作成したFBXのモーションをバッチでリターゲット
File-->Retarget batchメニューを実行して
サンプルプロジェクトの形状にbvh2FBXで作成したFBXのモーションをバッチでリターゲットします。
少し時間が掛かりますがプログレスバーが出ますので気長に終了を待ってください。
図９：モデルパネル表示
Retarget batch終了後にはサンプル形状にモーションが適用されています。
この際モーション用のモデルデータも作成されます。
モーション用のfbxのモデルは重くなる原因ですので削除します。
削除するにはFile-->モデルパネルメニューを実行してモデルパネルを表示し
不要モデルの横のdeleteボタンを押します。
図１０：不要モデルを削除した後のモデルパネル
図１１：モーションパネル
モデルを削除して動作を軽くしたところで
リターゲットしたモーションの確認をします。
モーションの確認をしてどのモーションを使うかを決めます。
図１２：モーションパネルでモーションを選択して再生してチェック選択
モーションパネルでモーションを選択した後
オイラーグラフ（画面下の横長ウインドウ）の上部のボタンの内、三角の形のプレイボタンを押します。
プレイボタンを押してモーションをチェックします。
カメラ操作用のスプライトボタンは３DウインドウのSpriteFKと書いてあるプレートをクリックして出します。
図１３：ToolWIndowのプロパティボタンでモーションに名前を付ける
使用するモーションを決めたら
そのモーションに名前を付けます。
ToolWindowのプロパティボタンでプロパティダイアログを出して名前を設定。
図１４：プロジェクト保存
File-->Save-->Projectでプロジェクトを保存します。
図１５：プロジェクト名設定
プロジェクト保存時にはプロジェクト名を変えることを推奨します。
名前を変えない場合は既存のプロジェクトが上書きされます。
図１６：Unity3Dでプロジェクト作成
さていよいよ本題のUnityで動かすための説明です。
Unity3Dのプロジェクトを作成します。
3D Coreタイプを選択して適当なプロジェクト名を付けてCreate projectボタンで作成。
図１７：モーションリターゲット済のfbxとテクスチャをUnityのAssetにドラッグアンドドロップ
モーションリターゲット済のfbxとテクスチャをUnityのAssetにドラッグアンドドロップします。
リターゲット済のfbxはEditMotで作成したプロジェクトフォルダの中のモデル名のフォルダの中にあります。
図１８：fbxのRigをHumanoidに設定
fbxをドラッグアンドドロップしたら
Assetの中にfbxのアイコンが出来ます。
再生マークが付いているfbxのアイコンをクリック。
右側のInspectorウインドウのRigタブをクリック。
RigのタイプとしてHumanoidを指定してApplyボタン。
これでfbxのボーン情報がUnityの標準形式へと変換されました。
図１９：fbxのAnimation設定
図１８のRigタブのtなりにあるAnimationタブをクリック。
今回はプログラミング無しでの説明なのでモーションは１つにします。
モーション名のあるウインドウで必要ないモーションを - ボタンを押して削除。
LoopTimeにチェック。
CycleOffsetに１（後で再生速度倍率を設定すると自動で大きい数値になる）。
Root Transform Rotation-->Original
Root Transform Position Y --> Feet
Root Transform Positon XZ --> Original
Motion--> Root Motion Node --> <None>
Applyボタンを押す。
ここで大事なのはRoot Motion Nodeを<None>のままにするところ。
fbx自体を表示に使用する場合にはRootNode-->Hip_Jointを指定するのですが
vrmのモーションとして使用する場合には<None>にしておかないと体全体の回転の中心がずれます。
2022/01/10追記
UnityEditorのアップデートにより
<None>以外にも自動処理の選択肢が追加されています。
それでもうまくいかないばあいは
InspectorでVRM側の全体移動ジョイントの位置を
fbx側の全体移動の位置と同じになるように数値入力するとうまくいきます。
図２０:Asset内にAnimator Controllerを作成
Asset内で右クリックしてCreate-->Animator Controllerメニューを実行して
Animator Controllerを作成。
図２１：Animator Controllerの設定
作成したAnimator Controllerのアイコンをクリック。
画面上のAnimatorタブをクリック。
fbxをEntryボタンの辺りにドラッグアンドドロップ。
モーション名のラベルが付いたオレンジ色のボタンが作成される。
図２２：モーションスピードの設定
オレンジ色のボタンをクリック。
Speedに５を指定。
次はVRoidで作成した表示用のvrmをインポートします。
図２３：Asset内でImport Package
図２４：UniVRM
vrmをUnityにインポートするには
UniVRMというパッケージを使いますのであらかじめダウンロードしておきます（図２４）。
先ほどと同じモデルデータのあるAsset内で右クリック。
Import Package-->Custom Packageメニューを実行しUniVRMをインポート。
UniVRMというパッケージをインポートしてvrmをインポート可能になりました。
図２５：VRoidでエクスポートしたvrmをUnityにインポート
VRoidでエクスポートしたvrmをAsset内にドラッグアンドドロップ。
vrmのキャラクターの絵が付いたアイコンがAsset内に出来ます。
図２６：メニューからvrmをHierarchyに追加
vrmをUnityのHierarchyに追加します。
この際にドラッグアンドドロップではなくVRM0-->MeshIntegratorメニューを使います。
図２７：HierarychyのMainCameraの設定
ここまでの手順で
vrmがゲーム用のオブジェクトとして登録されましたが
このままではカメラがキャラクターの後ろ姿を映しています。
Hierarchyのメインカメラをクリックして設定（図２７）。
Rotation Y --> 180
Position Z --> (+)5.5
図２８：vrmのAnimation Controller指定
Hierarchyのvrmの項目をクリック。
InspactorのAnimator-->ControllerにAsset内に作成したAnimator Controllerを指定。
図２９：Game画面でvrmモーション再生
ゲームタブを押してから三角の再生ボタンを押すと
vrmがbvhから作成したfbxのモーションを再生します。
髪の毛も揺れます！！
動画をツイッターにアップしました。
https://twitter.com/ochakkolab/status/1459615015875473411?s=20
こんなことがGUI操作だけでプログラミング無しで出来てしまうなんて
UnityもVRoidもすごい！！
「説明がつくっ、説明がつくぞっっ！！（憑りつかれた研究者風に）」[2021/10/10]
EditMotはver1.0.0.7で完成したのですが
初期のころのモーションキャプチャ結果のbvhを扱う場合に
姿勢が裏返ることがある不具合が発覚し修正に苦労しました
MameBake3Dデベロップ版としてオープンソースで試行錯誤しながら開発しました
やっと結果が落ち着いて更に説明もつくようになったのでメモとして残します
(EditMot ver1.0.0.15としてのリリースは１，２週間後になる予定です)
裏返る現象を図１と図２であらわします
図１：意図した姿勢（裏返っていない）
図２：意図しない姿勢（裏返っている）
肘の姿勢を例にとって説明します
肘の姿勢を計算するときには図１に示すオレンジ色の折れ線
つまり[肩から肘の線]と[肘から手首への線]の曲がり具合から計算します
このとき図１が意図した姿勢だとして
オレンジ色の折れ線情報だけで計算すると図２の意図しない姿勢が計算結果になることがあります
図１の折れ線も図２の折れ線も同じようにみえるので答えが２通り出てくるのです
これがbvh裏返りの症状の原因でした
そこで対策しました
一般的な３Dソフトにおいてはオレンジ色の折れ線情報に加えて
オレンジ色の折れ線に垂直なベクトルUpVec(アップベクトル)の計算を加えて正しい姿勢にします
MameBake3DとEditMotにおいては
メトード研究開発練習が目的なので
計算方法を編み出すことになりました
（オイラー角に関しては
２０１０年ころに協力者（謎の猫様？）が残したものを大いに参考にして続きを開発してきました）
さてその方法とは
図１と図２の姿勢の内
１回前（時間的に１フレーム前）の姿勢におけるオイラー角に近い方を選ぶという方法です。
その際に図２の姿勢を図１の姿勢に正すためのオイラー角の表現について試行錯誤しました
骨の軸をX軸とすると図１と図２ではX軸に関して裏返るほどねじっています
X軸に関して１８０度ねじっていることはすぐにわかります
長い間それだけで判定していました
しかし図１では肘を直角から伸ばす方向に曲げているのに対し
図２では肘を伸ばした状態から曲がる方向に曲げています
このときの回転軸をY軸とすると
図１ではY軸に関して６０度曲げたとき
図２ではY軸に関してー６０度曲げています
実際の姿勢の違いを体を使って確認してやっと正解と思われるオイラー角補正がわかりました
骨の軸に関しては１８０度違い
その他の２つの軸に関しては両方とも符号違いの回転になります
このことを考える際に陥った間違えとしては
回転結果の座標軸との成す角度だけから答えを導こうとする間違いがありました
今回求めているのはX,Y,Zの順番で回転するオイラー角を求めているのです
回転が座標系からみて何度かではなくて軸の周りに何度回すかというのを求めているのです
そんな間違いを何度も何度もして１８０ーY度のはずだなどと試行錯誤してはがっかりしていました
これらのことを踏まえると
式で表すと骨の軸がXのときオイラー角は
図１：X度、Y度、Z度
のとき
図２：X+180度、ーY度、ーZ度
となります
骨の軸はY軸の場合もZ軸の場合もあります
これらの中で１回前のオイラー角に一番近いものを選べば
正しい姿勢が得られることがMameBake3Dデベロップ版にて検証できました
研究成果として
行列とUpVecを使用したオイラー角計算の別解（クォータニオンと前回比較を使用したオイラー角計算）
がやっと出来ました
https://github.com/Ochakko
（MameBake3DのChaVecCalc.h, ChaVecCalc.cppにあります）
この成果をEditMotにマージして
EditMot ver1.0.0.15のリリースへと準備中です
EditMotはVector様のサイトにて配布予定です
（現在１つ前のバージョンver1.0.0.14公開中）
https://www.vector.co.jp/soft/winnt/art/se523002.html
次こそ完成版だと思います
（だよねぇー）
2021/10/14追記
180度裏返り対策付きのver1.0.0.15は2021/10/20夕方 Vector様のサイト(上記)にて公開予定です
１８０度裏返り対策について実際の効果を示さないと説得力に欠けると思うので補足説明します
モーションキャプチャ技術は昔よりも今の方が手法や精度などが改善されています
ですが昔のキャプチャデータも膨大であり精度が悪いデータも使いたくなります
精度が悪いデータにおいて足が１８０度近く上がったときなどに１８０度裏返りは起こりやすいです
昔のデータを扱うときに
１８０度裏返りが起こってしまったときの説明をします
図３にver1.0.0.14つまり１８０裏返り対策無しのモーキャプデータのオイラーグラフを示します
赤色がX軸回転、緑色がY軸回転、青色がZ軸回転です
XYZの順番でそれぞれの角度だけ回転することになります
図３：１８０度裏返り対策無しのオイラーグラフ
オイラー角はそれぞれ１８０度急に値が飛んでいたり急に符号が反転しているのがわかります
図４にver1.0..15つまり１８０度裏返り対策有りのオイラーグラフを示します
図４：１８０度裏返り対策有りのオイラーグラフ
図４についても
古い手法のモーキャプデータなのでオイラーグラフに段々状になっていますが
対策により元の動き本筋の動きがわかるようなグラフに完全しました
図４のオイラーグラフになる前にもう一段階ありました
オイラー角の計算のたびに裏返り対策計算をしてしました
そのときにはせっかく直したオイラーオイラーグラフが多重回裏返ってしまいました
多重回裏返るとIK操作(マウスでジョイントをドラッグして姿勢を編集する操作)の開始時に
瞬時に姿勢が裏返ったりしました
そこで１８０度裏返り対策はモーキャプデータbvhをfbxファイルに変換する際にだけ実行しました
そのようにしたところIK操作時に姿勢が急に反転することもなくなりました
さてそれでは次の段階
裏返ってはいませんがグラフが段々状になっています
段々状のオイラーグラフのモーション再生すると
少しの間変化が無く急に少しカクッと動くのを繰り返します
これに対しても解決策はあります
図５と図６をみてください
図５：段差が起きているフレーム（横軸時間）の前後のフレームをマウスドラッグで選択
図６：ツールウインドウの補間ボタンを押して補間を行い段差を無くす
図５で段差の１つを選んで段差の前と後ろを含むように複数フレーム選択します
図６でツールウインドウの補間ボタンを押します
補間ボタンを押すと複数フレーム選択の一番最初のフレームと一番最後のフレームの姿勢はそのままで
その間のフレームの姿勢を最初と最後の間で滑らかに変化するように計算して設定します
他の段差についても補間するべきところは補間操作します
このようにして段々状のオイラーグラフ対策をすると
モーションが滑らかになります
古いモーキャプデータも使える可能性が高くなるバージョン
それが2021/10/20夕方公開予定のEditMot ver1.0.0.15です
ちなみに
こちらとしては
１８０度裏返り対策を実装しましたが
誰かの手のひら返しが無くなる保証はありません
EditMot(エディットモット)を使って確かめたいことがある[2021/07/18]
EditMotはver1.0.0.7で完成したのですが
リターゲットバッチ処理（一括処理）機能があまりにも落ちやすいということで
修正版を出すことにしました。
落ちないことと処理中にGUIがキラキラしてきれいなところはトレードオフだったのですが
真面目にやれということで、キラキラしなくなりますが落ちなくなりました。
７月２６日（月）朝にEditMot ver1.0.0.8が出ました！！。
配布アドレスは以下です。（投げ銭はカートに入れるボタンからお願いします）
https://www.vector.co.jp/soft/winnt/art/se523002.html
EditMotにはたくさんの機能が付いていますが
モーションキャプチャデータの部分的コピペを一推し（いちおし）していることには理由があります。
某所で２５００個のモーションキャプチャデータが手に入ります。手に入りました。
手付けモーションのプロでもない人がかっこいいあるいは面白いダンスモーションを作るためには！！
という問いの応えの一つとして
2500個の実際の動きを部分的にコピペすれば踊ることが出来る
という仮説を立てました。
EditMotのミッションとして上記仮説を確かめるのです。
2500個のキャプチャデータをfbxファイルにして更にゆりちゃんデータ（同梱している赤ジャージの子）にリターゲットするには
膨大な（おおげさに言うと）変換処理待ち時間が必要。
さらに全モーションを再生して確認してプルプルしている部分などを滑らかに修正するにはかなりの手間が必要。
しかし、それをやることはゆりちゃん用のモーションライブラリが出来るようなもの。
コピペして踊らせるのです。
モーションライブラリが本当にモーションライブラリならコピペして踊るはずなのです。
いや、踊りたいのです！！
ということで
作業は地味を極めますが出来れば楽しいものです。
知っていますでしょうか？
ラジオ体操の意味を。
NHKの見解によりますとラジオ体操をしても体力増進にはなりません。
体力増進にはなりませんが命の危機を救う可能性があるそうです。
というのは転びにくくなるそうです。
なぜ転びにくくなるのか？
普段したことのない態勢になったときに転びやすいそうです。
普段したことの無い変な姿勢の体操をたくさんしておくとそれを体だか脳だかが覚えていて
いざというときのその姿勢から通常の姿勢への補間計算を行って転ばずに復帰するそうです。
そういう意味でラジオ体操すると転びにくくなり命の危機を救うのです。
あ、ラジオ体操の宣伝ではありません。
何が言いたいかというと
２５００個の実際の動きをコピペして補間することにより踊ることも可能という仮説の論拠を示したのです。
つまり動きとは覚えている動きの補間計算なのですという論拠。
そんな面倒なことをなぜするのか？
みなさん驚く方もいるかもしれませんが
実を言うとぼくも踊りたかったんですｗｗｗ
（確かめさせてください）
ちなみにぼくがコンピュータのことを好きな理由は
自分の代わりに動いている絵を描いてくれるところです。
EditMot(エディットモット)シェアウェア版としても完成[2021/07/07]
EditMot(エディットモット)はシェアウェアとしても完成しました。
特色は
モーションキャプチャデータの部分的コピペしてFBXファイル化
次のアドレスはまとめの動画のアドレスです。
動画【モーションツール】ver1.0.0.7完成版のいいところ【完成しますた】
https://youtu.be/nApvd9___mQ
エピソードっぽくまとめの感想も書かせていただきました。
上記のまとめ動画の中の技術的な部分の抜粋を日記として書いてみます。
まずモーションツールとしては
モーションキャプチャデータを使うものが格段に見栄えするということ。
ということは
モーションツールに求められているのは
モーションキャプチャデータの部分的コピーペーストであるという仮定。
その仮定に基づいてEditMot(エディットモット)はver1.0.0.7でシェアウェアとしても完成。
画面的にどうなのかスクリーンショットを載せます。
図１，図２、図３は
EditMotに同梱しているEditMotC4.exeにより
２つのEditMot.exeを２つ縦に並べて立ち上げたところ。
EditMotは複数起動して一方から他方へとモーションのコピーペーストが可能。
図１：下のEditMotは腕を元気良く振るが少ししか歩かない。
上のEditMotはくるっと一周り歩くが腕をほとんど振らない。
下のEditMotのモーションをコピー。
図２：上のMotionBrushのツールの操作対象ボーン設定ボタンを押して
腕のモーションだけをペーストするように指定。
図３：上のEditMotで複数フレームを選択してツールのペーストボタンを押してペースト。
図１から図３の説明を読むとおわかりのように
モーションキャプチャデータの
任意のフレーム範囲の任意のボーンのモーションを
任意のフレーム範囲にコピーペースト可能。
動画ではお見せしませんでしたが
コピーペーストにより
つなぎ目部分が不連続になった場合には
ツールの補間ボタンを使います。
補間ボタンの使い方を説明します。
不連続の始まりのフレームと不連続の終わりのフレームを両端に含むように複数フレームを選択。
ツールの補間ボタンを押す。
不連続の始まりと終わりの間を補間して滑らかに変化させます。
次に
コピーペーストだけでは足りないことがあります。
そのための編集機能も付いています。
これについては以前から動画や日記にしているように
複数フレームとブラシとブラシのパラメータを選んで
ジョイントをマウスでドラッグする方式の編集。
図４，図５，図６は
おちゃっこLABのEditMotのページ置いてある追加ブラシのアップデータを使用した様子。
図４：UpLinearブラシ、リピート２、ミラーU。線形。
図５：UpX^2ブラシ、リピート２，ミラーU。放物線。
図６：UpCosブラシ、リピート２、ミラーU。三角関数。
図４，５，６で使ったブラシは
機械的な線形の動作、放物線、三角関数のブラシ。
動きは冒頭で紹介した動画をみてください。
ジョイントのドラッグ操作に失敗したり気に入らなかった場合には
Ctrlキーを押しながらzキーを押すとアンドゥ（操作の取り消し）が出来ます。
ShiftキーとCtrlキーを押しながらzキーを押すとリドゥ（取り消した操作の再実行）が出来ます。
アンドゥリドゥ用のバッファはリングバッファです。
こんな感じの機能が
私が思う完成形のモーションツールの編集機能。
みなさんに見守っていただけたから完成できたと思っています。
どうもありがとうございました。
以下にリンクを示す。
Vector様のサイトでシェアウェアとして公開中
2021/07/07 ver1.0.0.7 完成版リリース
https://www.vector.co.jp/soft/winnt/art/se523002.html
2021/07/11
EditMotPluginsSDK Updata 002
TopPosスライダーを０にしたときの重みが間違っていたのを修正
(本体と一緒にご使用ください)
アップデータ002 ブラシ修正 EditMot ver1.0.0.7用
動画【モーションツール】ver1.0.0.7完成版のいいところ【完成しますた】
https://youtu.be/nApvd9___mQ
おちゃっこLABのEditMotのページ
EditMot(エディットモット)とBrush(ブラシ)の関係[2021/06/25]
モーションブラシってどこがブラシなの？
という疑問に対して説明しました。
以下のリンクのpdfに簡単にですが書きました。
MotionBrush_ExplainGraphOfBrushes.pdf へのリンク
Vector様に登録されました。[2021/05/29]
みなさんの応援のお陰で
OSSとしてのMameBake3Dは完成し
開発継続のためにソフト名をEditMotに変えて
Vector様のところでシェアウェアとして公開中です
ありがとうございます
Vector様のシステムは
ダウンロードと課金が別ボタンになっていますので
まずは気軽にダウンロードして動くかどうかチェックしてから
課金するかどうかを決めることが出来ます
EditMotのVector様でのアドレスは以下です
https://www.vector.co.jp/soft/winnt/art/se523002.html
修正したテストデータは本サイトに置いてあります
EditMot1.0.0.1用のアップデータ001
現在のEditMotのバージョンはver1.0.0.1で
ver1.0.0.2への差し替えを申請中
ver1.0.0.2には上記のアップデータ001が同梱されています
バグの修正もあります
EditMotを気に入ってくださった方や
将来性に期待された方などおりましたら
投げ銭感覚で
カートに入れるボタンを押していただけると
開発継続の可能性がアップします
前回の日記においては
４KTVが必須のような印象でしたが
EditMotというソフトとしては
横２K縦１Kの解像度があれば画面内におさまります
ですので機種によっては１３インチのモバイルでも動作可能です
メインのツイッターアカウントは
@ochakkolab
です
モーションブラシ用のアカウントを作りました
@Brush0Ch
です
ありがとうございます。MameBake3D完成しました。[2021/05/13]
令和３年（2021年）５月１３日（木）大安 午後０時０８分 MameBake3Dは完成！！
（本サイトのMameBake3Dのページ）
トップページでも告知しましたがMameBake3D(まめばけ３D)完成しました。
Microsoft DirectX11対応
物理ライブラリbullet physics対応
ゲームパッド(Sony DualSence)対応
FBXファイル入出力
ベイク済フルフレームモーション対応
bvhファイルをFBXにする機能
リターゲット機能
全ボーン自動剛体作成設定機能搭載
物理パラメータ設定
30fpsでも破綻しないように設定できる物理シミュレーション
複数フレーム変化分編集
モーションブラシ機能
IK搭載
物理IK搭載
物理シミュレーションと物理IKのベイク
３Dモーションに必要と思われる数式を研究開発テストしてOSS化
( https://github.com/Ochakko )
MameBake3Dのgithubへの最初のコミットは
2014年6月22日
完成まで約７年間
ありがとうございました。
おかげさまで完成しました。
思えば２０１０年頃
不特定多数にゲーム作成ライブラリを配布していた頃
物理に大きなバグがある指摘を受けながらも
そんなことはないと配布を続けてしまい怒られたのであった
オープンソースにしてからその大きなバグはみつかって修正した
このオープンソースの７年間は
こちらとしては
３Dモーションのブラックボックスに対する信用問題だったのだろう
と今ならわかる気がする
あくまでも
こちらとしては
である
３Dモーションに関わる計算式を
研究開発しながら説明し信用問題に対応した
と解釈
みなさんにみまもっていただいたから出来たこと
本当にありがとうございます
説明済の数式が一式揃ったところで
これから生活の足しとなるような
シェアウェア作成に取り掛かります
(の足し)というのが重要
以前は３Dソフト販売だけで生活しようという高すぎる目標を持っていた
せっかく貴重なお小遣いを使ってくださった人に対してまで
これでは足りない生活できない
というような不満の態度を示してしまった
(生活)の足しを意識することで
みなさんからの善意に気が付くことが出来ました
ありがとうございました
今後ともよろしくお願いいたします
次のシェアウェアは４KTV対応ならではのソフトにする予定
こんなのを考えている段階
図１ 次のソフトの案その１
図１の案としては
親玉ソフト内部から
MameBake3D相当のソフトを４つ起動して並べて
４つのソフトの内の２つを選んで選択フレームから選択フレームへと
モーションの編集を可能にしたい
というもの
４つ起動して負荷はどうなのかをみたのが図２
図２ ４つ立ち上げて４つとも物理シミュレーションを動かしたときのマシンへの負荷
物理を４つも立ち上げると
CPUは１０％から２５％くらい
GPUは１０％から４０％くらい
の負荷だった
なんとかなりそうである
経過はこの日記で報告していきます
足しも積もれば山となる！！
ぱっちりチリ足！！
追記
MameBake3DのライセンスはLGPLです
ライセンスはそのままです。変更しません。
市販のソフトによくあるように
このソフトについて
とか
オープンソースについて
などのメニューを追加して
そこにライセンスがLGPLであることと
お問い合わせ先のメールアドレスを記述する予定
市販ソフトのよくあるパターンを真似することにします。
物理IKと物理シミュ結果をベイクしてFBXファイルに[2021/05/02]
物理IKと物理シミュレーション結果をモーションにベイクしてFBXファイルに保存できるようになりました。
物理IKのベイクについては前回の日記で書きました
もう少し絵や動画を載せておこうと思います
まずは物理IKのベイクの動画です
動画１：【物理IK】MameBake3Dの物理IKが保存可能に【位置コンストレイント】
https://youtu.be/EOqRf35o7u8
絵も載せておきます
図１ 位置コンストレイントしたいジョイントにMass0 ON to LowerJointsを実行
前回の日記で
ドラッグ中に形が崩れないようにしたい場合には
右クリックメニューからKinematic On To LowerJointsを実行しました
位置コンストレイントをしたい場合
つまり
ドラッグ中に位置を固定したいジョイントに対しては
図１のようにジョイントを右クリックして出てくるメニューから
Mass0 ON to LowerJointsを実行します。
物理IKには回転（PhysRot）と移動（PhysMv）を用意しましたが
位置コンストレイントと相性が良い操作は移動（PhysMV）の方です
動画１でもPhysMvStartボタンを押してからジョイントをドラッグしています
物理IKの移動の際の絵を２つほど載せます
図２ 物理IK移動の前の様子 胸の分岐のジョイントをドラッグする準備
図２では図１の方法で両方の手首にMass0を設定した後、胸の分岐のジョイントを選択しています
この姿勢から
PhysMvStartボタンを押し
胸の分岐ジョイントを横にドラッグすると図３のようになります
図３ 物理IK移動後の様子 両手首には位置コンストレイントを設定済
ドラッグして
図３のようになりました
両手首の位置を動かさずに体を少し横に移動することが出来ました
自転車のハンドルを握りながら体を動かす場合などに応用可能
次に物理IK回転の図も載せます
図４ 物理IK回転前の様子 肘ジョイントをドラッグする準備
図５ 物理IK回転後の様子
図４が物理IK回転前で
図５が物理IK開店後です
PhysRotStartボタンを押してから肘ジョイントを上に少しドラッグしました
思ったよりも
普通に曲がりました
物理IKはドラッグしたジョイントから周囲のジョイントに力が伝わり
周囲のジョイントからフィードバックが変えてくるのですが
図４図５のように
無理なく少しドラッグする分には
普通に曲がることが多いです
物理的に動かすのに明らかに大きな力が必要な場所を
強引にドラッグしたりすると
急に大きく曲がりすぎたりすることもあります
ドラッグに失敗したり
結果が気に入らなかった場合には
Ctrlを押しながらZキーでアンドゥします（操作を取り消して操作前の姿勢に戻します）
物理IK回転と物理IK移動は
複数フレームを選択してから行います
ドラッグすると複数フレームに効果がベイクされます
複数フレームに対してどのようにベイクされるかについては前回の日記に書いてあります
今日はもう１つ動画があります
動画２ ： 動画【物理シミュのベイク】MameBake3Dで物理をベイク【フレーム範囲指定OK】
https://youtu.be/E-w6tpksu4I
動画２は
物理シミュレーション結果もモーションにベイクできるようになった様子を動画にしたものです
物理IKはジョイントドラッグ操作です
物理シミュレーションと呼んでいるのは
モーションに合わせてツインテールが揺れたりするシミュレーションのことです
図６ 物理シミュレーションのベイク BT RECボタン
図６は物理シミュレーションをベイクする際のスクリーンショットです
BT Startボタンは物理シミュレーションを再生するだけです
複数フレームを選択してから
BT Startの１つ下のボタン
BT RECボタンを押すと
指定範囲の物理シミュレーションを再生しながらそれを記録します
再生終了後に少し画面が固まって
指定フレーム範囲に物理シミュレーションがベイクされます
動画ではそのあと
プロジェクトファイルを保存してから読み込みなおして
物理シミュレーションが保存されたことを確認しました
プロジェクトファイルを保存する際にFBXファイルも保存されています
Maya2020で読み込んでも物理シミュレーションがベイクされていることを確認しました
物理IKや物理シミュレーションは
使用するコンピュータの処理速度などによって
まったく同じには再生されないことが多いです
処理が重い環境だと
物理が暴れてしまうこともあります
物理をベイクしてFBXにすることで
そのような
使用するコンピュータの違いでモーションが違ってしまう現象が
緩和されると思います
MameBake3Dの物理IKを再び有効にしてみました[2021/04/26]
物理IKとは
6DOFスプリング剛体を全てのボーンの位置と向きに合わせて自動的に作成し
数学でドラッグして物理で伝達とフィードバックをもらう形式のインバースキネマティクスのこと
物理ライブラリにはbullet physics ver2を使用し、
物理の力の伝達とフィードバックをもらう部分に利用している
物理IKのベースとなる部分は
数年前には出来ていた
しかし、きれいな結果を得るためには
物理IK中に60fpsくらいで処理できる環境が必要だった
当時の開発マシンでは限界が来て
何年か寝かしていた
数年前のゲーミングＰＣくらいのスペックで大丈夫だと思う
比較的きれいな結果が出るようになったので
解説記事を書いてみることにした
絵の中に解説を書いたのでみていただきたい
絵は縮小配置しているが元の絵は割と大きいので
絵をクリックして大きくすると字が読めると思う
図１ Kinematicをオンにして指の動きが破綻しないようにする
手順準備
手首のジョイントを右クリックしてメニューを出し
KinematicON to LowerJointsを実行
これをしておかないと
指の動きが破綻しやすい
図２ 物理IK実行の手順
手順１
複数フレームを選択
開始位置をマウスでクリック
終了位置までマウスボタンを押したままドラッグ
手順２
３DウインドウのTopPosというスライダーを動かして
編集効果のピークの位置を設定
手順３
物理IKを開始するため
（通常のIKと区別するために）
PhysRotStartボタンを押す
物理IKはドラッグ単位
ドラッグ開始の前に毎回PhysRotStartボタンを押す
手順４
ジョイントをマウスでドラッグ
ドラッグ中に経過時間と編集内容が記録される（最大約３０秒間）
結果を取り消したい場合は
ドラッグ終了後にCtrl + Zでアンドゥ
図３ 物理IKの結果の説明
ジョイントドラッグが終わると編集内容が結果に反映される
ドラッグ内容には時間と姿勢が記録されている
開始フレームからピークフレームまでは
ドラッグ開始からドラッグ終了までの編集内容が時間が増える方向で適用される
ピークフレームから選択終了フレームまでは
ドラッグ終了からドラッグ開始までの編集内容が時間が減る方向で適用される
物理IKの特徴として
ドラッグ内容が周りのジョイントに影響し
周りのジョイントからドラッグジョイントへも影響があるという点
微妙に体が傾いたり
微妙に腰がくねったりするような物理IKならではの効果がある
物理IKでは
回転禁止設定や制限角度や
Mass0による位置コンストレイントなどが可能
ゲームコントローラ対応の設計開発テストデバッグを趣味でやるとこんな感じ[2021/04/17]
ツール作り作業を一人でするということは
仕事で例えると
設計、開発、テスト、デバッグ、リリースを一人でする感じ
それを趣味でやるときの様子はどういうものか
ちょっとだけおみせします
ゲームパッドはSonyのPlayStation5用のゲームコントローラーDualSenceを使用
DualSenceの写真を載せます
テレビリモコンは別売りwww
さて
まずは設計書のようなもの
画像をクリックすると大きく表示されて文字が読めます
仕事でやるときには
OfficeのWordというアプリを使ってきちんと仕様書を書くけれど
趣味の時はこのくらいのテキトーさ加減
開発していくにつれて問題点が発覚することが多い
設計書を赤ペンでどんどん修正していく
赤ペン入れを含めて設計なのかもしれない
開発結果は以下のアドレスに置いてある
オープンソース
https://github.com/Ochakko/MameBake3D
そして
テストとデバッグのときのメモ
テストとデバッグについても
仕事でやるときには
バグトラッキングシステムででチケットを発行して
１つのチケットに付き１つの作業のようにして解決していく。
趣味の場合は
上の２枚のメモのように
問題点とチェックマークのメモ程度を残す感じ
こんなことをやって
何が分かったかというと
自発的にやっているから出来るようなものの
仕事で自分の思うことと違う作業でこれをやれと言わるなら
それなりに対価をもらわないと
ストレスで落ちるっ！！！
ということが分かった
ゲームコントローラー対応という経験が出来て良かった
次からはコンバットブローブンだっ
ゲームコントローラーでツールの操作性は向上するかどうかについての研究 [2021/04/14]
ゲームをゲームコントローラーでプレイすることは当たり前のこと
では
ツール（今回はモーション編集ツール）をゲームコントローラーで操作することにより
マウスやキーボードでの操作よりも操作性は向上するかどうか
について研究を行った
とりあえず報告してみる
今回は
ツイッターで報告したものを貼り付ける
（ ツイッター画面のスクリーンショットの都合上
繰り返し画像になっている文章もある ）
まとめると
マウスカーソルの瞬間移動とマウスカーソル位置の瞬間復元が出来る点で
ゲームコントローラーによる操作性向上はある
またゲームコントローラーの方が使用していて疲れにくいという利点もある。
しかし
マウスやキーボードが必要なくなるわけではなく
マウスやキーボードは必要
まめばけ３D(MameBake3D)というソフトにおいて研究を行っている
参考までにその操作方法も示す
まめばけ３Dはオープンソースで開発中の３Ｄモーションツールである
以下のアドレスにて公開および更新中
オープンソース
https://github.com/Ochakko/MameBake3D
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で良い気もするのですが。
ビッグデータが流行ですし
６４ビット化して実行速度が速くなれば もうけもん ってイメージ。
とりあえず調べ始めようと思います。
