本文へスキップ

おちっこLAB Since 2002 おちゃっこLAB Since 2006

おちゃっこLAB化け猫編バージョン2 Since 2013/12/21
おちゃっこLABメトード2編 Since 2021/09/23

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


前書き

化け猫おちゃっこのWindowsプログラミングの日記です。
勉強したこととか、作ったもののスクリーンショットとかのページにします。
3Dプログラミングに片寄っていたので
それ以外のことも勉強していきたいです。

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





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


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


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

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


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

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

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



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

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




図4:コピー履歴検索

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

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

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

履歴の中からペーストに使用したいコピー結果を選択したら
OKボタンを押します。

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
MotionBrush(モーキャプデータコピペ編集ツール) https://www.vector.co.jp/soft/winnt/art/se523002.html
MotionBrushOSS版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に持っていく準備をします。
MotionBrushというソフトを使います。
https://www.vector.co.jp/soft/winnt/art/se523002.html



図2:bvhフォルダ

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

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


図3:bvh2FBX batchメニュー実行

MotionBrushを立ち上げて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でサンプルプロジェクトを読み込む

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


図7:MotionBrushの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はMotionBrushで作成したプロジェクトフォルダの中のモデル名のフォルダの中にあります。


図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>にしておかないと体全体の回転の中心がずれます



図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]


MotionBrushはver1.0.0.7で完成したのですが
初期のころのモーションキャプチャ結果のbvhを扱う場合に
姿勢が裏返ることがある不具合が発覚し修正に苦労しました

MameBake3Dデベロップ版としてオープンソースで試行錯誤しながら開発しました
やっと結果が落ち着いて更に説明もつくようになったのでメモとして残します
(MotionBrush ver1.0.0.15としてのリリースは1,2週間後になる予定です)

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


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


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

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

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

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

そこで対策しました

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

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

(オイラー角に関しては
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にあります)


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

MotionBrushは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夕方公開予定のMotionBrush ver1.0.0.15
です


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







MotionBrush(モーションブラシ)を使って確かめたいことがある[2021/07/18]


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


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

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

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


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


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



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

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



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


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



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



MotionBrush(モーションブラシ)シェアウェア版としても完成[2021/07/07]


MotionBrush(モーションブラシ)はシェアウェアとしても完成しました。

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


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

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

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


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

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

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


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


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



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


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

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

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



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

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

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



図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
MotionBrushPluginsSDK Updata 002
TopPosスライダーを0にしたときの重みが間違っていたのを修正
(本体と一緒にご使用ください)
アップデータ002 ブラシ修正 MotionBrush ver1.0.0.7用

動画【モーションツール】ver1.0.0.7完成版のいいところ【完成しますた】
https://youtu.be/nApvd9___mQ

おちゃっこLABのMotionBrushのページ



MotionBrush(モーションブラシ)とBrush(ブラシ)の関係[2021/06/25]


モーションブラシってどこがブラシなの?
という疑問に対して説明しました。

以下のリンクのpdfに簡単にですが書きました。
MotionBrush_ExplainGraphOfBrushes.pdf へのリンク


Vector様に登録されました。[2021/05/29]


みなさんの応援のお陰で
OSSとしてのMameBake3Dは完成し
開発継続のためにソフト名をMotionBrushに変えて
Vector様のところでシェアウェアとして公開中です
ありがとうございます


Vector様のシステムは
ダウンロードと課金が別ボタンになっていますので
まずは気軽にダウンロードして動くかどうかチェックしてから
課金するかどうかを決めることが出来ます

MotionBrushのVector様でのアドレスは以下です
https://www.vector.co.jp/soft/winnt/art/se523002.html

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


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

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


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

前回の日記においては
4KTVが必須のような印象でしたが
MotionBrushというソフトとしては
横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ビット化して実行速度が速くなれば もうけもん ってイメージ。

とりあえず調べ始めようと思います。












店舗イメージ