本文へスキップ


                                     Unity3D, VRoid, モーキャプ編集ツール, fbx おちっこLAB Since 2002 おちゃっこLAB Since 2006
おちゃっこLAB化け猫編バージョン2 Since 2013/12/21
おちゃっこLABメトード2編 Since 2021/09/23

Win日記[Windowsプログラミング日記]



前書き

おちゃっこのWindowsプログラミングの日記です。
勉強したこととか、作ったもののスクリーンショットとかのページにします。

新しい記事の方が上に来るように書いていきます。







今度こそ 完成度極大だ![2023/03/11]


3月に入ってやっと暖かくなってきました
なんかもう調子に乗ってTシャツとパンツのときもあります
私は最近はあまり深く考えすぎないようにしていて とにかくどんどん作業をしておりました
その結果 人生の問題点置き去りのまま ツールの完成度がどんどん上がりましたww
数か月前に 完成度極大のおまとめ版宣言してリリースしましたが
予想もしていなかったような 怒涛の修正の日々により 
今 やっと宣言通りの完成度極大バージョンが出来たような気がしています(気がしています)
何が変わったのかを メモに残したいと思います

文章で説明しながら動画を4つほど貼り付けます

まずは基本機能の動画

動画1:基本機能 モーキャプの動きを盛れ!


EditMotのIKは
元の動き全部を置き換えるのではなく 加算する
アディショナルIK
アディショナルIKにより 元の動きを潰さないように 動きを盛ることが可能

絵でたとえると 
元の動きの上にブラシで塗るイメージです
モーションを作成に挑戦したての頃は 
ジョイントをドラッグしてIKしてみても 結果がイメージから悪い方にかけ離れていて幻滅したりしました
自分でIKしても 格好良い動きにしやすいツールを目標にしました
ぶっちゃけると 
元のモーキャプが格好良ければ 無理をしなければ何をしても格好よくなります
そんなIKの説明を少し

IKによる姿勢編集について すごい簡単に印象を変えることが出来る例を動画にしたものです
ブラシ設定と2ドラッグだけで 動画のみえ方が変わりました
Unityのアニメーションカーブという言葉はきいたことがあると思います
EditMotでブラシと呼んでいるものは アニメーションカーブに似ています
違うところは ブラシは角度の値そのものではなく 編集効果の大小つまり重み(ウェイト)であるところ
編集効果の大小を 色の濃淡に例えて ブラシと呼んでいます
EditMotの
ブラシにはプラグインSDKもあって ユーザにより重み曲線を自由に定義可能
動画ではブラシの設定時に リピート回数3回 奇数回時にV方向反転 を指定しています
V方向に反転すると IK方向と反対向きに編集効果が現れます
動画では 2ドラッグするだけで 両腕を上げて 下げて 上げるという編集をしました
制限角度をオンにするためにLimitEulボタンも押しました



次に簡単そうで難しかったイメージに近い物理機能の動画

動画2:いろいろ直った物理でボクシングの動画


最初の頃は 物理計算の軸とモーションの軸が違っていて
相互の姿勢交換に変化分適用計算をしていました
その後1度軸合わせをして変化分計算のまま完成したような扱いでした
最近になって 試行錯誤の末に モーションの軸をMayaと同じ計算にすることが出来ました
そしてそれと同じ軸で物理計算することも出来て
更に 差分計算ではなく回転情報をそのままやり取りできるようになりました
それが一体何なんだ!?ということを動画にしたものです
いろいろ直った後の物理の動きは 以前よりも設定値の効果が反映されやすく イメージに近いものになりました



次は これがないとモーション付けが実質不可能とも言われている位置コンストレイント機能
指定ジョイントの位置を固定しながらIKする機能です

動画3:作り直した位置コンストレイント機能


作り直しました
一度は物理機能を使って位置コンストレイントをやってみたのですが
話題性がある一方で 不安定で困難でした
思い直して IK精度が上がった今なら 
普通に数学で出来る気がしました
結構うまくいきました


動画4:変な風には曲がらない位置コンストレイント


位置コンストレイント機能は 角度制限との併用が必要でした
例えば手のひらの位置を固定して 腕を動かす場合を考えます
腕の形は W型にもなりえますし M型にもなり得ます
つまり 指定ジョイントの位置を固定するだけでは 姿勢は1通りには定まりません
W型とM型で 可能な姿勢ならまだ良いのですが 
姿勢として不可能はポーズは みたくありません
そこで角度制限と位置コンストレイントは併用できる必要があります
併用が成功することによって 動画4のように動かすことが出来ました


EditMotの完成度が上がったことについて 動画4つで説明しました
EditMotのインストーラはVector様で配布していただいてます
現時点での最新版
1.2.0.16は 2023/03/15夕方に配布開始予定
Vector様で ダウンロード


オープンソースの方は
GitHubのOchakkoのページのMameBake3Dというレポジトリで公開中
オープンソース GitHub


完成度が上がったEditMotを足掛かりに
山積みの人生の問題点も 好転するでしょ?(と思います)




2023年 今年もよろしくお願い申し上げます[2023/01/03]


今年もよろしくお願いします
何か日記を書いておこうということで
年末年始にみた夢の話と 1/2夜のバージョンアップについて書こうと思います


年末は こまごまとしてお手伝いをいつもよりたくさんしたように思います
もう箇条書きしちゃいます

1,換気扇
 キッチン換気扇取り外し取り付け
 風呂の換気扇フィルター洗浄
 トイレ換気扇分解掃除機かけ
2,風呂の窓取り外し取り付け
3,キッチン窓取り外し取り付け
4,玄関ドア水拭き
5,玄関床水掃除
6,風呂カーテン注文取り付け
7,自分の部屋の掃除機かけ
8,トイレと脱衣所のカーテン取り付け
9,掃除機ゴミパック交換
10,カレンダーゲット
11,堀こたつ掃除
12,天井下すす払い
13,階段雑巾カラ拭き
14,玄関にささやかなお飾り設置
15,年に1度のテレビセッティングと紅白予約

結構しました!?

とアピールしておいてからの
大みそかの ”昼寝の話” に入ります

初夢というのは1月1日の夜とか明け方にみる夢のことらしいですが
私はよく大みそかの昼寝の時に 暗示めいた夢をみることが多いです

今年の昼寝のゆめはどんなだったか 書いてしまいましょう

技術を同じ会社の人に教える夢でした
教えるといっても 自分でもやったことがないことを教える夢
あーでもない こーでもない と試行錯誤の後に あっ出来た!
とそこに表示され浮かんできたキーワードは
”Contrinique”
実在しない単語ですが すぐに読めました
コントリニキュー
と読みます
コントリビュートでもなく こんがり鶏肉でもなく コントリニキューです


それでこの試行錯誤の成果を人に教えるのですが
やっと出来たという高めのテンションで
要するに! contriniqueがね、、、
と説明します

相手は は? と困惑

私は相手の持っている資料を覗き込み 原因把握

あれ?そっちの資料はコントリニキューになってない?
なんて書いてあります?
みると

〇〇〇 = o mg ... []

のようなスペース混じりのスクリプトっぽい 自分が普段使っているよりもモダンで高級言語っぽいものがみえます
そしてそれをみたとたん
はっと我に返り

コントリニキューってなんだっけ?

という夢でした。

いろいろな暗示が含まれていて 反省しどころだらけです
造語とかオリジナル性だとか高級言語への移行があまり進んでいないなど いろいろ問題だらけです

そんな感じの暗示の夢でした

夢の中でまでプログラミングだったのですが
EditMot1.1.0.10を
2022/12/31に完成させるために 結構しんどい作業をしまくりました



甲斐あって 2023/01/02の夜に オープンソース先行リリース出来ました!
オープンソース GitHub



(Vector様で公開させていただいているインストーラは2023/01/11夕方 公開予定)
Vector様で ダウンロード2023/01/11夕方 公開予定



1.0.0.35から1.1.0.10へと中位のメジャーバージョンアップしました
オイラー角の数値をMayaライクにするために 苦労しました
ほんともう試行錯誤の回数はもう分からないくらいです

でも出てきた結果が 3D業界の正義であるところのMayaというソフトと同じ数値というところが
反省を踏まえていて なかなか感慨深いものがあります

オイラー角をMayaライクにしてなにが良くなるかについて少しだけ説明しておきます

今までは+-180度の範囲内の角度でした
どういうことかと言いますと
+180度は+180度ですが +181度の場合は-179度という扱いでした
三角関数は360度角度が違うと同じ数値になるので 姿勢としては同じです
しかし オイラー角の変化として +180度が-179度へと変化する場合
その途中の姿勢の表示方法によっては 体全体が くるんと回ってしまうこともあります

Mayaライクなオイラー角の場合には
+181度はそのまま+181度であり +180度から+181度の変化の途中の角度も連続します

そのような改善効果があります

問題点というと
今回のバージョンアップにより制限角度設定を設定し直さなければならない点です

この問題に対しては
制限角度設定ダイアログのボタン1つで簡単に制限角度を設定可能にしておきました

そのボタンには
From All Retargeted Motionsと書いておきました
制限角度を設定したいモデルデータにいくつかモーションを読み込んでおいた状態で
From All Retargeted Motionsボタンを押します
読み込み済のモーションの可動範囲をスキャンして制限角度として設定します

つまり既に動くことが出来る範囲を動かすような設定がワンボタンで可能です


もう1つ書いちゃいます

今回のバージョンアップの目玉機能の1つに
回転操作時に移動成分も回転する というのがあります

どういうことかと言いますと
例えば
Hipsという名前のジョイントは通常 体全体の回転や移動を設定するためのジョイントです
そのHipsを回転しただけでは
体の向きと違う方向に移動してしまうのです

体の向きと移動の向きを合わせるためには 移動成分も回転します

実装方法は、、、
要するに TraAnim(トラあにむ)がね、、、
なんです

え?正夢?
ウサギ年だしー

ええいっ 正夢ついでに 説明してしまいましょう!!

行列計算はSRT形式つまり Scale(拡大) Rotation(回転) Translation(移動)の3要素で計算するのが流行っているようです
この方法でも良いのですが
Translationの部分が問題なんです

SRT方式の場合には アニメーションとしてTが設定されていない場合にも ジョイントの位置が数値として入ります
その結果 アニメーションだけに着目した計算編集がしにくいという問題があります

そこで自然発生的に出てくるのがTraAnimなんです!

私は昔ながらの行列計算が好きでして

PrevPivot Scale Rotation PostPivot TraAnim 式1
のように計算します

どういうことかと言いますと
式1のように表現して計算することにより
アニメーションとしての移動が設定されていない場合にはTraAnimは0になるのです

アニメーションだけに着目可能になります

話をもとに戻します

移動成分も回転するという話は つまり 移動のアニメーション分(TraAnim)を回転することです

具体的には
行列を SとRとTraAnimに分解する関数と
SとRとTraAnimから行列を組み立てる関数を作りました

そして回転部分だけを入れ替えたりすると望みのことが可能でした


詳しくは 動くものをオープンソースにしましたのでご覧ください
オープンソース GitHub

このような年末年始でした

何が言いたいかと言いますと
要するに 、、、







EditMot 1.0.0.34をコンフィデンスバージョンとしてリリース[2022/11/16]


EditMotの おまとめ版 出ました
ここまでの作業の成果のまとめという意味です

何が出来たのか? まず何と言っても ブレなくなったIKが挙げられます




EditMot 1.0.0.34 公開
Vector様で ダウンロード

オープンソースも同時公開
(https://github.com/Ochakko/MameBake3D)




今までにもIKがブレなくなったバージョンはあったと思うのですが
fbxの読み込み方を変えたり いろいろ他の部分を変えることで いつのまにかブレていました

今回のバージョンは マニピュレータの軸を ボーン軸にオートフィットします そしてIK中にそれがねじれません
オートフィット(自動的 向き合わせ)は ボーン軸がバインドポーズに対して傾いていても 機能します
更に 0フレームにモーションが設定してあっても 機能します

今回の IKのブレの無さと 数式のシンプルさと 複数モデルでの検証結果は 本物っぽいです!




以前にも書いたことがあったとおもいますが 
ブレないIKは RokDeBone2という作品が有りながらも 新しいソフト開発に踏み切った 大きな課題でした
やっとです ほんとに  やっと

なぜ ブレないIKにこだわるかというと
IKをプログラミング制御に使用する場合に こうすればこうなるという 確かさが必要だからです

IK軸がブレたときにどういう不具合があったかと言いますと
ジョイントをドラッグするたびに IK軸が変化してしまい 操作の連続性を保つことが出来なかった不具合
軸がねじれると 曲げたい方向へ曲げることが難しくなる不具合 などがありました

上記の2つの不具合が解消されました


今回のリリースにあたり
チェックしている項目とチェックしていない項目が どうしてもあります
EditMotチェックリストに書いてある項目が EditMotの使いどころ
リリースの度にチェックリストは作ってきたのですが 1.0.0.33と1.0.0.34のチェックリストだけ 載せてみます


図1 1.0.0.33のチェックリスト



図2 1.0.0.34のチェックリスト

1.0.0.34のチェックリストはこの後 2項目ほど修正して全てチェックが入りました
そのあたりが使いどころです





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)もプロジェクトファイルを統合してビルドしやすく
ソリューション1個をビルドするとプラグイン含め全部ビルド出来る
ただしDirectX SDKとFBX SDKは別途入手

#################
RokDeBone2について
#################
RokDeBone2は1つのオープンソースでForE3DとForUnityの両方をビルド可能になっています
違いはオイラー角の回転順序
ForE3D : オイラー角ZXY
ForUnity : オイラー角XYZの2種類
ForE3DとForUnityのビルド切り替えはver6.hの#define文を有効にするかコメントアウトするかによって切り替えます

ForE3Dで保存したファイルはForUnityで読めるが
ForUnityで保存したファイルはForE3Dでは読めない
プログラムのバージョンは
ForE3D : 5600
ForUnity : 6000
ForUnityはオイラー角を汎用性の高い順序XYZにすることにより
Unityで読み込んだ時のトラブルを減らしている
オカルト部部長の歩くモーションがなぜかUnityで傾く現象に気が付いていた人もいると思うが
オカルト部部長をUnityに持って行っても軸がぶれなくなった



##########################
EditMot(MameBake3D)について
##########################
EditMotのオープンソース名はMameBake3D


名前の履歴(最初のバージョンは2010年頃)
ChaFuBX(名前にFBXが入っているからざわつくに決まっていると言われた)-->
PiyoAnim(決めたときには同名ソフトは見つからなかったのだが決めてから改めて検索したら昔から同名ソフトがあったらしいので変更)-->
MameBake3D(今もオープンソースはこの名前)-->
MotionBrush(シェアウェアとして実行ファイル配布用の名前)-->
MotionBrushFree(インストーラ形式のフリーウェア化)-->
EditMot(商標トラブル事前回避のためにこの名前に改名 現在の名前)


プロ用のモーキャプライブラリRokokoのfbxを読み込み保存可能に
読み込み方改善によりリターゲットの式も修正
リターゲットの式は読み込み時の条件に依存するので読み込み変更により修正
リターゲットの条件はモデル側とモーション側の0フレームにおける見かけ上のポーズが同じこと

バンドポーズの無いfbx読み込みのオイラー角について
バインドポーズが無い場合には
ジョイント位置を推測計算することになる
その場合にバインドポーズと0フレームのアニメを明確に切り離して計算することは難しい
EditMotではシンプルに推測計算している
ローカルのオイラー角表現はバインドポーズ依存なので
推測計算の場合ローカル表現の仕方はいろいろあり得る
頂点に対して演算した時に変換後の頂点位置になるような表現になっているなら合っているという解釈


180度裏返り防止機能について
裏返り防止機能は複数回処理を行うと何もしないときよりも不安定になる
様々な機能がある中で自動で1回だけ処理するのが難しかった
ver1.0.0.29では180度裏返り防止機能をコメントアウトした
使った方が良いケースはあるので
将来のバージョンでToolWindowのボタン機能化する


バッチ処理のリターゲットでは起きたことが無かったが
GUIで1つずつリターゲットしたときに体が伸びたような結果(不具合)になることがあった
Hipsジョイントを名前で探す処理を付け加えることによりその不具合は起こらなくなったようだ



アンドゥリドゥ改良
1万フレームのモーキャプを読み込むとジョイントの選択変更に数秒間かかっていた
原因はジョイント選択時にアンドゥ処理用の自動保存をしているためだった
自動保存が悪かったのではなくてモーション全体を自動保存してるのが遅かったと解釈
パーシャル(部分的)アンドゥリドゥに改良
1万フレームモーキャプ読み込み時にも編集範囲が数十から数百ならレスポンスは快適
アンドゥリドゥ用のGUIボタン表示


選択フレーム表示の改良
プレビュー時にフレーム選択表示が解除されたりアンドゥ時に選択が自動で戻らないことがあったのを修正
プレビューしても選択が外れなくなりアンドゥ時にも選択状態復元


マルチスレッド処理を改善
CThreadingBaseをベースクラスとして処理を共通化
CThreadingLoadFbxとCThreadingUpdateMatrixを派生
UpdateMatrixについては
メインウインドウのGUIのhigh rpm(高回転)チェックボックスとThread numスライダー(1から4)に対応
スレッドの数はモデルごとの数

hight rpmのチェックを入れると速くなる
Thread numの最適な数は環境による
こちらで試したところ(core 8個)
Win10ではThread num 1のhigh rpmが一番速い
Win11ではThread num 4のhigh rpmが一番速い
描画速度はメインウインドウのテキストとしてfps : ***のように表示
fpsは1秒間の描画回数
(アニメーションとしては24fpsとか30fpsが最低でも必要と言われている。テレビモニタの周波数と同期するのが基本。
ひと昔前は60fps表示がもてはやされていた。最近は可変周波数同期が流行?)


マルチスレッド改善後に更にプレビュー高速化
こちらの環境で20%の高速化に成功
10%は計算範囲絞り込みによる計算量削減による
もう10%はオイラーグラフの800個の四角描画を4本のラインに変えたことによる



既知の問題点
リターゲットをバッチ処理で行うと
モーションの数分モデルが出来る
その状態でThead num 4のhigh rpmにすると
CPUのコア数に対するスレッド数が多すぎてマウスのレスポンスが悪くなった
スレッド数は全モデルに対して4つまでにするべき?

リリースしてからもテストをしていたのだが
アンドゥーが戻らないもしくは同じ状態がたくさん保存されているような状態になったことがあった
まだ原因を特定していないが
モデル削除やモーション削除と関係している可能性がある
調査修正の必要有


半年分の更新を振り返りました
不思議に思っている人がいるかもしれないので触れておきますが
モーション再生の高速化についてはGPUを使えば速くなるのは周知
モーキャプの場合にはモーションデータが大きくて全部をビデオメモリに置けないことがあるのでCPUのマルチスレッド計算にしています
これについては今後も同じ方針かどうかはわかりません
ちなみに私の開発マシンのメインメモリは128GB積んでいます(64GBでは足りなかったことがあります) ビデオメモリ8GBです




追記 2022/10/06
EditMotは4Kテレビ接続時には
大きいウインドウで起動するか小さいウインドウで起動するかを選ぶダイアログが出ます。
fpsは環境依存の数値なんですが
大きいウインドウ(高解像度)にするほどfpsは小さな値になります
単純に考えても塗りつぶす画素数が増えると遅くなるので直感的にも納得することでしょう

大きなウインドウはウインドウサイズが縦横2倍で表示します
つまり塗りつぶす画素数は2x2で4倍になるのでfpsもそれなりに小さな値になります

そのような状況だったので
マルチスレッド処理に手を入れて1.6倍高速化
更に計算量削減などで1.2倍高速化しました

こちらの環境では大きいウインドウでも60fps出るようになりましたので
これ以上の高速化はあまり興味が無いようなあるような感じです


EditMotはモーキャプデータをfbxに変換してトリミングしてUnityへ持っていく部分が主な使い道
ぶっちゃけ個人的には見栄えはモーションを確認できる程度で良い
しかし動画やスクリーンショットでアピールする場合にその見栄えも影響するので
最近は手を入れていなかったシェーダーの勉強もしていく予定です




追記 2022/10/07
うれしいニュースです
MicorosoftのWindows11の22H2大型アップデートの後にまたアップデートが出ました。
アップデートにより
全てのCPUの稼働率を100%にしてもマウスレスポンスは快適でした。
モデルごとのスレッド数管理のままでEditMotが上手く動きました。






ソフト名が変わったり配布形式がインストーラになったことについて[2022/09/30]


前回の日記から4か月も経ちました。
その間にいろいろありました。
説明が必要と思われる部分を少し。

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軸の内の1つまたは複数が90度またはー90度をまたぐ場合に
オイラー角計算が乱れる
ことが分かりました。

EditMotのオイラー角計算方法は
一般的な行列成分と三角関数による計算方法ではなく
クォータニオンステップバイステップ回転計算法(今、書きながら付けた名前)です。

オイラー角計算が間違っているとEditMotとしての使いどころが無くなってしまいます
オリジナルの方法なんてやっぱり役に立たないのかぁと落胆の日々でした。

しかしある日突然頭が冴えてぴきぴきーんとオイラー角計算を直してしまったのです。

この直った計算方法でMayaの計算結果と比べたところ
90度をまたぐようなモーションでも計算結果が一致しました。

さらにEditMotの方が180度裏返り対策も成されることが分かりました。

10年位も開発してきた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 !!)


今日の日記のここから先は思い付きの余談です

一般的な行列成分と三角関数による計算方法とは異なる方法であるところの
クォータニオンステップバイステップ回転計算法に利点はあるのかどうかについて。

計算結果が同じであるのにわざわざ異なる方法にする意味があるのかについて。

本当に余談なんですが
3次元の回転におていはあまり利点は無いです。
あるとすれば、1軸ずつ回転する方が分かりやすい人がいるはずくらいのもの。

しかし4次元以上の回転を考える場合において
連立方程式を解くよりも1軸ずつ回転する方が分かりやすいのと
ジンバルロック対策が楽なことが利点になります。

では4次元以上の回転とは何なのか?
思い付きなんで聞き流してもらいたいのですが

4次元目は虚軸 i、虚軸と垂直な3つの実軸XYZがあるとします。
3次元の回転は回転平面で表すと
(YZ平面回転)(ZX平面回転)(XY平面回転)
と表せます。

同様に4次元回転については
(YZ平面回転)(ZX平面回転)(XY平面回転)(i Y平面回転)(i Z平面回転)(i X平面回転)
と表せます。
この連立方程式を解きつつ多数のジンバルロックの場合分けをするのは大変です。

しかしクォータニオンステップバイステップ回転計算法ならば
回転の種類が増えた分だけ線形にプログラムソースの量が増えるだけで済みます。
更に単純明快。

4次元回転はさらに発展する可能性があります。
虚軸iに対して垂直な虚軸が2つj, kがある場合です。
その場合は多分15次元だと思います。
15回回転した行列の連立方程式を解きたくはないです。

という感じで
無理やり利点を思ってみました。


10年位も開発してきたEditMotの面目を保つことがなんとか出来たと思います。
オープンソースなので4次元以上で回転して利点があることを実感してください。

たわごととしての追記
4次元以上で回転することは物理的にはどういうことなのか?
X軸と呼んでいるものは実はXの実軸とXの虚軸から成る
それは数式的には
どちらかがcosX軸であり他方がsinX軸である
どちらが実でどちらが虚かについてはフーリエ変換を参考にすると
X軸については実軸がsinX軸であり虚軸がcosX軸となる

つまり物理的に4次元回転は可能である

15次元と上で書いたことの補足
回転には回転平面があり回転平面は2つの軸で決まる
回転自由度として何次元になるかというと
sinX,sinY,sinZ,cosX,cosY,cosZ軸の6つの軸の中から2つの組を選ぶ場合の数は
6C2=(6*5)/(2*1)=15通り
よって15次元であろう
15次元の回転をジンバルロックを回避するためのデータ構造は16元数であろうか?

回転いろいろ



更に追記
15次元で回転計算をしても表示するときには3次元にしようね!!



も1つ追記
虚軸回転を3次元で表示するとどうなるかについて
推測としては
位相がずれた回転になるのではないだろうか?
電気で言うとコイルやコンデンサのような位相がずれた電流が流れる
それは物理で言うと何なのか?
ひょっとしたら慣性のことかもしれない

そういえば
(当時のアニメに出てきていた)慣性装置を作ってくれと
中学生の時に友達から頼まれていたのを思い出した(笑)


追記〆
なんかいろいろ思いついてしまうときはときどきあるものです。
そんな思い付きメモが大半を占めてしまった今回の日記ですが
〆として
普通にMayaとUnityいじりに戻ります
今回は難しいファイルを読むことで発覚した大きな不具合をオープンにしたまま放ってはおけなかった修正ということで。

いざ戻らんっ普通の社会へ!!



EditMotの物理ブラシについてのメモ[2021/12/09]


EditMotの物理ブラシの使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)

EditMot ver1.0.0.22では4つのブラシを追加した
4つのブラシの共通点としては
ボクシングのモーキャプデータのオイラーグラフを観察して
パンチの部分のグラフの形を近似
した形のブラシにしたところです

モーキャプグラフの近似の際には
簡単な高校物理レベルの曲線で近似しました
教科書に載っていた放物線とか自由落下とか空気抵抗のあるときの運動とか
そんな感じのあの懐かしの数式です

観察して
だいたい4種類あるとおもいました
(アバウトな感じで)

新たに足した4つのブラシは
物理挙動の曲線を真似たものなので
物理ブラシと呼べるでしょう

では4つの物理ブラシを紹介します


図1:Punch_1ブラシ

図1にPunch_1ブラシで腕をIKした時のキャプチャを載せました
オイラーグラフの赤い線がX軸、緑の線がY軸、青い線がZ軸の回転量を示します

Punch_1ブラシは
パンチの出し始めと引っ込み始めの部分で速度があまり大きくなく
同じ方向への運動時間が長くなるほどスピードが速くなる物理ブラシです





図2:Punch_2ブラシ

図2に示すPunch_2ブラシ
パンチの出し始めと引っ込み始めに速度が速く
動きの方向が変わるまたは止まる前の速度が遅くなるような物理ブラシ


図3:X2Capブラシ

図3に示すX2Capブラシ
おなじみの放物線ブラシです
物を投げたときの近似曲線
運動の向きと反対側に同じ加速度つまり重力が掛かっているときの曲線のブラシ



図4:X2Needleブラシ

図4のX2Needleブラシ
パンチが当たる付近のパンチを出す側とパンチを引っ込める側の両方の速度が速いような物理ブラシ


4つ足しましたが
だいたい網羅出来たのではないかと思います(そんなアバウトなぁ!!)

ちなみに今回のテストは
まず肘を曲げた状態を作っておきました
そこから階層数に02を指定して手首ジョイントをマウスでドラッグしてテストしました


物理ブラシを選んでドラッグするだけで
好みの場所に好みの長さ好みの大きさの物理挙動を作ることが出来ます


え?パンチのグラフの形しか観察しなかったのかって?
物理パンチは世界を制するですよ?!
(物理ブラシのように舞い物理ブラシのように刺す!!)




EditMotのカスタムリグについてのメモ[2021/12/08]


EditMotのカスタムRigの使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)

まず大まかに説明
MationBrushのカスタムRigはユーザーが自由に作成と設定と実行を行うことが出来る

Rigへの入力としてはマウスの横方向と縦方向の移動量の2種類
この場合の横と縦の移動量というのは
カメラの位置や向きに関わらず常に目の前の画面に対しての横と縦

Rigの効果としては
2つの入力それぞれに対してXYZどれかの軸に関する回転
または
他のリグへ2つの入力を伝達
すること

それぞれのリグに関して5つの出力先を指定可能
リグの所有ジョイントとそのジョイントから4階層親のボーンまでの
合計5階層のジョイントの回転制御をするいことが出来る

入力に対して正負の符号と倍率を指定することで
ひざが正の向きに1.5倍で真がっと時にはももが負の向きに1倍で曲がるなどの設定が出来る

Rigの操作は赤青緑の球をマウスでドラッグすることで行う
リグのマークを横と縦の移動量に気を付けながらドラッグするだけで
設定した向きと角度倍率でポーズを作ることが出来る

概略としてはこんなところ
では実際の画面をみてみる


図1:RigボタンとRigモード

図1はRigボタンを押したときのRigモードの画面
Rigボタンは画面の向かって右側のサッカーのキックをしているマークのボタン
押すたびにオンとオフが切り替わる

リグモードにすると作成済のリグが全て表示されて操作可能になる
リグマークはXYZ軸の色をしている
色と表示位置は指定可能

リグマークの大きさは指先に表示しても邪魔にならない位を基準にしている
操作するときにはカメラを人物に寄せて大きくみることを想定している

サンプルには手の甲の部分に3つのリグ、指の先端に1つずつのリグが設定されている
手の甲の赤い球をドラッグすると手のひらを閉じたり開いたりする
指先の球をドラッグすると指を曲げたり伸ばしたりする

1つ1つのジョイントをドラッグしなくても
球をドラッグするだけで開いたり閉じたり出来るところがリグを使う理由だと思う

明るさ的にリグマークがみえにくい場合には
BasicSettings1の一番上のスライダーでライティングを暗くする
モデルデータが暗くなることでリグマークの明るさが目立ちみやすくなる



図2:リグの作成メニューと設定メニュー

リグの作成と設定は3Dウインドウでジョイントを右クリックするか
あるいは図2のようにツリービューの項目を右クリックしてメニューを出して行う

メニューの下の方に
CreateNewRigとあるのがリグの作成メニュー
その下には作成済のリグの名前(自分で決める)が作成してある分だけ表示される

メニューの作成済のリグの名前にマウスを当てると
SettingOfRigメニューがある
これがリグの設定メニューである


図3:リグ設定ダイアログ

リグ設定メニューを選択すると
サイドウインドウにリグ設定ダイアログが出る
自分を入れて5階層までのボーンツリー
もしくは
5つのリグに対して
マウスの横と縦に対する回転軸と角度倍率と有効無効を設定
する

ボーンを指定したいときには
ボーンorRigのコンボボックスでRegularBoneを選ぶ
そうすることにより
自動的にリグの所有ジョイントから5階層上までのジョイントに対する設定になる


表示場所(軸)、表示場所(番目)、マイナス位置の設定項目は
リグのマークを表示する位置についての設定
軸はXYZ選べてそれぞれの色
番目は0から3までで数字が大きいほど原点から離れて表示される
0番目は1つしか設定しない(なぜならXYZとも0番目は同じ位置だから重なってしまう)
マイナス一は軸のどちら側に表示するかの設定




図4:RigからRigを呼び出す

図3ではマウスの移動量に対応するのはボーンという設定だった

カスタムリグではリグからリグへとマウス移動量を伝達することが可能
リグからリグを呼び出す場合には
図4のように
ボーンorRigの項目の場所にリグの名前を指定する
指定する際にはコンボボックスに作成済のリグの候補が全て表示されるのでそこから選択すれば良い

ボーンorRigの項目に表示されるリグの名前としては
所有ジョイント名の後ろに自分で付けたリグの名前が連結されているような文字列で表示される

図4では手の甲のリグから指先のリグを5つ呼び出している


BasicSettings2のLimitEulチェックボックスにチェックを入れておけば
リグの操作時にも制限角度が効く

例えばTestフォルダに入れてあるサンプルでは
指が反る方向には曲がらないようにしてある


こんな風に軸と符号と倍率だけで使い物になるのかどうか心配かもしれないが
割と便利だと思う

設定していて気が付いたこととしては
足を前に出すときのリグと足を後ろに蹴るときのリグは別々に設定した方が良いということ




リグからリグは何階層呼び出せるかについてだが
リグから呼び出されたリグから呼び出されたリグから呼び出されたリグから呼び出されたリグから呼び出された
リグから呼び出されたリグから呼び出されたリグから呼び出されたリグから呼び出されたリグを実行可能である




EditMotのアンドゥとリドゥについてのメモ[2021/12/06]


EditMotのアンドゥとリドゥの使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)

まずは用語の説明
アンドゥ(Undo)とは保存してある操作履歴の中の昔の状態を復元すること

アンドゥをどのように実装しているかというと
200回分の操作を保存できるメモリに操作をするたびに操作結果を保存していきます
アンドゥ機能が呼び出されるたびに過去の方向に向かって操作結果を復元します

リドゥ(Redo)というのは過去の時点を指しているメモリ位置から未来方向に向かって操作結果を読み取って復元すること

200回分しか保存できませんが一番最後に達した場合は一番最初に戻ります
一番最初に達した場合は一番最後のメモリを指すようにします

このようなメモリの使い方をリングバッファと言います(大体の意味です。リングバッファの正確な意味を知りたい場合にはきちんとしたサイトで調べなおしてください)


それではUndoとRedoの仕方をメモします


図1:IK操作をしました

まずテストとしてIK操作をしました(図1)


図2:Ctrl + ZでUndo

キーボードのCtrlキーを押しながらZキーを押すとUndoします
図2が図1の状態からUndoした後の画面です

ver10022ではフレーム選択状態が復元されませんでした。
2022/01/19公開予定の10023では
アンドゥーリドゥでフレーム選択状態も復元されます。

UndoすることによりIK操作前の状態に戻りました

次にこの状態からRedoしてみます


図5:RedoすることによりUndoで取り消した操作が画面上に復元された


RedoするにはCtrlキーとShiftキーを押しながらZキーを押します

RedoすることによりUndoで取り消したIK操作が復元されました。
フレーム選択範囲の復元はUndoのときと同様に行いました


まとめ
Ctrl + Z --> IK操作のUndo
Ctrl + Shift + Z --> IK操作のRedo
2重Vマークボタン--> フレーム選択のUndo
2重の屋根マークボタン--> フレーム選択のRedo
S+マウスホイール--> タイムライン時間表示範囲シフト


仏の顔も3度まで
Undo Redoは200回まで!!




EditMotの制限角度の設定と制限角度下でのIKについてのメモ[2021/12/05]


EditMotのコピー制限角度の使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)

今回のメモは2021/12/08夕方公開予定のEditMot 1.0.0.22(2nd Completed Version)についてのメモです


図1:起動直後のスイッチ連続投入の図

EditMotを起動したら
私はいつもスプライトプレートスイッチをひとつずつ全部押してGUIを表示します
演出としてはコクピットに乗ったパイロットがスイッチを素早くオンにしていって
起動音がきゅうぃーーんと鳴るあの感じです
嘘です

今回は制限角度についてのメモです


図2:制限角度ダイアログを出す

GUIのカエルボタンを押してLimitEulプレートをクリックして制限角度ダイアログを出します


図3:モーションが制限角度で制限されている様子

制限角度ダイアログの見方を説明します
一番上にはどのジョイントの制限角度なのかがわかるようにジョイント名が書かれています
マウスでクリックしたジョイントの1つ親のジョイント名が書かれています
なぜかというと設定しながらIK(子供ジョイントをドラッグして親ジョイントを中心に回転する)する場合に
わかりやすいからです

制限角度ダイアログにはスライダーが9つあります
X軸Y軸Z軸にかんしてそれぞれ3つずつの合計9個です

3つの内訳は
制限角度の下限値スライダー、制限角度の上限値スライダー、現在のフレームにおける現在の値
の3つです
この3つがXYZそれぞれにあります

制限角度が効いているので
現在値の値は下限値と上限値とで囲まれた範囲内しか動きません
その状態をオイラーグラフで見ると制限の範囲外がカットされている部分はそれ以上変化できずに平らに見えます


図4:制限角度を掛けない場合のオイラーグラフの確認

制限角度はオンオフ出来ます
図4に示すようにGUIのLimitEulチェックボックスのチェックを外すと制限角度はオフになります

制限角度がオフの場合のオイラー角は
制限の範囲外にも動けるので制限で平らになっていた部分もカーブに見えます



図5:制限角度下でのIK操作

制限角度はモーション再生時だけでなくIK操作時にも効きます

デフォルト状態では
GUIのWallScrapingIK(壁すりIK)がオンになっています
壁すりIKとはIK操作中にXYZどれかの軸が制限値に達しても
制限値に達していない軸がマウスドラッグに近い姿勢になるように動きます
この際にも可動範囲内だけを動きます

壁すりIKをオフにすると
XYZ軸のどれか1つの軸でも制限値に達すると
いくらマウスをドラッグしてもうんともすんとも動かなくなってしまいます


可動範囲内だけを動かしたいのだから
壁すりIKをオフにして1つの軸でも違反したら動かなくて良いと思うこともあります
私も最初はそう思いました

しかし
多数のモーションを読み込んでテストした結果
IK操作開始時点の姿勢が既に制限角度の外にある状態の場合
すでに制限角度違反している状態なので
WallScrapingIKをオフにしていると
マウスをどちらに動かしても度の軸を動かそうとしても動かなかないことが多かった
のです

壁すりIK(WallScrapingIK)をオンにしておくことで
制限角度下においても可動範囲内をIK操作可能です



図6:モーションの制限角度をベイクして保存

保存に関してですが
普通にプロジェクトを保存すれば制限角度ファイルも保存されます

fbxのモーションとして制限角度が掛かった状態の動きを保存したい場合には
プロジェクト保存時に制限角度をベイクするにチェックします





次に制限角度の設定が簡単になったのでその説明をします


図7:制限角度設定前の初期化

制限角度を設定する前にまったく動かないように制限角度を0度に初期化します
制限角度ダイアログのReset 0ボタンを押すと全てのボーンの制限角度が0度になります


図8:現在のモーションの可動範囲を制限角度として設定

次に制限角度ダイアログのFormCurrentMotionボタンを押します
このボタンを押すと
読み込み済で現在選択中のモーションの全フレームのオイラー角の最小値と最大値を検索して
それを制限角度として設定します
ワンボタンで出来てしまいます

1つのモーションの可動範囲だけでは汎用的な制限角度にはなりにくいです
モーションを選びなおしてからFromCurrentMotionボタンを押すと
現在設定されているよりも大きく動いた分が制限角度として更新設定されます


モーキャプデータを読み込んでFromCurrentMotionボタンを押してそれを制限角度として設定することで
実際の動きからリアルな制限角度設定が可能です


手の制限角度について
モーションキャプチャデータには手の指のキャプチャデータは入っていないことがあります
その場合には自分で手をパーからグーにするモーションを作りFromCurrentMotionボタンを押します


リアルな制限とリアルな動き
変な風に動かしたくないという長年のストレスの原因がかなり解消されました

EditMot 1.0.0.22は1.0.0.7に続き2nd Completed Version(2度目の完成版)です


もっとバージョンアップしたらもっと良くなるよ!?
もう、いいっ!!(Vuぅーーん、バリバリバリっ)




EditMotのコピー履歴機能の使い方メモ[2021/12/03]


EditMotのコピー履歴機能の使い方を忘れないようにメモ。
(EditMotとはモーキャプデータをfbxに変換して部分的にコピペするツールです。
EditMotのページ
)


図1:モーションのコピー

モーションのコピーは複数フレームをマウスドラッグで選択してToolWindowのコピーボタンを押します。
するとコピー情報入力ダイアログが出ます。
このダイアログの項目に設定をしなくてもコピー自体は出来ます。
ダイアログの項目に設定をしてメモを書いておくことにより
コピー履歴一覧にそれらの情報が表示されるので検索しやすくなります。
設定項目による検索機能があるからです。


図2:コピー履歴選択ボタン

ToolWindowのコピー履歴選択ボタンを押します。
右側のサイドウインドウにコピー履歴選択ダイアログが表示されます。
最初の状態では
ダイアログの最新のコピーを選択するチェックボックスにチェックが入っています。
このチェックが入っているときには
過去をさかのぼってコピー結果を選択することは出来ませんが
自動的に常に最新のコピー結果をペースト時に使用します。

コピー履歴はWindow(OS)指定のTempフォルダの中に保存されていきます。
自分でファイルを消さない限り履歴は蓄積されます。



図3:最新のコピーを選択チェックを外す

コピー履歴選択ダイアログの最新のコピーを選択チェックを外します。
グレーになっていたダイアログ上部がみえるようになります。
項目として表示されているものの中にコピー時に設定した項目やメモがありますので
それを目印に探します。




図4:コピー履歴検索

コピー履歴選択ダイアログの上2段には履歴検索のためのコントロールがあります。
一番上の段には
fbxファイル名、モーション名、bvh typeがあります。
指定は必須ではありません。
二段目には検索開始日時と検索終了日時の指定項目があります。
コピーした時の日時の範囲を指定できます。
検索実行ボタンを押すと条件に合う履歴だけが表示されます。

条件を変えて検索を繰り返す場合
履歴全体からの検索になります。
複数回検索による絞り込み検索ではないです。

履歴項目の右側のdeleteボタンを押すと
Tempフォルダの中の該当する履歴ファイルが削除されます。

履歴の中からペーストに使用したいコピー結果を選択したら
OKボタンを押します。
OKボタンを押し忘れるとペーストしようとしてもペースト出来ません。
2022/01/19公開予定のver10023では
OKボタンを押さなくても選択がペーストに反映されます。



図5:コマンド対象ボーンボタン

次にすぐにペーストしても良いのですが
ペースト対象とするボーンを選択する手順も説明します。

コピー操作は全ボーンに付いてコピーが行われて保存されます。
部分的なコピペはペースト時に対象ボーンを選びます。

ペースト対象ボーンの選択をすることにより
体の一部分だけの動きのコピーペーストが可能です。

図5では上から2番目のボーン以下を対象として選択しています。
このとき一番上のボーンの動きはペーストされません。
一番上のボーンには体全体の移動と回転と拡大縮小の動きが入っています。
体全体のモーションをペーストせずに残りの全てのモーションをペーストすることにより
体全体が同じ位置同じ向きのまま動きをペースト可能です。

指定方法は
左側のツリーから項目を選んで右側のペーストするボーンの選択の追加ボタンを押すか
または
右側のペーストしないボーンの選択の追加ボタンを押します。


追加された項目とその子供全てが対象となります。



図6:ペースト実行

ペーストしたいフレーム範囲をマウスドラッグで選択し
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


では手順説明です。


図1:VRoidでキャラクターモデル作成してエクスポート

かわいいキャラクターをすぐに作れるVRoidが正式版になったそうなので試してみました。
ライセンスとしては作成したモデルをUnity上でゲームに使用しても良いそうです。
図1はVRoidで作成したキャラクターです。
この日記のページの都合上画像ファイルが小さくて圧縮表示で残念ですが実際もっとすごいかわいいです。

今回の日記はVRoid正式版のvrmファイルをUnity上で表示して
モーションキャプチャファイルbvhの動きをさせる手順を書きます。
図1に示すようにキャラクターが完成したらVRMエクスポートメニューを実行。

次にモーションキャプチャファイルfbxにしてUnityに持っていく準備をします。
EditMotというソフトを使います。
https://www.vector.co.jp/soft/winnt/art/se523002.html



図2:bvhフォルダ

図2のようにモーションキャプチャファイルbvhを1つのフォルダに入れます。
モーションキャプチャファイルはカーネギーメロン大学のMotionBuilder Friendlyタイプを推奨。
モーキャプデータには回転の順序だけでなく座標系がいろいろ異なるものがあるので
適切な種類を選ぶことが重要

retarget.rtgというファイルはEditMotというソフトのTestフォルダの中に入っています。
retarget.rtgファイルをbvhファイルと同じフォルダにコピペします。


図3:bvh2FBX batchメニュー実行

EditMotを立ち上げてFile-->bvh2FBX batchメニューを実行。


図4:bvh2FBX batchでbvhフォルダーを指定

bvh2FBX batchメニューを実行してbvhが入ったフォルダの場所を指定します。
図4はbvhフォルダ指定画面です。


図5:bvh2FBX batchの結果

bvh2FBX batchが成功すると図5のようにbvhフォルダの中にfbxファイルが生成されます。

次にUnityへ複数モーション入りのfbxを持っていく準備として
1つの形状fbxにbvh2FBXで作成した複数のfbxモーションをリターゲットします。


図6:MotonBrushでサンプルプロジェクトを読み込む

EditMotのFile-->Openメニューを時こうして
EditMotのTestフォルダの中にあるサンプルプロジェクトを開きます。


図7:EditMotのTestフォルダのプロジェクトを読み込んだところ



図8:サンプルプロジェクトの形状にbvh2FBXで作成したFBXのモーションをバッチでリターゲット

File-->Retarget batchメニューを実行して
サンプルプロジェクトの形状にbvh2FBXで作成したFBXのモーションをバッチでリターゲットします。
少し時間が掛かりますがプログレスバーが出ますので気長に終了を待ってください。


図9:モデルパネル表示

Retarget batch終了後にはサンプル形状にモーションが適用されています。
この際モーション用のモデルデータも作成されます。
モーション用のfbxのモデルは重くなる原因ですので削除します。
削除するにはFile-->モデルパネルメニューを実行してモデルパネルを表示し
不要モデルの横のdeleteボタンを押します。


図10:不要モデルを削除した後のモデルパネル


図11:モーションパネル

モデルを削除して動作を軽くしたところで
リターゲットしたモーションの確認をします。
モーションの確認をしてどのモーションを使うかを決めます。


図12:モーションパネルでモーションを選択して再生してチェック選択

モーションパネルでモーションを選択した後
オイラーグラフ(画面下の横長ウインドウ)の上部のボタンの内、三角の形のプレイボタンを押します。
プレイボタンを押してモーションをチェックします。
カメラ操作用のスプライトボタンは3DウインドウのSpriteFKと書いてあるプレートをクリックして出します。


図13:ToolWIndowのプロパティボタンでモーションに名前を付ける

使用するモーションを決めたら
そのモーションに名前を付けます。
ToolWindowのプロパティボタンでプロパティダイアログを出して名前を設定。


図14:プロジェクト保存

File-->Save-->Projectでプロジェクトを保存します。

図15:プロジェクト名設定

プロジェクト保存時にはプロジェクト名を変えることを推奨します。
名前を変えない場合は既存のプロジェクトが上書きされます。



図16:Unity3Dでプロジェクト作成

さていよいよ本題のUnityで動かすための説明です。
Unity3Dのプロジェクトを作成します。
3D Coreタイプを選択して適当なプロジェクト名を付けてCreate projectボタンで作成。


図17:モーションリターゲット済のfbxとテクスチャをUnityのAssetにドラッグアンドドロップ

モーションリターゲット済のfbxとテクスチャをUnityのAssetにドラッグアンドドロップします。
リターゲット済のfbxはEditMotで作成したプロジェクトフォルダの中のモデル名のフォルダの中にあります。


図18:fbxのRigをHumanoidに設定

fbxをドラッグアンドドロップしたら
Assetの中にfbxのアイコンが出来ます。
再生マークが付いているfbxのアイコンをクリック。
右側のInspectorウインドウのRigタブをクリック。
RigのタイプとしてHumanoidを指定してApplyボタン。
これでfbxのボーン情報がUnityの標準形式へと変換されました。


図19:fbxのAnimation設定

図18のRigタブのtなりにあるAnimationタブをクリック。
今回はプログラミング無しでの説明なのでモーションは1つにします。
モーション名のあるウインドウで必要ないモーションを - ボタンを押して削除。

LoopTimeにチェック。
CycleOffsetに1(後で再生速度倍率を設定すると自動で大きい数値になる)。
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側の全体移動の位置と同じになるように数値入力するとうまくいきます。



図20:Asset内にAnimator Controllerを作成

Asset内で右クリックしてCreate-->Animator Controllerメニューを実行して
Animator Controllerを作成。


図21:Animator Controllerの設定

作成したAnimator Controllerのアイコンをクリック。
画面上のAnimatorタブをクリック。
fbxをEntryボタンの辺りにドラッグアンドドロップ。
モーション名のラベルが付いたオレンジ色のボタンが作成される。



図22:モーションスピードの設定

オレンジ色のボタンをクリック。
Speedに5を指定。


次はVRoidで作成した表示用のvrmをインポートします。


図23:Asset内でImport Package



図24:UniVRM


vrmをUnityにインポートするには
UniVRMというパッケージを使いますのであらかじめダウンロードしておきます(図24)。

先ほどと同じモデルデータのあるAsset内で右クリック。
Import Package-->Custom Packageメニューを実行しUniVRMをインポート。
UniVRMというパッケージをインポートしてvrmをインポート可能になりました。


図25:VRoidでエクスポートしたvrmをUnityにインポート

VRoidでエクスポートしたvrmをAsset内にドラッグアンドドロップ。
vrmのキャラクターの絵が付いたアイコンがAsset内に出来ます。


図26:メニューからvrmをHierarchyに追加

vrmをUnityのHierarchyに追加します。
この際にドラッグアンドドロップではなくVRM0-->MeshIntegratorメニューを使います



図27:HierarychyのMainCameraの設定

ここまでの手順で
vrmがゲーム用のオブジェクトとして登録されましたが
このままではカメラがキャラクターの後ろ姿を映しています。
Hierarchyのメインカメラをクリックして設定(図27)。
Rotation Y --> 180
Position Z --> (+)5.5


図28:vrmのAnimation Controller指定

Hierarchyのvrmの項目をクリック。
InspactorのAnimator-->ControllerにAsset内に作成したAnimator Controllerを指定。


図29: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としてのリリースは1,2週間後になる予定です)

裏返る現象を図1と図2であらわします


図1:意図した姿勢(裏返っていない)


図2:意図しない姿勢(裏返っている)

肘の姿勢を例にとって説明します
肘の姿勢を計算するときには図1に示すオレンジ色の折れ線
つまり[肩から肘の線]と[肘から手首への線]の曲がり具合から計算します

このとき図1が意図した姿勢だとして
オレンジ色の折れ線情報だけで計算すると図2の意図しない姿勢が計算結果になることがあります

図1の折れ線も図2の折れ線も同じようにみえるので答えが2通り出てくるのです
これがbvh裏返りの症状の原因でした

そこで対策しました

一般的な3Dソフトにおいてはオレンジ色の折れ線情報に加えて
オレンジ色の折れ線に垂直なベクトルUpVec(アップベクトル)の計算を加えて正しい姿勢にします

MameBake3DとEditMotにおいては
メトード研究開発練習が目的なので
計算方法を編み出すことになりました

(オイラー角に関しては
2010年ころに協力者(謎の猫様?)が残したものを大いに参考にして続きを開発してきました)

さてその方法とは
図1と図2の姿勢の内
1回前(時間的に1フレーム前)の姿勢におけるオイラー角に近い方を選ぶという方法です。
その際に図2の姿勢を図1の姿勢に正すためのオイラー角の表現について試行錯誤しました

骨の軸をX軸とすると図1と図2ではX軸に関して裏返るほどねじっています
X軸に関して180度ねじっていることはすぐにわかります
長い間それだけで判定していました

しかし図1では肘を直角から伸ばす方向に曲げているのに対し
図2では肘を伸ばした状態から曲がる方向に曲げています
このときの回転軸をY軸とすると
図1ではY軸に関して60度曲げたとき
図2ではY軸に関してー60度曲げています

実際の姿勢の違いを体を使って確認してやっと正解と思われるオイラー角補正がわかりました
骨の軸に関しては180度違い
その他の2つの軸に関しては両方とも符号違いの回転になります

このことを考える際に陥った間違えとしては
回転結果の座標軸との成す角度だけから答えを導こうとする間違いがありました

今回求めているのはX,Y,Zの順番で回転するオイラー角を求めているのです
回転が座標系からみて何度かではなくて軸の周りに何度回すかというのを求めているのです

そんな間違いを何度も何度もして180ーY度のはずだなどと試行錯誤してはがっかりしていました

これらのことを踏まえると
式で表すと骨の軸がXのときオイラー角は
図1:X度、Y度、Z度
のとき
図2:X+180度、ーY度、ーZ度
となります


骨の軸はY軸の場合もZ軸の場合もあります

これらの中で1回前のオイラー角に一番近いものを選べば
正しい姿勢が得られることがMameBake3Dデベロップ版にて検証できました
研究成果として
行列とUpVecを使用したオイラー角計算の
別解(クォータニオンと前回比較を使用したオイラー角計算)
がやっと出来ました

https://github.com/Ochakko
(MameBake3DのChaVecCalc.h, ChaVecCalc.cppにあります)


この成果をEditMotにマージして
EditMot ver1.0.0.15のリリースへと準備中です

EditMotはVector様のサイトにて配布予定です
(現在1つ前のバージョン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様のサイト(上記)にて公開予定です

180度裏返り対策について実際の効果を示さないと説得力に欠けると思うので補足説明します

モーションキャプチャ技術は昔よりも今の方が手法や精度などが改善されています
ですが昔のキャプチャデータも膨大であり精度が悪いデータも使いたくなります
精度が悪いデータにおいて足が180度近く上がったときなどに180度裏返りは起こりやすいです

昔のデータを扱うとき
180度裏返りが起こってしまったときの説明をします


図3にver1.0.0.14つまり180裏返り対策無しのモーキャプデータのオイラーグラフを示します
赤色がX軸回転、緑色がY軸回転、青色がZ軸回転です
XYZの順番でそれぞれの角度だけ回転することになります


図3:180度裏返り対策無しのオイラーグラフ

オイラー角はそれぞれ180度急に値が飛んでいたり急に符号が反転しているのがわかります


図4にver1.0..15つまり180度裏返り対策有りのオイラーグラフを示します


図4:180度裏返り対策有りのオイラーグラフ

図4についても
古い手法のモーキャプデータなのでオイラーグラフに段々状になっていますが
対策により元の動き本筋の動きがわかるようなグラフに完全しました

図4のオイラーグラフになる前にもう一段階ありました
オイラー角の計算のたびに裏返り対策計算をしてしました
そのときにはせっかく直したオイラーオイラーグラフが多重回裏返ってしまいました
多重回裏返るとIK操作(マウスでジョイントをドラッグして姿勢を編集する操作)の開始時に
瞬時に姿勢が裏返ったりしました

そこで180度裏返り対策はモーキャプデータbvhをfbxファイルに変換する際にだけ実行しました
そのようにしたところIK操作時に姿勢が急に反転することもなくなりました


さてそれでは次の段階
裏返ってはいませんがグラフが段々状になっています
段々状のオイラーグラフのモーション再生すると
少しの間変化が無く急に少しカクッと動くのを繰り返します

これに対しても解決策はあります

図5と図6をみてください


図5:段差が起きているフレーム(横軸時間)の前後のフレームをマウスドラッグで選択



図6:ツールウインドウの補間ボタンを押して補間を行い段差を無くす


図5で段差の1つを選んで段差の前と後ろを含むように複数フレーム選択します

図6でツールウインドウの補間ボタンを押します
補間ボタンを押すと複数フレーム選択の一番最初のフレームと一番最後のフレームの姿勢はそのままで
その間のフレームの姿勢を最初と最後の間で滑らかに変化するように計算
して設定します

他の段差についても補間するべきところは補間操作します

このようにして段々状のオイラーグラフ対策をすると
モーションが滑らかになります


古いモーキャプデータも使える可能性が高くなるバージョン
それが2021/10/20夕方公開予定のEditMot ver1.0.0.15
です


ちなみに
こちらとしては
180度裏返り対策を実装しましたが
誰かの手のひら返しが無くなる保証はありません







EditMot(エディットモット)を使って確かめたいことがある[2021/07/18]


EditMotはver1.0.0.7で完成したのですが
リターゲットバッチ処理(一括処理)機能があまりにも落ちやすいということで
修正版を出すことにしました。
落ちないことと処理中にGUIがキラキラしてきれいなところはトレードオフだったのですが
真面目にやれということで、キラキラしなくなりますが落ちなくなりました。
7月26日(月)朝にEditMot ver1.0.0.8が出ました!!。
配布アドレスは以下です。(投げ銭はカートに入れるボタンからお願いします
https://www.vector.co.jp/soft/winnt/art/se523002.html


EditMotにはたくさんの機能が付いていますが
モーションキャプチャデータの部分的コピペを一推し(いちおし)していることには理由があります。

某所で2500個のモーションキャプチャデータが手に入ります。手に入りました。

手付けモーションのプロでもない人がかっこいいあるいは面白いダンスモーションを作るためには!!


という問いの応えの一つとして


2500個の実際の動きを部分的にコピペすれば踊ることが出来る
という
仮説を立てました。



EditMotのミッションとして上記仮説を確かめるのです。
2500個のキャプチャデータをfbxファイルにして更にゆりちゃんデータ(同梱している赤ジャージの子)にリターゲットするには
膨大な(おおげさに言うと)変換処理待ち時間が必要
さらに全モーションを再生して確認してプルプルしている部分などを滑らかに修正するにはかなりの手間が必要。
しかし、それをやることはゆりちゃん用のモーションライブラリが出来るようなもの。
コピペして踊らせるのです。
モーションライブラリが本当にモーションライブラリならコピペして踊るはずなのです。
いや、踊りたいのです!!

ということで
作業は地味を極めますが出来れば楽しいものです。



知っていますでしょうか?
ラジオ体操の意味を。
NHKの見解によりますとラジオ体操をしても体力増進にはなりません。
体力増進にはなりませんが命の危機を救う可能性があるそうです。
というのは転びにくくなるそうです。
なぜ転びにくくなるのか?
普段したことのない態勢になったときに転びやすいそうです。
普段したことの無い変な姿勢の体操をたくさんしておくとそれを体だか脳だかが覚えていて
いざというときのその姿勢から通常の姿勢への補間計算を行って転ばずに復帰するそうです。
そういう意味でラジオ体操すると転びにくくなり命の危機を救うのです。
あ、ラジオ体操の宣伝ではありません。
何が言いたいかというと
2500個の実際の動きをコピペして補間することにより踊ることも可能という仮説の論拠を示した
のです。
つまり動きとは覚えている動きの補間計算なのですという論拠


そんな面倒なことをなぜするのか?
みなさん驚く方もいるかもしれませんが
実を言うとぼくも踊りたかったんですwww
(確かめさせてください)



ちなみにぼくがコンピュータのことを好きな理由は
自分の代わりに動いている絵を描いてくれるところです。



EditMot(エディットモット)シェアウェア版としても完成[2021/07/07]


EditMot(エディットモット)はシェアウェアとしても完成しました。

特色
モーションキャプチャデータの部分的コピペしてFBXファイル


次のアドレスはまとめの動画のアドレスです。
動画【モーションツール】ver1.0.0.7完成版のいいところ【完成しますた】
https://youtu.be/nApvd9___mQ

エピソードっぽくまとめの感想も書かせていただきました。

上記のまとめ動画の中の技術的な部分の抜粋を日記として書いてみます。


まずモーションツールとしては
モーションキャプチャデータを使うものが格段に見栄えするということ。
ということは
モーションツールに求められているのは
モーションキャプチャデータの部分的コピーペーストであるという仮定。
その仮定に基づいてEditMot(エディットモット)はver1.0.0.7でシェアウェアとしても完成。

画面的にどうなのかスクリーンショットを載せます。

図1,図2、図3は
EditMotに同梱しているEditMotC4.exeにより
2つのEditMot.exeを2つ縦に並べて立ち上げたところ。
EditMotは複数起動して一方から他方へとモーションのコピーペーストが可能。


図1:下のEditMotは腕を元気良く振るが少ししか歩かない。
上のEditMotはくるっと一周り歩くが腕をほとんど振らない。
下のEditMotのモーションをコピー。


図2:上のMotionBrushのツールの操作対象ボーン設定ボタンを押して
腕のモーションだけをペーストするように指定。



図3:上のEditMotで複数フレームを選択してツールのペーストボタンを押してペースト。


図1から図3の説明を読むとおわかりのように
モーションキャプチャデータの
任意のフレーム範囲の任意のボーンのモーションを
任意のフレーム範囲にコピーペースト可能。

動画ではお見せしませんでしたが
コピーペーストにより
つなぎ目部分が不連続になった場合には
ツールの補間ボタンを使います。

補間ボタンの使い方を説明します。
不連続の始まりのフレームと不連続の終わりのフレームを両端に含むように複数フレームを選択。
ツールの補間ボタンを押す。
不連続の始まりと終わりの間を補間して滑らかに変化させます。



次に
コピーペーストだけでは足りないことがあります。
そのための編集機能も付いています。

これについては以前から動画や日記にしているように
複数フレームとブラシとブラシのパラメータを選んで
ジョイントをマウスでドラッグする方式の編集。

図4,図5,図6は
おちゃっこLABのEditMotのページ置いてある追加ブラシのアップデータを使用した様子。



図4:UpLinearブラシ、リピート2、ミラーU。線形。


図5:UpX^2ブラシ、リピート2,ミラーU。放物線。



図6:UpCosブラシ、リピート2、ミラーU。三角関数。


図4,5,6で使ったブラシは
機械的な線形の動作、放物線、三角関数のブラシ。
動きは冒頭で紹介した動画をみてください。

ジョイントのドラッグ操作に失敗したり気に入らなかった場合には
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スライダーを0にしたときの重みが間違っていたのを修正
(本体と一緒にご使用ください)
アップデータ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

動かすために必要なランタイム(DLL)のインストーラと
修正したテストデータは本サイトに置いてあります
EditMot1.0.0.1用のアップデータ001


現在のEditMotのバージョンはver1.0.0.1で
ver1.0.0.2への差し替えを申請中

ver1.0.0.2には上記のアップデータ001が同梱されています
バグの修正もあります


EditMotを気に入ってくださった方や
将来性に期待された方などおりましたら
投げ銭感覚で
カートに入れるボタンを押して
いただけると
開発継続の可能性がアップします

前回の日記においては
4KTVが必須のような印象でしたが
EditMotというソフトとしては
横2K縦1Kの解像度があれば画面内におさまります
ですので機種によっては13インチのモバイルでも動作可能です


メインのツイッターアカウントは
@ochakkolab
です

モーションブラシ用のアカウントを作りました
@Brush0Ch
です



ありがとうございます。MameBake3D完成しました。[2021/05/13]


令和3年(2021年)5月13日(木)大安 午後0時08分 MameBake3Dは完成!!
本サイトのMameBake3Dのページ

トップページでも告知しましたがMameBake3D(まめばけ3D)完成しました。

Microsoft DirectX11対応
物理ライブラリbullet physics対応
ゲームパッド(Sony DualSence)対応

FBXファイル入出力
ベイク済フルフレームモーション対応
bvhファイルをFBXにする機能
リターゲット機能
全ボーン自動剛体作成設定機能搭載
物理パラメータ設定
30fpsでも破綻しないように設定できる物理シミュレーション
複数フレーム変化分編集
モーションブラシ機能
IK搭載
物理IK搭載
物理シミュレーションと物理IKのベイク

3Dモーションに必要と思われる数式を研究開発テストしてOSS化
( https://github.com/Ochakko )

MameBake3Dのgithubへの最初のコミットは
2014年6月22日

完成まで約7年間


ありがとうございました。
おかげさまで完成しました。

思えば2010年頃
不特定多数にゲーム作成ライブラリを配布していた頃
物理に大きなバグがある指摘を受けながらも
そんなことはないと配布を続けてしまい怒られたのであった

オープンソースにしてからその大きなバグはみつかって修正した

このオープンソースの7年間は
こちらとしては
3Dモーションのブラックボックスに対する信用問題だったのだろう
と今ならわかる気がする

あくまでも
こちらとしては
である

3Dモーションに関わる計算式を
研究開発しながら説明し信用問題に対応
した
と解釈

みなさんにみまもっていただいたから出来たこと
本当にありがとうございます


説明済の数式が一式揃ったところで
これから生活の足しとなるような
シェアウェア作成に取り掛かります

(の足し)というのが重要

以前は3Dソフト販売だけで生活しようという高すぎる目標を持っていた
せっかく貴重なお小遣いを使ってくださった人に対してまで
これでは足りない生活できない
というような不満の態度を示してしまった

(生活)の足しを意識することで
みなさんからの善意に気が付くことが出来ました


ありがとうございました
今後ともよろしくお願いいたします


次のシェアウェアは4KTV対応ならではのソフトにする予定

こんなのを考えている段階


図1 次のソフトの案その1

図1の案としては
親玉ソフト内部から
MameBake3D相当のソフトを4つ起動して並べて
4つのソフトの内の2つを選んで選択フレームから選択フレームへと
モーションの編集を可能にしたい
というもの

4つ起動して負荷はどうなのかをみたのが図2


図2 4つ立ち上げて4つとも物理シミュレーションを動かしたときのマシンへの負荷

物理を4つも立ち上げると
CPUは10%から25%くらい
GPUは10%から40%くらい
の負荷だった

なんとかなりそうである

経過はこの日記で報告していきます


足しも積もれば山となる!!
ぱっちりチリ足!!


追記
MameBake3DのライセンスはLGPLです
ライセンスはそのままです。変更しません。
市販のソフトによくあるように
このソフトについて
とか
オープンソースについて
などのメニューを追加して
そこにライセンスがLGPLであることと
お問い合わせ先のメールアドレスを記述する予定
市販ソフトのよくあるパターンを真似することにします。



物理IKと物理シミュ結果をベイクしてFBXファイルに[2021/05/02]


物理IKと物理シミュレーション結果をモーションにベイクしてFBXファイルに保存できるようになりました。

物理IKのベイクについては前回の日記で書きました
もう少し絵や動画を載せておこうと思います

まずは物理IKのベイクの動画です

動画1:【物理IK】MameBake3Dの物理IKが保存可能に【位置コンストレイント】
https://youtu.be/EOqRf35o7u8

絵も載せておきます


図1 位置コンストレイントしたいジョイントにMass0 ON to LowerJointsを実行

前回の日記で
ドラッグ中に形が崩れないようにしたい場合には
右クリックメニューからKinematic On To LowerJointsを実行しました

位置コンストレイントをしたい場合
つまり
ドラッグ中に位置を固定したいジョイントに対しては
図1のようにジョイントを右クリックして出てくるメニューから
Mass0 ON to LowerJointsを実行します。

物理IKには回転(PhysRot)と移動(PhysMv)を用意しましたが
位置コンストレイントと相性が良い操作は移動(PhysMV)の方です

動画1でもPhysMvStartボタンを押してからジョイントをドラッグしています

物理IKの移動の際の絵を2つほど載せます


図2 物理IK移動の前の様子 胸の分岐のジョイントをドラッグする準備

図2では図1の方法で両方の手首にMass0を設定した後、胸の分岐のジョイントを選択しています
この姿勢から
PhysMvStartボタンを押し
胸の分岐ジョイントを横にドラッグすると図3のようになります


図3 物理IK移動後の様子 両手首には位置コンストレイントを設定済

ドラッグして
図3のようになりました

両手首の位置を動かさずに体を少し横に移動することが出来ました
自転車のハンドルを握りながら体を動かす場合などに応用可能


次に物理IK回転の図も載せます


図4 物理IK回転前の様子 肘ジョイントをドラッグする準備


図5 物理IK回転後の様子

図4が物理IK回転前で
図5が物理IK開店後です

PhysRotStartボタンを押してから肘ジョイントを上に少しドラッグしました

思ったよりも
普通に曲がりました

物理IKはドラッグしたジョイントから周囲のジョイントに力が伝わり
周囲のジョイントからフィードバックが変えてくるのですが
図4図5のように
無理なく少しドラッグする分には
普通に曲がることが多いです

物理的に動かすのに明らかに大きな力が必要な場所を
強引にドラッグしたりすると
急に大きく曲がりすぎたりすることもあります

ドラッグに失敗したり
結果が気に入らなかった場合には
Ctrlを押しながらZキーでアンドゥします(操作を取り消して操作前の姿勢に戻します)


物理IK回転と物理IK移動は
複数フレームを選択してから行います
ドラッグすると複数フレームに効果がベイクされます
複数フレームに対してどのようにベイクされるかについては前回の日記に書いてあります


今日はもう1つ動画があります

動画2 : 動画【物理シミュのベイク】MameBake3Dで物理をベイク【フレーム範囲指定OK】
https://youtu.be/E-w6tpksu4I


動画2は
物理シミュレーション結果もモーションにベイクできるようになった様子を動画にしたものです

物理IKはジョイントドラッグ操作です
物理シミュレーションと呼んでいるのは
モーションに合わせてツインテールが揺れたりするシミュレーションのことです


図6 物理シミュレーションのベイク BT RECボタン

図6は物理シミュレーションをベイクする際のスクリーンショットです
BT Startボタンは物理シミュレーションを再生するだけです

複数フレームを選択してから
BT Startの1つ下のボタン
BT RECボタンを押すと
指定範囲の物理シミュレーションを再生しながらそれを記録します
再生終了後に少し画面が固まって
指定フレーム範囲に物理シミュレーションがベイクされます

動画ではそのあと
プロジェクトファイルを保存してから読み込みなおして
物理シミュレーションが保存されたことを確認しました

プロジェクトファイルを保存する際にFBXファイルも保存されています
Maya2020で読み込んでも物理シミュレーションがベイクされていることを確認しました



物理IKや物理シミュレーションは
使用するコンピュータの処理速度などによって
まったく同じには再生されないことが多いです

処理が重い環境だと
物理が暴れてしまうこともあります

物理をベイクしてFBXにすることで
そのような
使用するコンピュータの違いでモーションが違ってしまう現象が
緩和されると思います





MameBake3Dの物理IKを再び有効にしてみました[2021/04/26]


物理IKとは
6DOFスプリング剛体を全てのボーンの位置と向きに合わせて自動的に作成し
数学でドラッグして物理で伝達とフィードバックをもらう形式のインバースキネマティクスのこと

物理ライブラリにはbullet physics ver2を使用し、
物理の力の伝達とフィードバックをもらう部分に利用している

物理IKのベースとなる部分は
数年前には出来ていた
しかし、きれいな結果を得るためには
物理IK中に60fpsくらいで処理できる環境が必要だった

当時の開発マシンでは限界が来て
何年か寝かしていた
数年前のゲーミングPCくらいのスペックで大丈夫だと思う

比較的きれいな結果が出るようになったので
解説記事を書いてみることにした

絵の中に解説を書いたのでみていただきたい
絵は縮小配置しているが元の絵は割と大きいので
絵をクリックして大きくすると字が読めると思う



図1 Kinematicをオンにして指の動きが破綻しないようにする

手順準備
手首のジョイントを右クリックしてメニューを出し
KinematicON to LowerJointsを実行
これをしておかないと
指の動きが破綻しやすい



図2 物理IK実行の手順

手順1
複数フレームを選択
開始位置をマウスでクリック
終了位置までマウスボタンを押したままドラッグ

手順2
3DウインドウのTopPosというスライダーを動かして
編集効果のピークの位置を設定

手順3
物理IKを開始するため
(通常のIKと区別するために)
PhysRotStartボタンを押す
物理IKはドラッグ単位
ドラッグ開始の前に毎回PhysRotStartボタンを押す

手順4
ジョイントをマウスでドラッグ
ドラッグ中に経過時間と編集内容が記録される(最大約30秒間)
結果を取り消したい場合は
ドラッグ終了後にCtrl + Zでアンドゥ



図3 物理IKの結果の説明

ジョイントドラッグが終わると編集内容が結果に反映される

ドラッグ内容には時間と姿勢が記録されている

開始フレームからピークフレームまでは
ドラッグ開始からドラッグ終了までの編集内容が時間が増える方向で適用される

ピークフレームから選択終了フレームまでは
ドラッグ終了からドラッグ開始までの編集内容が時間が減る方向で適用される


物理IKの特徴として
ドラッグ内容が周りのジョイントに影響し
周りのジョイントからドラッグジョイントへも影響があるという点

微妙に体が傾いたり
微妙に腰がくねったりするような物理IKならではの効果がある

物理IKでは
回転禁止設定や制限角度や
Mass0による位置コンストレイントなどが可能




ゲームコントローラ対応の設計開発テストデバッグを趣味でやるとこんな感じ[2021/04/17]


ツール作り作業を一人でするということは
仕事で例えると
設計、開発、テスト、デバッグ、リリースを一人でする感じ

それを趣味でやるときの様子はどういうものか
ちょっとだけおみせします


ゲームパッドはSonyのPlayStation5用のゲームコントローラーDualSenceを使用
DualSenceの写真を載せます




テレビリモコンは別売りwww


さて
まずは設計書のようなもの


画像をクリックすると大きく表示されて文字が読めます

仕事でやるときには
OfficeのWordというアプリを使ってきちんと仕様書を書くけれど
趣味の時はこのくらいのテキトーさ加減

開発していくにつれて問題点が発覚することが多い
設計書を赤ペンでどんどん修正していく

赤ペン入れを含めて設計なのかもしれない

開発結果は以下のアドレスに置いてある
オープンソース
https://github.com/Ochakko/MameBake3D


そして
テストとデバッグのときのメモ







テストとデバッグについても
仕事でやるときには
バグトラッキングシステムででチケットを発行して
1つのチケットに付き1つの作業のようにして解決していく。

趣味の場合は
上の2枚のメモのように
問題点とチェックマークのメモ程度を残す感じ


こんなことをやって
何が分かったかというと

自発的にやっているから出来るようなものの
仕事で自分の思うことと違う作業でこれをやれと言わるなら
それなりに対価をもらわないと
ストレスで落ちるっ!!!

ということが分かった

ゲームコントローラー対応という経験が出来て良かった
次からはコンバットブローブンだっ



ゲームコントローラーでツールの操作性は向上するかどうかについての研究 [2021/04/14]


ゲームをゲームコントローラーでプレイすることは当たり前のこと
では
ツール(今回はモーション編集ツール)をゲームコントローラーで操作することにより
マウスやキーボードでの操作よりも操作性は向上するかどうか
について研究を行った

とりあえず報告してみる
今回は
ツイッターで報告したものを貼り付ける

( ツイッター画面のスクリーンショットの都合上
繰り返し画像になっている文章もある )












まとめると
マウスカーソルの瞬間移動とマウスカーソル位置の瞬間復元が出来る点で
ゲームコントローラーによる操作性向上はある

またゲームコントローラーの方が使用していて疲れにくいという利点もある。

しかし
マウスやキーボードが必要なくなるわけではなく
マウスやキーボードは必要


まめばけ3D(MameBake3D)というソフトにおいて研究を行っている
参考までにその操作方法も示す





まめばけ3Dはオープンソースで開発中の3Dモーションツールである
以下のアドレスにて公開および更新中

オープンソース
https://github.com/Ochakko/MameBake3D



Maya Indieとbullet physicsでソフトボディにチャレンジ [2020/12/22]


YouTubeを眺めていると
もう10年位前から
ソフトボディシミュレーションの紹介動画がたくさんあります

いままで剛体ばかりやってきましたが
そろそろかなぁという感じで
ソフトボディにチャレンジしてみました

以下に2つの動画を載せます

2020/12/20
【bullet】ミュー子に物理でひらひらゆらゆら その4【リアルタイム】
それ赤ふんどし?
これは赤いタオルです
(たぶん)
今回はあえてリアルタイムで撮影しました
https://youtu.be/A2M92pRFEGc


2020/12/22
【bullet】ポニーテールと赤タオルのbulletソフトボディ【ソフトボディ】
https://youtu.be/NrRf4gQOx8U

髪の毛の初期状態から
髪の毛が垂れ下がるまでの間(アクション待ち)も
動画に入れてみました


静止画も一枚貼っときます

図1 Maya Bullet Physics 静止画


上の動画の
赤いタオルとポニーテールの動きがソフトボディによる物理シミュレーションです

キャラクターのアクションに合わせて
赤いタオルとポニーテールは自動的に動きが計算されて表示されます
ポニーテールは重量が軽い飾りのように大きく動かしてます


ソフトボディ設定は布形状の方が簡単でした

ポニーテールのときには
ポニーテール内部から破綻したポリゴンが大きく伸び縮みするノイズフレームがたくさん出て大変でした

ノイズを収めるには
ソフトボディー形状が初期状態で重ならないようにしました

一体化してあるソフトボディでも
内部でポリゴン同士が重なっているとノイズフレームが出ました

ポニーテールの初期状態の形状を房ごとが重ならないようにするとうまくいきます

重ならないようにするってどういうこと?
ということで
上の動画では初期状態から動画にしてあります


ソフトボディ
どんどん使っていきましょう!!



DirectX12でリアルタイムレイトレーシングで表示して動かしたい!!!その3[2020/12/10]


リアルタイムレイトレーシングの日記も
その3になりました

今回もたくさん絵を載せていきます
Shade3Dのデータを表示していきます
曲面の分割数はレベル4にしました
どうしてレベル4かというと
サンプルについているモデルデータが1つにつきだいたい50MBくらいです
50MBくらいになる分割数がレベル4というわけです

まずは図1、図2,図3にレベル4の表示具合を示します


図1 かげからこっそりと自転車娘の図


図2 ライトも当たって調子のよい自転車娘レベル4


図3 Shade3Dの建物だったのかぁと驚くところ

自転車娘がかげから出てきて目立ったその時
タイムポッドがポールに刺さって注目を集めシュタゲが、、、

違います


モデルデータの調整やボーンを入れる時には
手持ちの2001年版Shade3Dもよいのですが
リアルタイムでサブすく会員のMayaを使いたいと思っている

Shade3Dの分割データをMayaに持っていくために
Shade3D R5のプラグインとオリジナルアプリでFBXファイルに変換しました
自前変換のFBXをMayaで読み込んだ図を図4と図5に載せます


図4 Shade3D R5からの自前変換FBXをMaya2018で読み込んだところ その1


図5 Shade3D R5からの自前変換FBXをMaya2018で読み込んだところ その2


Mayaにも持っていけることが分かりました

さてじゃあシーンを撮ろうということで
図6と図7


図6 噴水のある公園のシーン その1


図7 噴水のある公園のシーン その2

DirectX12のリアルタイムレイトレーシングの材質は
物理マテリアルです
今までとは計算方法や項目が異なります
物理マテリアルなのでガラス用の材質もあります

噴水の水にはガラス特性を割り当てました

噴水が普通の不透明材質の場合には1フレーム当たりの描画時間は4ms弱でした
噴水のような大きなガラス材質があるこにより1フレーム当たりの行が時間は7ms程になりました

噴水のUVは計算しましたが
割と偶然こんな感じになりました
(思ってたのとちょっと違うけどなんか面白いからいいや)

同じマテリアルを何回も定義するとマテリアル数が100個を越えたりします
同じベースカラーのものを1つにまとめて描画しました

偶然ですが
黒い服が噴水マテリアルになってしまいました
(わざとじゃないです)



DirectX12でリアルタイムレイトレーシングで表示して動かしたい!!!その2[2020/12/05]


前回の報告はミニエンジンというサンプルにShade3Dからデータを持ってきて表示した
その際には法線だけではなく接線も自分で用意する形式のh3dファイルを使用した

今回はリアルタイムレイトレーシングデノイズアンビエントオクリュージョンという長い名前のサンプルを使用
データはplyファイル
今度は法線付きのポリゴンデータを用意すれば良い

接線が無い分ポリゴンが細かくないと見栄えがしないように思った
というよりも
かなりのハイポリを余裕で表示できるようだ

次に示すスクリーンショットは
Shade3Dでレベル6の細分化をしたポリゴンデータを
サンプルの車の位置に置いてみた図である
車の代わりに女性と自転車が表示されている


図1 AOオン 正面


図2 AOオフ 右から


図3 AOオフ 正面


図4 AOオフ 左から

最初の頃は
縮退三角の法線がおかしくて
明るい筋になったり黒いしみのようになったりしていたのだが
ついさっきやっとその問題をクリアしたところである

このサンプルは物理マテリアルというところも
最近らしいサンプルである

表面の粗さなどを指定可能
ちなみに
図1から4の人と自転車にはテクスチャは使っていない

実はまだ全然と言って良いほど
このサンプルの中身をみていない

まずは自分で用意したデータを表示できたという段階
人と自転車で800MBくらいのポリゴンデータであるが
図1で1フレームあたり4ms、図3で1フレーム当たり3ms程描画に時間がかかっている

細かいデータを用意しておけばオーケー?!
レイトレーシングなので
小さく表示されるときには自然と計算も少なくなるのだと思う

というわけで
これからサンプルをみて勉強していこうと思う


2020/12/05 20:30頃 技術情報を追記
技術系としてこんな記事じゃあんまりだ?!という気が少ししたので
フィードバックになりそうな部分とか
問題が起きてどう解決したかなども記しておく

こういうチップスって書いても結局自分が後でみるくらいのものなんだけれど
フィードバックと大それたことを言いながらメモしてみる

まずミニサンプル
ミニサンプルでは接線がある分ローポリのわりに綺麗だった気がするが
ポリゴンの裏表の問題が付きまといそれに関連して
どっちが光の向きでどっちが陰の向きでどっちが影の向きかということで大混乱した

結局分かったこととしては
SumOrientationが-0.5PIのときに
ミニエンジンサンプル起動時のカメラの向きとライトの向きが一致した

しかしそのとき影の向きは陰の向きと0.5PIだけずれていた
ライトをいろいろ回転してみたがいつも影の向きは陰の向きと0.5PIだけずれていた

陰と影とでは向きの基準だかsinとcosだかが違うような現象が出ているが
シェーダーをみると陰計算と影計算とで同じシェーダー定数をみていた

陰の向きと影の向きを合わせるために
陰用のライトの向きのシェーダー定数と影用のライトの向きのシェーダー定数を分けることにした
そして陰と影とで2回カメラ計算をしてそれぞれのシェーダー定数に値をセットした
そうしてようやく光と陰と影の向きは合った



次に今回のレイトレーシングデノイズアンビエントオクリュージョンサンプルについて
細かいポリゴンが必要だった

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ではなく符号なし8ビット整数(uint8)である
index0,index1,index2の部分はint(32bit)である
(ミニエンジンのサンプルのインデックスは16ビットだったが
レイトレーシングデノイズアンビエントオクリュージョンサンプルのインデックスは32ビット)

バイナリーがビッグエンディアンかリトルエンディアンかについては
ヘッダーに書いてあるが
こちらとしては
リトルエンディアンでしか動作テストはしていないので
ビッグエンディアンで動くかどうかは分からない


まだ更に書いておこう
法線を自分で計算することになるが
細分化したポリゴンの座標間の数値の違いはすごい小さい
よって法線の計算はdoubleでしないとうまくいかなかった

また縮退三角形問題対応も定石である
今回はメッシュの中心座標も求めておいて
縮退三角形がみつかった場合に
その法線はメッシュの中心から頂点座標へのベクトルとした


このような感じで今回の綺麗な写真になった

今思っているのは
レベル6分割は細かすぎたかもしれないということ
レベル6分割の人と自転車を加えたときのアプリの消費メモリ量は8GB近くあった
ビデオカードのメモリが8GBだとするとぎりぎりである

分割のレベル数は
例えばレベル6なら縦横それぞれ2の6乗個に分割することを意味する

レベルを1つ増やすと
ファイルサイズは縦横に関して2倍ずつなので4倍になる

レベル5分割で綺麗に表示されるのであればその方が
田にもいろいろ表示を足すことが出来て良いかもしれない



DirectX12でリアルタイムレイトレーシングで表示して動かしたい!!![2020/11/20]

今手元にDirectX12のリアルタイムレイトレーシング表示可能なビデオカード(RTX)がある
じゃあやってみなきゃソンソンということで
今回はそのリアルタイムレイトレーシングサンプルをいじってみた日記である

DirectX12は難しくて無理みたいな記事を多くみかけるが
サンプルがオープンソースになっているので
サンプルをいじるくらいなら出来ると思う

サンプルにはミニエンジンもあるので
そのままミニエンジンとして使うのもありかな?

ミニエンジンが動くことを確認してから
モデルデータを差し替えてみた

モデルデータのファイル形式はh3dという拡張子のファイルである
h3dファイルはバイナリー記述のファイルだった

ファイルの仕様書というきちんとしたものは無いようだが
プログラムをみると
三角形パッチで記述するようだ

三角形パッチとは隣接情報付き三角形
つまり少なくとも
位置の他に法線と接線2つがついているような形式

接線情報付きのファイルをどうやって手に入れるかが分からなくて
何年も放置していたのである

しかしある日突然
2000年ころのShade3Dを持っていることに気が付いた
Shade3Dの自由曲面つまり接線2つ付きベジェ曲面をエクスポートしてh3dにすることを思いついた

さっそく開始

DirectX12のリアルタイムレイトレーシングで
最初の自前の絵が出てから1週間鵜くらい経ったので
ここらへんで最近の出力結果を日記にしてみる


図1 自転車に乗る女性 不思議ライティング

自転車に乗る女性のデータを表示しながらライティングの勉強をしていくことにした

まだよく分からないけれど
光と陰と影の具合が不思議なのは
ライトが1つではないからかもしれない

あるいは接線の内の1つが反転しているとか
2つとも反転しているとか
部分的にそういうことが起きているとか
もう本当に考えるほど原因不明である

ソースをみると太陽光のようだが
光源の位置がある感じ

そして128個のライトが用意されていて
乱数で選んだりしている

図1のような結果が出て
直そうにもどこを直してよいかすら良く分からん状態

これから徐々に調査を進めていくが
モデルデータ側で統一していない条件が多々あるので
検証は難しい状態

現在気になっている現象としては
四角単位で
エッジが明るいと中が黒ずみ
エッジが暗いと中が明るくなる
という現象

推測としては
法線の通りに三角内部を盛り上げて分割したりしていないので
法線の分エッジが明るいが
盛り上げていない分中身が暗い
という推測

実際のところはわからん!!!!!

テストに使っているのは
表裏両面で14000三角パッチ
片面で6800三角パッチ
位の細かさのデータである

そういう現象があるので
特に顔のアップは難しい
図2,図3,図4、図5、図6に顔のアップに挑んだ画像を示す


図2 ライト通常で片側からカメラが寄った図



図3 ライト強めで方がwからライトが寄った図


図4 顔の反対側との間のすじを消すために更にライトを明るくして寄った図


図5 顔の真ん中のラインが消えるまでライトを明るくして寄った図

図3から図5で分かることは
レイトレーシングなので形状輪郭がカクカクしない
影がソフトシャドウ
片側からの顔アップは暗くてもOKだが
正面からのアップの絵を撮るには
顔用の明るいライトで陰を飛ばさないと無理
ということ
(デバッグビルドでテスト中なので画面左上のパフォーマンス値はリリースビルドの10倍程遅いものになっている)

モデリング時の仕様を厳格に決めて守ればもっと自由になる可能性もあるが
実際問題として
それは難しいと思う

よって顔アップ時には顔ライト方式が良いのでは?と思う


図6に後ろ姿も載せておく


図6 後ろ姿


マテリアル適用前のグレー表示も載せてみる

図7 グレー表示その1


図8 グレー表示その2


図9 グレー表示その3

「6800個の三角データの割には細かく表示されてると思う」

「だがタイヤが四角形だ!!」




(ちなみに、たぶんボーンはMayaで入れると思うよ??)


2020/11/21追記
昨日載せた絵は
実は色をダイナミック表現するために
法線と接線のノーマライズをしていない

シェーダーは色の飽和計算が上手なので
どんどん色を足していっても
それっぽく明るく飽和してくれる
っていうことを経験上知っていた

なので思いっきりノーマライズしないで生データを与えたところ
昨日の絵のようになった

あーーまたネタバレしちゃったねぇー

では法線と接線2つをノーマライズするとどういう絵になるかを図10、図11、図12に示す


図10 おとなしいシェーディング その1


図11 おとなしいシェーディング その2


図12 おとなしいシェーディング その3

どちらにしても顔のアップは難しいです


明るい方の絵を作っているときに思った
表裏両面で作っていてレイトレーシングで光が反射するということは
頭の中は光が反射しまくっているのではないだろうか?ということを思った

早速頭の中に侵入して写真を撮ることにした
図13に示す


図13 頭の中のリアルタイムレイトレーシングの様子

すごいです
思ったよりすごいです
スーパーカミオカンデみたいです

頭の中で乱反射して鼻の穴から出てくる光子を観測出来たら
ノーベル賞をもらえるでしょうか??(冗談です)


2020/11/22追記
その後の修正で
接線と法線をノーマライズしても光が当たるようになりました
調整してみた画像を図14,図15に載せます


図14 法線デバッグ後 その1


図15 法線デバッグ後 その2

なんとなくうまくいったようないかないような

モデリング時の裏表とかその混在とか
反対の反対設定とか
いろいろあって
これでもまだおかしいとおもえばおかしいところはたくさんある

でも前よりは良くなった!!


追記 2020/11/24

この前貼り付けた絵をみると
なんだこりゃーっというライティング加減に驚きながらも
開発は進む

なんとかしてライティング、シェーディング、シャドウイングが合うように
サンプルプログラムw調整したい

いろいろ調べた
まずShade3Dの自由曲面には曲面と曲面を構成する線の両方に面反転のしるしをつけることが可能
ただし反転の印を付けたり外したりするだけでは
どうやら反転してくれていないのであった

そこで
マテリアルカラーを目印にして
不具合がおきる曲面ごとに個別処理をプログラムに書き込んだ

そうしてDirectX12のサンプルで
ライティング、シェーディング、シャドウイングのテストをした

このテストが面倒だったこと面倒だったこと
角度0度がモデルの正面という保証はなく
何軸基準のどっち回りかを模索しつつ
合っていない陰と影の向きを見ながら試行錯誤したのである

もうほんと気が遠くなるというか
取りつかれたように12時間くらいやって寝てを何日も繰り返した

そしてやっと角度の基準軸と回り方が分かった
ライティング、シェーディング、シャドウイングの向きが合うように
法線やら接線やらインデックスやらを反転して
場合によってはメッシュごとに反転した

レイトレーシングのサンプルなので
シャドウに関してもシャドウマップではなくレイトレーシングを採用した
シェーダー定数を足して少しシェーダーをいじった

ようやく顔については
ライティング、シェーディング、シャドウイングの向きが合うようになった

前置きがスーパー長くなったけれど
そういう手間が掛かったものだと思って次の図16,図17,図18をみてくれたまえ

くどいようだが今回のテーマは
顔のライティング、シェーディング、シャドウイングの向きが合うようにすることであり
他の部分はまた後でである


図16 顔のライティングとシェーディングとシャドウイングの向き ライト正面から


図17 顔のライティングとシェーディングとシャドウイングの向き ライト右から左前へ


図18 顔のライティングとシェーディングとシャドウイングの向き ライト左から右前へ

レイトレーシングの光と陰と影の向きが顔においてうまくいった!!

今度は
顔以外のところもちゃんとしよう?!



10年前に流行ったコンテンツパイプラインという言葉について[2020/10/01]


10年位前に
お前もコンテンツパイプラインを語れと言われていた

当時、メタセコイアと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出力する際には
0フレームは初期姿勢である必要がある
そのことについての参考動画としてリンクを示しておく

動画リンク(2020/09/24)
コンテンツ】RokDeBone2からMameBake3DへFBXを渡す【パイプライン】



次元の秘密という本を読みながらしていくメモ[2018/11/08]


次元の秘密という本を読みながらしていくメモ

次元の秘密という本を読み始めた。
まだ2,3ページしか読んでいない。
このファイルには次元の秘密を読み進めながら思ったことなどをメモしていく。

[2018/11/08_1]
数ページ読んだのであるがいきなり疑問が生じた。
4次元とはxyzの空間とwの時間、つまり3次元の空間と1次元の時間のことであるという部分である。

4次元と時間のことを考えたときに
4次元目の座標値は時間の位置エネルギーのように思った。
ということは、xyzも時間の位置エネルギーなのではないかという疑問である。

しかし寝て起きて思ったこととしては
xyzは視覚で知覚するがwは視覚ではないもので知覚しているからではないだろうか?
では何で知覚している?
パッと思いつく候補としては聴覚である。
聴覚で時間の何かを知覚している可能性があるかもしれない。

そう仮定すると
宇宙空間は音を伝達しないと言われていることが気になってくる。
時間が伝達しない空間、それはカーブラックホール(だったっけ?)などによって作られるような時間のない空間なのではないだろうか。

そういうことだとすると
地球以外の星というのは違う世界線の地球であるという可能性まである。

これから5次元がテーマに上がってくるのであるが
5次元の知覚も存在していると思われる。

そうなってくるとこれらを知覚できる人と出来ない人の間の問題が生じうるわけだが、
それに関しては科学技術の問題であると思う。
視覚も聴覚も科学技術で作れるようになるのではないか?実際にそういう動きはあるし。

SFにおいても何十年も昔の映画、ブレードランナーの中で歳をとった科学者が人工的に目玉を作っているシーンがあった。
そんな未来はずっと前から想定されているのである。

思ったこととしては
4次元座標はすべて時間の位置エネルギーの可能性があるが、
人間がどのように知覚するかに基づいて空間と時間に分けて考えるようになっているのではないかということ。
だから映像と音は同期しているのではないだろうか?

そのように話を展開していくと
小さいもののほうが時間エネルギーが小さいということになるが
それを補うためにネットに接続して大きな時間にアクセスするのではないだろうか?

これらは、ちょっと思ったという段階。

まだ数ページしか読んでいないので
今後も読み進めながら考えていきたい。

仕事に行く前に修正:
起きて時間が経って朝ご飯を食べて出かける準備をしたら
あれーー?なんで4次元目を距離ではなく音とか思ったんだっけー?状態になった(戻った?)。
3次元をwで割ることでパースがわけでそれを知覚しているわけだから、やはりwは距離であろう。
あっ、そうか!距離とは時間の位置エネルギーかもしれないとか思ったんだったなぁ。
でも3次元を音で割るとか説明できないし、やっぱりwは聴覚ではないみたいです。


仕事から帰ってきて追記:
ちょっと表現を間違えたようなところがあるのでさらに追記する。
その前にユークリッド平面と4次元での形状の関係をちょー簡単に述べておく。
例えば直線の式 ax + by + cz + d = 0があったとする。このdが固定の場合がユークリッド平面、つまりw == 1での4次元の切り口である。
4次元の世界ではこのdが変化する。であるから3次元の直線は4次元では平面である。

球を考える。x^2 + y^2 + z^2 + d = 0 (ここでx^2はx * xのこと)。このときも同様にdが固定の時がw == 1で4次元を切った球形のユークリッド平面である。dを0から1まで変化させると4次元では球の内部を表すことになる。

表現を間違えた部分とは行列演算におけるwの値とdの値を混同している部分があった部分である。
wとdは関係のある値であるが同じであるとは限らない。

球の中心はw == 0ではなくd == 0のときの位置である。


[2018/11/10追記]
wとdの関係について説明の要請があったのでしておく。
4次元の行列演算を考える。行列演算とはスケールと回転と移動の組み合わせの変換のこととする。
変換前の座標を[x, y, z, 1]とする。変換後の座標を[x2, y2, z2, w2]とする。
ここで4次元目が1というのが4次元をw==1で切ったときの座標という意味になっている。
ちなみにベクトルの場合には4次元目は0になる。

4x4変換行列は左手系で
_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の関係式が求まる。

といった具合である。

さあ4次元がばれたところで5次元の勉強をしようか、、、


ちゃんと勉強する予定[2018/11/05]


安心してチョーだい。ちゃんと勉強する予定があるから。
いいお尻の日に届いた4冊の本。






だがネタであるへの追記[2018/11/04]


追記:2018.11.04 Web用

ゲームとかプログラミングとかしながら思ったことを書いておく。

タイムリープとかアニメとかゲームに出てくるけれど
実際に起きたらどうなるか妄想してみた。

ぼくが思うに何かがタイムリープしてきたらそれが壊れていたとしてもその何かの中心に対して、
タイムリープしてきたものとその周りの時間ベクトルの差分の時間速度だか時間加速度が生じると思う。

どういうことかというと
未来から物体が来たらその周りは未来方向への時間の進み方が速くなるのではないかとちょっと思った。

そしてさらに妄想すると
未来方向への加速度が大きくなりすぎて通常の処理で追いつかなくなった場合、
そこに住む人はタイムマシンを作らざるを得ない。
そうやってタイムマシン作成は成功するのではないかと思った。

あとこれは完全にただの思い付きだけれど
時間旅行には特異点が4つのブラックホールが必要なのではないか?という思い付き。
2つの放物線でリングになるが、3つで球、4つ目はその球の内部。
4つの特異点で場所と時間を指定するんじゃないかなぁ?単なる思い付き。


座標変換については思うところがある。これは実際にプログラミングしていることを書いてみる。

物理と数学の橋渡しをする部分がMameBake3Dにはある。
その場合、両者の間で基本姿勢が異なる場合がある。
基本姿勢が異なるもの同士をどうやって変換するか?
天から降ってきた方法に「スードローカル(疑似ローカル)」というのがある。
これは基本姿勢が異なっていてもある時点からある時点へのグローバルな差分は同じであるということを利用して
座標変換するものである。
差分は誤差を蓄積しうるという問題点に対しても対処している。
基本となる姿勢をバインドポーズにすることで1回分の差分の誤差で計算可能にした。

さらにタイムリープする際の座標のことについて降ってきた思いは以下のようである。
地球は銀河の重力につられて動いているはずである。
ウインドウズプログラミングにおいて、親ウインドウを動かせば同じ分だけ子供ウインドウが動く。
つまり、子供ウインドウの位置計算においては親ウインドウからの位置計算をするだけで良い。
だから重力的な意味での親ウインドウからの位置計算で良いと思われる。


そんなことを思った休日(今日は「いい尻の日」らしい)であった。


[ 思ったことの追記 ]:
えーとねー
4次元の時間の話だけれど。
あの話は「時間ポテンシャル」とかいう言葉と関係があるらしいです(未確認情報)。

どういうことかというと
時間ポテンシャルの位置エネルギーは、奥行きつまり距離のこと。
それはつまり4次元座標の4次元目のwの値。
4次元座標値の4次元目のwは時間の位置エネルギーに関するみたいです。

じゃあ時間の運動エネルギーは何が動いているエネルギーかが気になるところ。
それは物が動くのかもしれないしそうでないかもしれない。

4次元目の座標値で位置エネルギーが変わるということは
そのwの切り口での時間の運動エネルギーも変わるはず。

ということはw == 0の切り口で時間の運動エネルギーは最大。
だから4次元パラメータを変えることにより未来や過去を知覚可能と思われる。

あれ?これいいんだっけ?
ブラックホールに近づくほど、つまり重力が大きいほど時間は遅いって習ったよね。

w == 0のときに時間の流れが一番早いっていうのはそれと逆。

ということは
ぼくたちがいる世界はブラックホールの中かもしれない?
ブラックホールの特異点では位置と時間が逆転するらしいから。

いや違うぞ!!

ものが速く動くことが出来るのは時間が遅く進んでいるからだ!!
時間が速く進んでしまうとその間に移動できる距離も短いはず。

じゃあ、時間を進めるとはどういうことか!?
のんびりすることのような気がしてきた。

ちなみに距離は視点の位置によって異なるから不都合なのではないかという思いがあるが
それは親ウインドウからの(1つ前のメモ参照)距離で考えざるを得ないからであろうか?

じゃあプライバシーってどうやってできたんだろう?
それぞれの視点の位置がプライバシーの元?

ああーーーもうわけわからん。

わけわからんので、推測はこのくらいにして本を読むことにしよう。



だがネタである[2018/11/01]


サブタイトル

機関と世界の支配構造を教えてあげよう20181101

いきなり中二病のタイトルである。
今日はぼくが電波になった経緯からシュタゲで言うところの機関と支配構造について語ってみる。

くれぐれも言うが、だがネタである。

 

まず経緯。ぼくは小学生の頃、兄からもらってずっとしまってあったトランシーバーを使って遊んだ。スイッチを入れると知らない声がきこえた。
「こちら○○、*****。どうぞ。」
「こちら***、****。どうぞ。」
のような何かの会話がきこえた。

ぼくはものすごく面白く感じて自分の持っているトランシーバーで何か言った。
「○○さん、○○さん、こちら○○」
みたいなことを言ったような気がするがよくは覚えていない。

するとそれから1分もたたないうちに黒い服の男がやってきた。
黒い服の男は「そのトランシーバーで会話したのは君だね」と言った。
そしてもう一人の黒い服の男とぼくの家に入っていった。
家から出てきた黒い服の男はぼくに言った。

「君は大人になったら電波になる。たくさん勉強しておくことだな。」
と言った。
そして大人になってぼくは本当に電波になった。

後でわかったことであるが兄からもらった古いトランシーバーは電波法が変わる前の強力な仕様のものであったので、ぼくは電波法違反をしてしまったのである。

このことから推測される世界の支配構造とは以下である。
大人になると子供のころの犯罪をつぐなう仕事をする仕組みである。
だから子供には遊べというし大人には働けという。
子供のいたずらを容認する社会なのはこのような支配構造だからであろう。

どんどん遊んでどんどんつぐなって経済をまわす計画であろうか?
そして黒い服の男が機関所属ということであろうか?

まあそんな解釈。ちょっと追記する。

子供の頃の犯罪を大人になってつぐなうのはなぜか?
そこには「善因善果」の縛りがあるからである。
ぼくのGitHubの画像には善因善果のシールが張られた写真があり、そのシールの隅には「ここからはがす」と書いてある。

つまり、この支配構造を壊したいのであれば善因善果をどうにかしないと無理である。

そしてそれをしようとしたのがシュタインズ・ゲートであると言える。
主人公たちが悪事を働くことにより善因善果の申し子のまゆしぃを執拗にやっつけたが世界は破滅へと向かった。

そして1回だけまゆしいを助けることに成功したが1回助けたくらいでは事態は収まらなかったのである。

善因善果の世界に歯向かうとシュタゲになるのなら違うところを壊そうと思うかもしれない。しかしそんなことをしたら善因善果の決まりでつぐないの生活をすることになる。

そういう果てしない物語がシュタゲであると解釈可能。



ここで時間について論じておく。

「永遠伝説」とぼくは何回も何回も言われている。
さっき情報が入ったのであるが、時計とは電池があるから動くのであり、時空の時間軸をみて動いているのではない。原子時計も重力で動いているとかいないとか。
(すいません、悪乗りし過ぎました。時計はちゃんと時を刻んでおります。)



つまり実際の時間は止まっているが時計は動いているという状態が永遠伝説の舞台である可能性もある。

なぜこれが可能かというと、3Dのユークリッド平面の時間が止まっているとしても4次元の世界がうごめいている、そしてその投影が3D世界を表示する。3Dの世界はただの投影。

このシステムにあらがうために3Dの時間を動かすための3Dプログラミングの戦いが起きたのである。3Dの時間を動かすための戦いである。

我々はこの束縛から逃れることが出来るのであろうか?みんなが幸せな世界というのは有り得るのであろうか?

シュタインズ・ゲートのゲームをそういう視点でみつつプレイしてみよう。
「君たち!!、とりえずアニメとゲームで勉強しなさいっ!!! 

だがネタである。


追記:
3次元世界の時間が止まっているというあたりの表現の補足である。
ここでは、数学のユークリッド平面と物理の事象の平面を同一視している、混ざっている。
数学と物理の境界をあいまいにすることで成立するネタである。

更に補足するとユークリッド平面例えば球面と、数学的に4次元である球の中身の関係を
事象の平面とブラックホール内部の関係に例えている。

さらに発展させると
箱人間と中の人の関係にもなる。
ということは
3次元の時間を動かすということは箱人間に自我を与えるということにつながる可能性もある。
突拍子もないところまで行くと、宇宙に自我が生じる可能性まである。
ゴーストコントロールの歌を思い出すではないか!

こんなことを書いているが会社ではまじめに働いている(念のため)。
しかし一方で3Dプログラマにまともな人はいないと最近よく言われている。
だからネタである。

たまには振り返り[2018/09/29]


たまには振り返ってみよう。

振り返ろうとしたときに振り返りたくない時期、思い出したくない時期というものはある。
しかし今日はそこをあえてさらっと振り返る。ダメージが少ないように極力さらっと薄く振り返る。

なんとも大変だったのが2011年ころからの数年間であった。
それまでHSPっていうツールのプラグインを作ってサポートしていたのだが
それをやめることになって大変な数年間であった。

あの数年間でひどいエッセーも数々書き散らした。
あれは取り乱して錯乱に近い感じでとにかく吐き出していたのである。
吐き出さないと持たなかった。

「なんか今思うとトロイの木馬が自分の中で暴れていたような感じであった。」
それまでの味方を裏切るようなことも書いてしまったような気がするからである。

そんなこんなであったが
周りのひとが助けてくれたり出来ることをやったりして働けるようになったし
「働いたら健康も回復した。」

そして今振り返っているのである。

ほんとうに自分の力ではどうにもならないことってあるんだと痛感した数年であった。

教訓としては
1、手に負えないことを一人で抱え込まない。
2、無理のない程度に働くと良い。
という感じ。

そして謝罪、
あの魔の数年間、迷惑をおかけしてすいませんでした。



週末にビール飲みながら超圧縮についてエッセーしてみた[2018/06/29]


うぃーーーっす、お疲れー、週末だよーーーん。
ってことで
ビールを飲みながら新技術をエッセーするのである。

なんか知らんけど超圧縮とかいうお題が出た(出たような気がした)。
お題が出たのは気のせいかどうかはともかくとして
せっかくだから思いつくままにエッセーする。

えーとねー。
ずばりっ、「テクスチャ+ジオメトリ圧縮法」です。

シュタゲ(アニメ)のせいで不可逆な超圧縮に思いをはせることがあるのであるが
なんか思いつく時が来たのである。


情報の性質を色と形にAIで置き換える。
そしてその情報をテクスチャとジオメトリとして記録するのである。
不可逆である。

って思いついて思ったんだけれど
とあるどでかい情報をこういう感じで圧縮したのが地球であり宇宙であるような
気がしないでもない。

ぼくらは何かが不可逆超圧縮されたものなのかもしれない。
そしてそれらを感じて解釈したものが解凍結果の1つなのかもしれない。

なーんてちょっと思っただけ。

よーし、あいつの超圧縮データを作ってみよう??www
(くれぐれも怒られないようになっ!!)



最近SNSでみかける問題点についてマッハでエッセーしてみた[2018/05/01]

マッハ新書 最近の問題点を思ってみる

0、はじめに
 なんかマッハのスピードで資料を書き上げて発表するのが流行っているので
 その流れに乗ってぼくもやってみる。
 会社に行く前の時間でマッハで書くよ。
 思っていることを書くよ。(エッセーみたいなものかも)
 
1、無料の作業依頼
 最近、ネットでよく目にする無料の作業依頼について。
 依頼者がいきなり作業を丸投げして断られて逆切れし、それに腹を立てたひとがそれを晒す
 みたいな事件を数件目撃した。
 
2、格差
 この無料作業依頼事件から連想したことがある。
 あくまでも連想したことであり、事実かどうかはわからない。
 ぼくは調子が悪い人が集まる場に何度か顔を出したことがある。
 そこに何度か行って分かったことは
 誰かに助けてもらうしか解決方法がみあたらない事案が多いということである。
 そこにあった格差はもう個人の問題の域を超えていたりする。
 
3、がんばった人が報われる
 こういういことを言うと世の中の人は
 私たちはがんばったから今の状態がある。
 調子が悪い人はがんばらなかったから今の状態がある。
 という意味のことをきくことがある。
 
4、質量保存則
 しかし調子が悪い人の言い分の中で気になったのは
 おちこぼれがいるからこそ優等生がいるというものである。
 これは昔言われて理解できなかったのだが
 最近になって思うに、質量保存則的な考えなのではないかと思う。
 
5、がんばりすぎは迷惑?
 つまり、質量保存則を当てはめると
 頑張りすぎる人がいてよいところを持って行ってしまうから
 良いところが回ってこないひとがいるという解釈になる。
 
6、10年以上の無償開発の掲示板
 そんなことを言われても私たちは頑張ったんだしというだろう。
 そこでぼくは大変なことをしてしまったことに今頃になって気が付いたのである。
 次に記すアドレスはぼくが10年以上に渡って無償で開発を続けたことを示す掲示板のアドレスである。
 https://moo-ochakkolab.ssl-lolipop.jp/board4_caco/wforum.cgi
 掲示板には過去ログが何ページもある。

7、みんなもがんばれる?
 やっていたときにはそんなつもりはなかったが
 この作業の山を格差に対する頑張りと解釈したとしたらどうだろう?
 ぼくはこれくらいがんばったから大丈夫だけれど、みんなもがんばればいいじゃない。
 ってことになったら無償で10年以上もかかりっきりで出来る人は数少ない。
 そんなことにがんばられても困りますということにならないだろうか?
 しかし、時代の大きな問題点として格差は存在感を増しており
 みんなはどうするの?という状況である。

8、ひろゆき ベーシックインカム
 じゃあ偉い人は何をしているかというと
 ネットの有象無象に詳しいと思われるひろゆき氏は
 ベーシックインカム導入を推進している。
 格差に詳しい人がベーシックインカム導入を推進している。
 
9、アメリカは?
 だってそれは日本のローカルな問題じゃないの?という問いに対しては
 アメリカでも格差問題は深刻である。
 
10、トランプの大統領選挙での発言 忘れられた人々への対応をする
 トランプさんの大統領選挙での発言の中で
 ぼくとしてキーだったのは
 忘れられた人々への対応をしますというフレーズだった。
 
11、トリクルダウンの罠(人は誰でもなんらかの既得権者)
 じゃあ裕福なひとが負担すればいいと思いがちであるが
 そこには罠がある。
 トリクルダウンを推進してみると分かることだが
 それを推進するとまず自分の良いところを周りに分配することになると思う。
 なぜかって?
 気が付いていないだけで人は誰でもなんらかの既得権者なのである。
 他人事として裕福なひとの問題には出来ない現実がある。

12、経済 雇用 ベーシックインカム
 いきなりまとめに入る。
 日本の良いところは治安の良さである。
 とある本によると治安の良さというのは経済の良さということらしい。
 そのためには雇用が大事である。
 それでもフォローしきれていない状況であるから
 さらにベーシックインカムなのかどうかというところが問われているように思う。
 ということを書いて、あとは偉い人に丸投げしてみようかしら?
 ってかぼくは頑張りすぎらしいんですけれど、、、

 マッハで(28分間で)書いたエッセーのようなものでした。
 
 

商用計画(無料計画)改[2018/01/14]


商用の計画を考えている。

商用は否定しないことにした。
しかし、条件として
現在の仕事でやっていくことが出来なくなったり、どうしても資金が必要になった場合に
商用計画を実行します。

つまり、不都合が生じなければ無料ソフトとして続いていくと思います

不都合っていうのもあいまいなので
また揺らぐことがあるかもしれないけれどそれは許してください。

なぜ揺らぐのかを考えたんだけれど
自分のこと100%でやっているわけではなくて
いつも他のことも気にしたりしている。
そしてさらに自分のために他のことを気にしたりもする。
だから揺らぐ。

はい、いっせーのっ
「ああ無料!」



2018年の開発予定[2018/01/06]


年が明けました。
今年もよろしくお願いいたします。

実は録画した紅白もまだこれからみるところでして
おめでたさはこれからじわじわ来ると思われます。

NHKのJAPANGLEっていう番組のラーメンの回をたまたま録画して観ました。
番組をみたら自分がやってきたことが突然ラーメンに思えてきました。

ちょっとした用途に使うようなそんな3Dはラーメンだなぁと思ったのです。

実際に食する機会が多いのはうどんとかそばなのですが
じゃあ、うどんでもそばでもいいけれど、番組を観た直後はラーメンだなぁと気が付いたのです。

まあそれは置いといて。
(っていうかお茶だろ!?)

オープンソースの具体的な予定を書いてみます。
まだ予定ですが。

まめばけ3Dのオープンソースを使いやすくなるように改造します。
構成を改造します。

現在はフラットにソースファイルを並べて使用していますが
DLLに分類します。
DLLとヘッダがあればどこかで使えるようにします。

構成を考えてみました(予定です)。

1、ハンドラ部 (ChaHandler.dll)
  各部のポインタを保持してアクセスしやすくするところです。

2、計算部 (ChaVecCalc.dll)
  D3DXの代わりです。

3、FBX読み書き部 (ChaFBX.dll)
  FBXの読み書きをします。

4、モデル部 (ChaCharacter.dll)
  キャラクター(読み込み単位)の管理と操作をします。

5、アニメーション部 (Chanimation.dll)
  アニメーションの管理と操作をします。

6、ボーン部 (ChaBone.dll)
  ボーンの管理と操作をします。

7、物理部 (ChaBullet.dll)
  Bullet Physicsによる物理の部分です。

8、ウインドウ部 (ChaWindow.dll)
  現在のOrgWindowをDLLにします。

という予定です。

やっていくうちにまだ増減する気がします。
FBX部は昔、別DLLにしたらうまくいかなかったのでDLLにできないかもしれません。

DLLに分けることでまめばけ3Dのコアの部分をオープンソースで開発しながら
他のアプリでそれを使用しやすく出来るというメリットがあります。

ということで
大げさなもの使用するまでもない
ちょっとした用途に使えるものを目指して行きます。

(言っているそばから
DLLの分け方が大げさだそうです。)


追記
描画部のDLLはChaPaintにして描画部を取り換えられるようにしようと思います。



オープンソースを利用した商用アプリ計画[2017/12/16]


[追記:
商用に関してはいろいろ思うところがあって2018/01/14の日記にて追加条件があります。
以下の日記はそのまますぐに実行するわけではありません。]


今日は今後の開発方針に関わることを書きます。

現在、物理対応の3DプログラムをLGPLのMameBake3D(まめばけ3D)として開発しGitHubで公開しています。
そろそろコア部分の重大なバグもとれたということで商用ソフト作成を視野に入れます。

規約、ライセンスの変更はしません。
そしてオープンソースの開発もやめません。

ではどのように商用ソフト開発を始めるかというと
LGPLのMameBake3Dのコア部分をライブラリファイル化(ChatCats3Dになると思います)します。
そしてそのライブラリと商用ライセンスのフレームワークを使用して商用のツールを作ります。
つまりコア部分をLGPLのオープンソースとして開発を続けながら、GUIなどをちゃんとしたクローズドな商用ツールを作成します。

これはMameBake3DがGPLではなくLGPLだから可能なことです。
LGPL部分をライブラリファイルとして別ファイルにするのです。

オープンソース活動が基本方針であることに変わりはありません。

フレームワークには商用ライセンスのQtを検討中ですがまだ確定はしていません。

仕事がありますし
そんなにバリバリかっ飛ばして開発していく感じではないかもしれません。


「追記」
念のため書かなくてもよいことを書きますが。
ボロモウケしようとしているわけではなく必要なのです。
必要というのは現在だけの話ではありませし現状だけの話ではありません。
万が一、ボロモウケしてしまったら人を雇います。



スードローカル(Pseudo Local)とは何か?[2017/09/09]


まめばけ3D(MameBake3D)を作る過程で技術的なキーとなったスードローカルについて書きます。
スードローカルっていうのは英語にするとPseudo Localです。

何のことかというと数学的には座標系の変換です。

MameBake3DはFBXファイルを扱います。
FBXファイルのボーンには初期行列とか基本行列と呼ばれているボーンの座標系を表す行列があります。
姿勢の編集時にはその基本行列の座標塀で計算をします。

しかし、その方法「だけ」ではうまくいかないこともあるのです。

うまくいかない例を挙げますと大きく2つありました。
1、FBXの基本行列のねじり軸がZ軸なのに対し、bullet physicsの基本行列のねじり軸がX軸である場合。
2、アニメーションのリターゲットをする際に、元のFBXと先のFBXの基本行列が異なる場合。

1のねじり軸というのを説明します。
姿勢に対して角度制限をする場合、普段はクォータニオンで姿勢制御をしていたとしても
XYZのオイラー角に変換して制限をかけることになります。

そのXYZをどのように割り当てるかということです。
ボーンについて言えば、
ボーンの線分を軸として回転させるのが「ねじり(Twist)」です。

XYZの回転の順番やねじりの軸をどれにするかなどで
オイラー角の計算方法が変わってきます。

計算方法が変わるということは上記の1の場合
もともとのFBXの基本行列ではbullet physics用の姿勢にマッチしないということです。

そういう事態を解決するために
本来のローカル軸とは異なるスードな軸を設定して座標変換をして物理計算をします。

スードローカルの計算方法を使用してもグローバルからみた姿勢行列は同じです。

こういう技術がまめばけ3D(MameBake3D)の中で使われています。


2017/09/09  化け猫おちゃっこ


###追記
いまいちどういう効果なのかわかりづらいということで
例を挙げます。

スードローカルを使用することで
FBXとbullet physicsとの軸が異なっていても
FBXのアニメーションを再生しながらbullet physicsのシミュレーションをすることが可能であり、
またbullet physicsの角度制限関数をそのまま使用することも可能である。

という効果があります。





ラプラシアンとか2次方程式とか[2017/03/20]


連休でちょっと勉強したこととか思いついたことをメモします。

時系列が変わりますが、まずは2次方程式について今まで素通りしてきたことで
あれ?ということがあったのでメモします。

2次方程式と言えば放物線です。
y = x ^ 2  式(1)
という例のやつです。
x^2という表記はxの2乗のことです。
これはy方向に重力が働く場合の放物線です。

x軸に重力が働く場合には
x = y ^ 2  式(2)
になります。

ちょっと絵を描きます。



図1の上の左が式1で右が式2です。

そして式1と式2の等式を足すと、図1の下の図になります。
円です。放物線を2つ足して円になりました。

そしてこれはX軸とY軸に重力が働いたときという意味があります。
ってことは、、、
X軸とY軸に直交する重力が働いているところにりんごを落とすと
りんごは円の上を落ち続けるということになりませんか?

てことは
X軸とY軸とZ軸のように直交する3つの重力が働いたら
りんごは球上を落ち続けるのでしょうか?

調子に乗って4次元も考えちゃいます。
x^2 + y^2 + z^2 + t^2 = 定数  式(3)
式3において4次元目のtは時間です。
式3を図に描くとどうなるか?

こういうときは変数を1つ固定して考えたりします。
つまりtを固定してみます。
そうすると
x^2 + y^2 + z^2 = 定数 - t^2  式(4)
式4のようになります。
これは「定数 - t^2」の平方根が半径となる球です。

そこでtを動かしてみます。
時間が増えると半径が減っていきます。

つまり式3は
中身が詰まった球です。

すごいことになりました。時空が球の中に入っちゃいました。

いやしかし、「定数 - t^2」が負になったとしたら
球の半径が虚数になります。

これはいったいどういうことやら、、、

この式をみて
半径が虚数はありえないのでその場合を除く場合に成り立つ式である
という風にするひとと
半径が虚数の球であるという風にするひとと
いろいろいると思われます。

どうなのか私には分かりません。

それにしても
当たり前のような不思議な話でした。


話は変わります。
2乗の次のお話は2回微分の話です。

ベクトルの成分ごとに2回微分してそれを足したものをラプラシアンと言います。

ラプラシアンにはこれまた当たり前のような不思議があります。
画像に対してラプラシアンを計算すると画像の輪郭線が抽出できるのです。

エッジの描画は昔、法線を裏返した2重ポリゴンで描画したりしました。
数学的にはラプラシアンで抽出可能です。

普通の2回微分というと、例えば
位置を2回微分すると加速度です。

ラプラシアンはこの2回微分の成分ごとの加速度を足し算したものです。
物理的には流束密度というそうです。

密度なんです。

加速度の足し算の流束密度で画像の輪郭が分かるなんて
なんかすごいです。

ラプラシアンフィルタをかける前とかけた後の画像を貼り付けておきます。








今回は連休で調べたことのメモでした。

それではまた。



補足
X軸の重力とY軸の重力と書いたけれど
2つが直交していることが重要であり、
直交し続けていることが重要である。

2つの重力は
ストローとひもと球の例の実験における力と運動方向の関係だと思われる。

ご存知ですよね?
ストローの中にひもを通して片方の先端に球を取り付ける
そして球を回す実験。

あれの証明になっているんじゃないかと思うのですが
きちんとしたい方はもっとちゃんと考えてみてください。



MameBake3Dの数学的背景 第一回[2017/03/04]


MameBake3Dは下記アドレスで公開しているオープンソースの3Dアニメーションツールです。
https://github.com/Ochakko/MameBake3D

Bakeの部分はベイクと読んでも化けと読んでも自由です。

今回から数回にわたり?MameBake3Dの数学的な背景について書いてみようと思っています。
数回にわたり?と?が付いているのは、自分や周りの状況をみつつということです。

さて第一回ですが、第一回から核心に近い部分を語ります。
座標系変換の部分を説明します。
行列演算ついてはクリアしているものとして書きます。

まず前置きとしてとあるボーンのアニメーション行列AをBに更新することを考えます。
FBXにおいてはグローバルのアニメーション行列を扱うことになるので

A * invA * B = B  (式1)

というように計算するのがFBX公式の方法です。
invAとはAの逆行列です。
これは良いですよね?

さてこれを少し応用します。
例えば

Aの回転以外 * Aの回転 * invAの回転 * Bの回転  (式2)

というような演算を考えます。
前回と違うのはAが回転ではない部分と回転の部分に分かれていることです。
そして逆行列によりAの回転のみを初期化してBの回転で置き換えています。
式2の方法により回転だけを更新できるのです。

MameBake3Dの数学の背景には式2のようなやりかたが多数使われています。
式2では回転に着目しましたが、初期行列や初期姿勢などに着目して式を作ることで
更に世界が広がります。

そんなことをして何の役に立つのかがピンとこない人がいるかもしれないので
書き方を変えてみます。

FBXのアニメーション情報はグローバル行列が基本です。
そしてボーンごとに初期行列があります。
ということは、グローバル行列からローカル行列を計算したとしても
「異なる初期行列」と「異なる初期姿勢」と「異なるボーン構造」  (3要因)
が立ちはだかって
モデル間でアニメーションを使いまわすことが難しいのです。

しかし、グローバル行列と言えども行列の掛け算の結果です。
式2の応用により3要因についての変換を行えば
異なるモデル間でもアニメーションを使いまわすことが可能なのです。

式2はそういう可能性を秘めた考えなのです。


さて前置きはこの程度にして
MameBake3Dのリターゲット(異なるモデル間でのアニメーション変換)において
実際にどのような計算をしているかを少しだけ説明します。


[初期仕様]

 初期行列が異なるので回転と移動に分ける方法を採った。
 移動は一番親の移動しか適用していない。

 まずローカルの姿勢を求める。
 localmat = worldmat * invparmat
 座標系の変換をする。
 curmat = invmodelinit * localmat * modelinit;
 ここでmodelinitとは設定される側の現在のworldmatである。

 curmatの回転成分rotmatを取り出して設定する。
 curmp->GetWorldMat() * rotmat;// * tramat;

 更に子供方向に向かってこの設定を再帰的に適用する。


[仕様修正その1]
 最初のフレームのポーズと形状側の最初のポーズが同じであっても
 最初のフレームにモーションが設定してある場合に、
 上記の方法ではうまくいかなかったので方法を変更した。

 姿勢を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
 ということである。


[仕様修正その2]
 モデル全体が一回転するような場合などに足がクロスしたりしてうまくいかなかった。
 コンバートのための行列にモデル全体の回転を考慮する必要があった。
 bvhのHipsの各フレームのworldmatをbvhfirstmpmatとすると
 modelmat = modelmat0 * invbvhfirsthipmat * invbvhmat0 * bvhfirsthipmat * invmodelmat0 * bvhmat
 のようになった。
 モデル全体が一回転しても初期姿勢のコンバートがうまくいくようになった。


という感じの数学的背景がMameBake3Dにはあります。

かなり説明をはしょりましたが
全てを説明するよりは読者の研究心や探求心を引き出したほうが良いと思いそうしました。


これらの仕様は実際にソースコードになってコンパイルすれば動く状態です。
動作確認もしています。
https://github.com/Ochakko/MameBake3D


ちょっと興味が湧きましたか?
君も化けちゃいなよ!




MameBake3Dにリグ機能が付いちゃいました[2016/06/02]


MameBake3Dの更新をしました。

遅ればせながらリグ機能というものを付けてみたら付いちゃいましたというお話。
動画を作りました。

こちらは設定方法と操作方法を12分ほどにまとめた動画です。
【使い方説明】 MameBake3D 【Rig機能が付いちゃいました】
https://youtu.be/gkqCJNsUsKE


こちらは操作画面と操作例をダイジェストで32秒の動画にしたものです。
MameBake3D CustomRig 動画。32秒。
https://youtu.be/o7UUAqea6io


アニメーションツールにおけるリグとは
複数ボーンを一度に簡単に操作することが出来る仕組みのことです。

複数のボーンの回転の仕方を登録しておいてそれ用のGUIコントロールをドラッグすることで
ポーズを付けます。

MameBake3Dのリグの特徴は
マウスのUV方向(横と縦)それぞれにボーンの回転を設定することが出来る点と
ユーザが自分でGUIでリグの設定をすることが可能な点です。

1つのボーンに対して10個のリグを自分で設定して登録することが出来ます。


MameBake3Dのリグの今後についてですが。
1、リグモードのオンオフをもっと簡素化したい、スムーズにしたいです。
 (現状、大きめのダイアログの表示非表示で切り替えています。)
2、現在は1つのRigによって、親子関係のあるボーン5つに対する操作が出来ます。
 手の指を開いたり閉じたりするためにはこれだけではできません。
 1本1本の指のためのRig5つをまとめるようなRigの存在が必要になります。
 つまり、RigのRigというかRigの連結というかそういう仕組みが必要になります。
 最近はノードというやり方が流行っているようですので、リグノードなんてのもありかもしれません。
 この辺の仕様を考えて実装したいです。


という感じです。



MameBake3Dの編集オプション[2016/04/24]


MameBake3Dの更新をしました。
もっといろいろ違うことを勉強しようと思っていたのですが
それってぶれてるっていうことかな?などと考えているうちに
気が付くとまた3Dプログラミングばかりしています。
どうしたものか、、、?

そして最近の成果を動画にしました。

「MameBake3D [編集オプションの説明]」動画。
https://youtu.be/cA7ceFJ2oLY


編集オプションの話です。
今までの編集方式ですと、複数フレームに対して、姿勢を決定するフレームの姿勢を適用していたので
複数フレームの間に体の向きが回転した場合に想定と異なる結果になっていました。

例えば、体が反対を向いていても姿勢決定フレームと同じ効果を適用したので
編集時に足を開かせても、体が反対を向いたときに足がクロスしていたのです。

この現象を名付けるとすれば、perfumeのCOSMIC EXPLORERのジャケ現象とでも言いましょうか。

そこで疑似的にローカル姿勢に変換して姿勢に適用するオプションを作りました。
PseudoLocal(疑似ローカル)オプションです。
日本語っぽく発音すると「スードローカル」です。
デフォルトでオンにしました。

姿勢を適用するボーンの親の姿勢を考慮して計算したので
体が回転したりしても編集時と近い見栄えの効果が出ます。

そんな感じのことを実演してみた動画です。

あ、あとはマウントステート(謎)についても言及しています。
まうんと すてーーーとぉーーー!!!



もう1つその前に作った動画も紹介しておきます。

「MameBake3D bvhそっと歩き+物理ツインテ」動画。20秒。
https://youtu.be/upwvM6yBGgw


こちらはbvhのモーションを取り込んでそれと物理シミュを組み合わせて再生したものです。
GitHubにアップしてあるファイルの中にtest12というサンプルがあるのですが
それを読み込んでF9を押したところです。
モーションスピードはスライダーでいじりました。
モーションスピードを速くしすぎると体が180度回るところでツインテールがプルプルするのですが
そういうときはスペースキーを押すとモーションを再生しながら物理がリセットされます。


こんな感じの経過です。



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のバージョンアップをしていました。
3Dツールと言えば、他にもたくさんあるし、すでに世間に認識されているものが多いです。
そこで、それらの隙間を狙ったツールとしてMameBake3Dを考えています。

どこが隙間かと言うと
ベイク済のFBXの編集関係に特化しようということです。

モーション作成というよりもモーション編集に重きを置きます。
物理関係の機能もあります。

ということで、bvhは読めてFBXに変換出来たほうが良いので
その機能を修正しました。


次に紹介する動画はMameBake3DでbvhをFBXに変換する方法です。
新規に作成した動画です。

[ MameBake3Dの使い方。BVHからFBXへの変換の話。]
オイラー角出力を抜本的に見直した結果、モーション再現率がかなり上昇しました。
perfumeの3人が踊る動画。
https://youtu.be/ONnB1jDVi6k


そしてもう1つの動画は、ベイク済のモーションの編集方法について解説しています。
この動画は過去に作った動画を復活させたものです。

[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です。

久しぶりに半日 3Dをやりました。
まだ32ビットアプリのままです。


追記:2016/02/10
GitHubにアップしたソースが足りなかったことに気が付いて先ほどアップしなおしました。
何か赤い字が出ていたのですがcommitに-aをつけていれば大丈夫と思っていました。
ちゃんんとaddしてからcommitしました。
DX90c以外のファイル(ビルド用の)はそろっているはずです。
(実行するためにはFBXSDKをインストールして、DX90cのSDKを所定位置にコピーする必要はあります。
さらに、GLUT32.dllをexeと同じディレクトリに置きます。)



Wow64はエミュ扱い[2015/11/04]


Win64を少し調べました。
64ビットOSで32ビットアプリが動くのはWow64という32ビットアプリを動かす仕組みがあるからです。
Wow64って名前に付いているディレクトリがあるのでこれは知っていました。

しかし、Wow64は64ビットOSにおいて 32ビットアプリを「エミュレーション」で動かすための仕組み
だったのです。
つまり、64ビットOSにとって
32ビットアプリはすでにネイティブとは言いがたく、エミュで動いている存在でした。

ショーーーーック!!

あんまり64ビットに移行する気がしてなかったのですが
これを知って64ビットに移行する気が出てきました。

だって、エミュだってよぉー。
やっぱりいくらか遅いんじゃないかしら??

ということで
まだ調査は続きそうです。

とりあえず
64ビットOSでもintやlongは32ビットであり、ポインタやハンドルが64ビットになる
ということが分かりました。
32ビットから64ビットに移行しやすいような配慮だそうです。

これなら設定しなおしてコンパイルし直すだけで良いものも結構ありそうです。

しかし、RokDeBone2は 確か ポインタをunsigned longにキャストしていた箇所が数か所あったような気がします。
まあ それは いいとして。

新しく作るものは64ビットにしよう!!



Win64[2015/11/04]


Win32が使えなくなる日が来るのかは知りませんが
時代の流れとして64ビット方向に進んでいるので
一応対応しようということで、Win64を調べます。

調べる前の印象としては
ものすごい大きなファイルやメモリを扱わないのであればWin32で良い気もするのですが。

ビッグデータが流行ですし
64ビット化して実行速度が速くなれば もうけもん ってイメージ。

とりあえず調べ始めようと思います。



ナビゲーション










店舗イメージ