レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
次期MMDツール開発関連スレ
-
樋口MがこのたびMikuMikuDanceの開発終了を発表されましたので
それを引き継ぐ「MMDツール」開発に関する話題を取り扱うスレッドです。
プログラマー以外の方も含め、幅広いご意見をどうぞ
-
>>586
つまり、MMD#とMMDでミクのスカートが透けるかどうかの違いは、
スカートの裏地部分のエッジを描画しているかどうかってことだね
>>581
機能が充実してきた分、そろそろマニュアルないときつくなってきた
もう少し機能が固まって、(MMD杯終わったら)こっちで作ろうか？
それぐらいなら手伝えると思うし
-
UIの部品は現状で出揃いつつあるんだろうか？
ならばマニュアル作っていく事もできるけど、もし現状からガラっと変わる予定なり心づもりなりがある部分があるなら教えて欲しいね
-
プロジェクトがセーブ可能になったら一本まともにMMDS使って動画つくろうと思ってる
それを元にチュートリアル作るつもり
-
結構 mikumikudance ユーザーというか動画作成してるひとって
XP 以降のOS使ってるひと多そうな予感…
-
XPはオワコン
-
うわ…やっぱりラデの方がAVI出力遅し…
-
>>590
さすがに2000ユーザーはもうほとんどいないかと。>XP以降というなら
XPユーザーはまだまだいると思いますが・・・
-
>>587
夕方に公開したバージョンで一応Lat式と標準の両方が
正常に表示されている・・・と思います。
確かにグラフのエディット等はマニュアルなしでは操作出来ない
ところまで来てしまっていると思います･･･。
ですのでマニュアルを作っていただけるのは大変有り難いです。
（とはいえカーブのUIはまだ使いやすく修正していくつもりなので完成ではないですが）
>>589
現状のバージョンでも確認した限りは正常にシーンデータのSave/Loadは出来るようになっています。
>>592
うーんナゾですね・・・
一応高速化のネタはあるのでそっちも試してみたいと思います。
うまくいけば今よりは速くなるんじゃないかなと思うんですが･･･。
-
>>103の人は今どのくらい進展してるんだろう
-
マニュアルかー
作者にとっては別言語でツール作り直してるようなもんだしねー…
-
MMDだとgeforceとintel(sandy内臓)は性能相応でradeonだけ遅い
みたいな報告あったけどsandy内臓で計測した人いる？
-
もし認識違いならごめんなさい
現状でモーションを作って行く場合の問題点
１．プレビューウィンドウ（モデルが表示されてるウィンドウ）主体でモーションをつけていく事ができない
ポーズを付けることは可能だが、その状態でキーが打てない
MMDで言う所の「未登録選択」＞「フレーム登録」に相当する機能が必要だと思う
２．30フレーム以降を編集することができない
使ってみて、こうだったら良いのにと思った点
１．MMDみたいに色が変わる等の方法で編集したボーンが分かると嬉しい
２．アンドゥが出来ると嬉しい
モーションをつけようとしてX軸触ろうと思ったのにY軸動いちゃった場合などでも操作が取り消せない
３．アプリケーションを終了しようとした際に、「保存せずに終了しますか？」等の問い合わせのダイアログがあると嬉しい
４．プレビューウィンドウの視点中心をある程度選択できると嬉しい
選択中のボーンを中心に回転等があると操作しやすいかも
５．フレームの移動のショートカットがあると嬉しい
MMDで言う所のカーソルキー右左みたいな
-
>>598
＞１．プレビューウィンドウ（モデルが表示されてるウィンドウ）主体でモーションをつけていく事ができない
実は変更時に自動的にキーが打たれています。
まぁこれLightwaveの仕様なんですが･･･。
deleteキーで現在のフレームのキー一括削除なんかも対応予定です。
＞２．30フレーム以降を編集することができない
これも実は可能でタイムラインウィンドウの「現在のフレーム」と「最終フレーム」は
数字のところをダブルクリックすると入力用のダイアログが開いて変更することが出来ます。
＞使ってみて、こうだったら良いのにと思った点
参考にさせてもらいます。
ぶっちゃけ自分でMMDで何かを作ったりしたことがあるわけではないので
UI回りでの改善点は色々挙げてもらえると助かります。
MMD関係の本とかは一通り買って作り方自体は見たりしていますが･･･。
とりあえずアンドゥ/リドゥ/コピー/ペーストは必須機能だと思いますので早いうちになんとか対応します。
-
>>599
ちょっとだけ現状についてきいていいでしょうか。
>>47の
>昔モデルデータスレに居た人間からすると
>・MMD本体部分(英名、物理、自影拡張以前の基本機能)の作成は、DirectX(GLでもいいけど)を弄ったことがある人なら可能だと思う
>（要は、現在フレームの各ボーンの位置と回転をローカル*ワールド行列に仕込んで、あとはカメラと照明も似た感じに処理するだけなので）
これってそんなものなんでしょうか。
>・難しいのは、旧バージョンと動作を完全に一致させる部分
>（IKはBlenderより1個分チェーンが短かいとか、その他諸々、Mが書いた計算式をどこまで推測できるか次第）
>・物理はBulletをちゃんと見た事が無いのでなんとも言えないけど、実装する気になった時に調べればいいので
>・セルフシャドウは、昔、変な影(板)が出てたあたりから推測すれば行けるはず
この辺もすでに課題解消済み？
-
>>600
＞これってそんなものなんでしょうか。
ごく一般的な3D計算なのでそんなもんです。
＞この辺もすでに課題解消済み？
IKに関してはただのCCD＋膝だけ独自処理です。
Bulletに関してはいじったこと自体はあったのであとは人様のソースとか参考にごにょごにょ。
セルフシャドウは挙動からただのLiPSMなのが分かるのでそのまま実装するか
Cascadeに変更するかして対応して終わりかなと。
-
>>599
ほんとだ！
なるほどそういうUIだったのか。
あと、>>598に以下を追加させてください。
問題点
３．プレビューウィンドウから移動可能じゃないボーンが移動できてしまう
CTRL+ドラッグで肩とかの位置を動かせてしまいます。
４．選択できなくていいボーンが選択できてしまう
IK接続先？が操作できてしまいます。つま先とか。
こうだったら良いのにと思った点
６．選択中ボーンの回転量、移動量を簡単に初期状態に戻せると嬉しい
結構多用するのですが、他の人はどうなんでしょう。
グラフエディタから数値入力で相当の操作は可能ですが、もっと直接的な操作で可能になると嬉しいです。
７．プレビューウィンドウに表示されているボーンを種類で色分けしてくれると嬉しい
MMDに慣れきってるからだと思うのですが、IK影響下のボーンはパッと見で判別可能だと嬉しいです。
IKも影響下のボーンと操作点のボーンが同じ□で表示されているのでどっちを触っているのか分かりづらいです。
８．プレビューウィンドウ上で選択しているボーンがどこかに表示されると嬉しい
プレビューウィンドウでボーンを選択するとグラフエディットのボーン一覧上でも選択されますが、グラフエディットのペインを開いておかないと見れないので、
それとは別にどこかに表示されているとMMDユーザは喜ぶと思います。私とか。
あと、選択されるだけじゃなくてスクロールの表示範囲内に勝手に入ってくれると嬉しいです（EnsureVisible）
９．ボーンの操作をXYZ系統別に出来ると嬉しい
プレビューウィンドウ上のボールベクター、ツイストディスクがまだ未実装なだけな気もしないでもないですが、XYZ系統別にドラッグ出来たりすると嬉しいです。
10．キー未選択状態でグラフエディットのフィット(A)を行うと、左下が０の状態に戻るのが寂しい
これは好みの問題な気もしますが、未選択であればAの操作を無視する、もしくはFと同じ動作とする方が違和感が少ないような気がしました。
>>601
MMDではモード2（表示＞シャドウ設定＞mode2）がLiPSMに相当すると思われます。
Mによる実装時の日記が読めます。
http://v-nyappon.net/?m=diary&a=page_detail&target_c_diary_id=728717
-
テスト
-
http://www1.axfc.net/uploader/Sc/so/260622
背景の読込みやるといいつつやってません、すんません。
今日は動画の出力部分をカスタムしてました。
挙動的にGPUをストールさせずに動画へ落とすことが出来るだろう方法を試してみました。
SandyBridgeのノートPCでも30FPS以上で出力できるCodecもあったりとそこそこ良好な結果です。
メインのPCがRadeonしかないのでGeForceとの差は測れませんが、
以前よりは速い速度で出力できてるんではないかな〜と思います。
それとα付き連番PNG出力に対応しました。
PNGの圧縮が結構重いのでよろしいCPUじゃないときついかもですが
ファイルサイズがかなり小さく扱いやすいので後から合成とかするのに便利だと思います。
あとはマテリアルエディットの画面でマテリアル毎の描画ステートを細かく設定できるようにしました。
まだ色々足りないですが今後そこに増やしていくという事で。
そして次こそＵＩの改善と背景モデルの読み込みを・・・。
>>602
この手の改善案は大変助かります。
参考に色々と修正していきます。
移動不可のボーンが移動できるのってどうなんですかね？
移動をマスクするのは簡単ですが特殊な演出とかでやりたくなったりはしないんでしょうか。
LiPSMはそれなりに良好な影を生成する傾向にありますが
特定条件でガッカリになったり欠点もあるので
そのままの採用をするかどうかは割りと微妙です。
-
今のMMDにはボーンモーフというのがあってだな…
真面目な話、一回PMXの仕様書読んだ方がいいんじゃないのか。
-
>>595
アンドゥリドゥのフレームワークを追加した。
描画エンジンをマルチウィンドウ対応に書き直した。
（だが本家にない機能なので実戦投入されるかは謎）
タイムラインの実装が６０％
みんなにテストしてもらえるようなものは、現時点では無い（´・ω・｀）
-
>>604
移動不可ボーンはモデラーがそのモデルではそのボーンを動かさないよう
セットアップしているから動かさなくていいと思うよ
モデルの意図された動きと違うってことだし
どうしてもやりたい場合はPMDEditorで改造してる
-
描写の仕組みは良くわからないが3Dゲームみたいにアンチエイリアスの程度を選べて
マシンスペックが許す限り綺麗に表示とか出来ないかな
-
>>604
多分それ喜ぶのホメ春香使いの人だけだと思うW
-
>>608
そんなもんはGPUのドライバでやればいいこと
それよりセルフシャドウの品質を上げて欲しい
-
>>610
良くわかんないついでに聞くけど今のMMDでもGPUドライバで設定すれば
綺麗に描写されるの？アップにしても耐えられるくらい
-
>>606
地道に進んでるのな。
ゆっくり期待してるんで気楽にがんばれー
-
アップに耐える云々はモデルの作りもあるし
MMD自体がDX9上のソフトだから、
（昨今の）３Dゲームのように〜ってのはカナリ無理があると思う
-
>>611
もしかしてアンチエイリアスの意味を取り違えていない？
-
>>613
なるほどDX9なかぎり難しいのか
>>
シャギーを目立たなくする為に階調を弄って線画の周りをぼかすって認識してるけど違うのかな
-
>>604
>移動不可のボーンが移動できるのってどうなんですかね？
>移動をマスクするのは簡単ですが特殊な演出とかでやりたくなったりはしないんでしょうか。
本当に特殊な場合のみだと思うので通常は出来ない操作としておいて、とある操作（例えばボタンを押した以降とかチェックボックスを外すとか）をすれば移動可能となれば嬉しいです。
＃具体例としてPMDEDitorのTranceformViewにおいては回転のみのボーンも「制限解除」ボタンを押すと移動可能となります。
パースペクティブビューから後ろを見たらカメラが！
と言うことでカメラに関してですが、MMDのカメラが非常に使いづらい（カメラの位置や注視点の親がワールド固定で被写体やオブジェクトアタッチ出来なかったりとか）するのでMMDSではその辺の使い勝手を考慮してもらえると嬉しいです。
-
>>615
それであってる。それなら、それなりのグラボを使ってたら
綺麗に見えるよ。
アップでも耐えうる、とか言ってたので、ローポリモデルを
ハイポリモデルみたいに表示させたい、とおもってるのか
と思ってた。
-
>>611
よくわからないけどアンチエイリアスとミニマップをnHancerとかいうものでどうにかできるんじゃなかったっけ？
セルフシャドウの品質は良くなって欲しいと思う
-
>>616
VMDのデータ上は特に・・問題ないですよね。>移動不可ボーンが動かせる
なんというかなにかの前提になってると嫌らしいなあと。
-
HLシェーダだけど、これはどうだろ。
3DCGゲームのイメージにに近くない？違うかな？
ttp://www.nicovideo.jp/watch/sm13389986
こういうのでよいならアンチエイリアスやセルフシャドウの精度はそのままで
MMEが使えればいいだけかな〜と思ったんだけど。
-
>>619
前提っつーか、いわゆるフールプルーフじゃないのかな
初心者が間違って動かしちゃいけないボーンを動かしちゃって戻せないとか
そういうのを防ぐ意味でも、やらないほうがいいんじゃないのとは個人的には思う
-
だから初心者は今までのMMDを使えば良いんだって
次期MMDは今までのMMDに飽き足らずもっとこうしたいああしたいってユーザー向けで良いと思う
だから下手な制限は要らないと思ってるある意味住み分けしないと後発の意味無いし
-
現行MMDでも、シャドウ距離変えたりCTRL＋G（だったかな？）押すことで、
セルフシャドウの精度変えられるよね。
このへんをもし自動できれいにできるならそれに越したことはないけど、
重くなりすぎないかどうかが心配だなあ。
-
>>621
フールプルーフとして考えるんだったら「隠し機能」にするのが妥当かな。
大きな判断として「下位互換性をどこまで確保するか」というのはありますよね・・
今は逃げ道を確保するためにも、
デフォルトのMMDSで作ったデータははそのままMMDで読める状態にするのが妥当だと思う。
MMDの置いてあるフォルダを指定するとそこを起点にMMD同様にファイル読み書きできるとかやれば
今の段階でもツールとして有効になる可能性あるし。
-
全く意味が分からん
何でMMDSがMMDで読めるデータを吐けないかんのよ
AdvancedなMMDを求めてる人間と
MMDの正統な後継者を求めてる人間で意識に乖離がありすぎるな
-
しかし mmd 互換をなくすというか程度にもよるんだろうけど
変更すると PMDEditor とか心当たりのアレとかアレとかライブラリで
楽チンぽんで読み込むことができなくなるという…でも上がって来てる物は間違いなくいいと思うよSは
-
>>625
AVIファイルの出力段階で、MMDに持っていくために必要だろ
シェーダー、物理演算の振る舞い、MMDエンジンの動きが、MMDと異なるのは、製作者が異なるから
どうあがいても発生するんだから、モデルの調整や、Fixが行われたツールで出力するのが、常套だと思うけど
Ver.7が出たときも、諸問題で、Ver.5系とVer.7を行き来してた経験上、データ互換無いと
移行期には動画製作できない。
-
>>625
大丈夫かい？何かぴりぴりしてる？
何か話がまざっちゃっているような気がしてきた
「AdvancedなMMD」は要件の話。ツールの目的だね
「フールプルーフ」は設計思想。方針、アプローチだね。
もちろんこの2つは密接に関係しているけど、
「AdvancedなMMD」と「フールプルーフ」を両立するということは不可能じゃない
当然、「従来どおり」で「フールプルーフなし」もあり
もちろん、MMDの何を引き継いで、何を引き継がないか
最終的な決定はそれぞれの開発している人たちが決めることではあるけど、
MMDの何がこんなに人をひきつけたか、という点は考える価値はあると思うな
-
MMD互換を確保しておけばMMDSに不具合あったけどすぐには対処できないときに
「その工程とかモデルの部分はMMD使ってね」と逃げられると思うんです。事実上の並行稼働体制。
どれだけスキルがあっても最初から完璧なものが作れるものじゃない。
安定稼働したらゆっくり離れていけばいいんじゃないかな。
・・と書いたところで>>627さんがもっと妥当なレスしてる。
-
>>628
なーにが「大丈夫かい？」だ
「僕はこいつより一段上で冷静に物事を見れてるんだよ」と
皆にアピールしてからじゃないと意見も言えないのか
そもそも誰がフールプルーフを否定したよ
俺はMMDSが吐くデータがMMDでも読めなきゃいけない理由なんかないと
言ってるだけだ
-
>>627
>>629
お前らも一体何を言ってるんだ？
>>114がMMDSを今すぐワークフローに組み込んでくれとでも言ったのかよ
-
盛り上がってきますた！ ('A`)
まぁ、どっちもちょっち冷静になれYO！
作りたいように、>>114も>>103も作ればいいと、俺は思うよ
その上で、余裕があれば対応してくれるかもしれないしな
-
pmmがオープンじゃない以上オーサリングの互換は無理でしょ。
-
多分MMDしか使えない環境にある人（XPの人）にも
MMDSで作ったモーション等を使える様にってことじゃないですか？
すぐに移行できる程趣味にお金つぎ込める人ってあまりいないんじゃないかと思いますし。
-
>>114は前方互換の非現実性を説明しといた方がいいと思うよ
「MMDSはMMD互換ツールではありません」と表明しておかないと
延々とこんな話することになる
-
MMD→MMDSのデータ持ち込みがそこそこできればいいのであって
MMDSがMMDで読めるデータを履けるようにする必要はないしそもそも結構無理がある
開発してる本人がそういう仕様にしたいというなら他人に止める権利は無いけどな
最終的な方向性というか現在のMMDに対してどんな立ち位置にあたるツールにする予定なのか
なにかしら明言しておかないと見当違いの意見がでてくるし
-
MMDとMMDSの接点はPMDとVMDだけだろう。
そしてそれらはMMDからMMDSには持ってこれるがMMDSからMMDへは持っていけない、仮にこの先持っていけるようになったとしても既にモーションデータの構成がMMDとは違う方向に進んでるMMDSなのであまり互換性の高い物にはならないんじゃないかなぁ。
-
>>604
Lat式を読み込んでみたら、額、鼻、口周りが白く表示されてる
後前髪が一部赤い
自分は>>561以降はLat式みてないんでどのあたりからこうなってるかは
ごめんわからない
標準ミクのスカート裏地は透けてない
あと自分>>587なんだけどマニュアルの話
実際に作るのはインタフェース固まってからだけど、方向性だけは出しとく
入れたほうがいいこととか、逆にいらないというものとかあったら言ってもらえるとうれしい
イメージは最初に触るときの簡易マニュアル
しっかりしたチュートリアルは動画がいいんだろうと思ってる
ぶっちゃけ自分がグラフエディットがよくわかんないので、
その勉強かねてつくろうとしてる
ファイル形式は簡単なHTMLで作って、自分が作るのをたたき台にして
後で他の人が修正してもらえるといいかな
項目的にはこんなとこかと
・推奨環境
・導入
・インタフェース説明
・とっかかりとしてモデル、モーションを読み込んで動かすまでの一連の流れ
・グラフエディットの使い方
- インタフェース説明
- 1つのモーションを作るまでの簡易手順
・MMDとMMD#での共通点と相違点
-
MMDSのAVI出力の速度を、取り敢えず自分の常用環境で試してみた
常用環境そのままで、ベンチ用に環境揃えてみたりしてないから悪しからず
OCしたりコア数変えたりの検証もしてない
モーションはGOMYWAY
出力を始めて少し時間が経ち、fpsが安定してからの最小と最大を記録（小数点以下切捨）
環境1
【CPU】PhenomIIx3 705e @2GHz
【M/B】GA-MA790FX-UD5P
【メモリ】DDR2-800 2GBx4（4GBをRAMディスクに）
【VGA】GTX 560 Ti
【OS】Vista 64bit
MMDS 7/30版
50-58fps -ut video codec RGB
12fps -microsoft video 1
10-20fps -未圧縮
MMDS 7/31版
54-59fps -ut video codec RGB
19-20fps -microsoft video 1
15-28fps -未圧縮 ※RAMディスクに出力の場合は150-187fpsと最速を記録
環境2
【CPU】i7 875k
【M/B】Big Bang-Fuzion
【メモリ】DDR3-1333 4GBx2（こちらはRAMディスク無し）
【VGA】HD 6950
【OS】7 64bit
MMDS 7/30版
91-112fps -ut video codec RGB
39-41fps -microsoft video 1
13-28fps -未圧縮
MMDS 7/31版
95-118fps -ut video codec RGB
53-59fps -microsoft video 1
13-31fps -未圧縮
当たり前だけど、ビデオカードだけ変えてやらないと
RADEONとGeForceの比較にならんなあ…
-
書き忘れ
レンダリングサイズは1280ｘ720
-
比較はともかく秒間100フレーム前後出力できるならスピードは充分でないかい
-
MMDS→MMDの互換のためのツールは必要ならば誰か作るでしょう。
MMDSへの規格の移行がスムーズに行くなら問題なし
行かなければ問題点を直す努力をするか、開き直って諦める。
-
よくよく考えたら pmd はそれほど仕様変更の影響は受けないんじゃないか…
カメラ周りいじるとしても
それなら PMDEditor は今まで通り問題なく利用できそうだし…
-
まあ、下位互換性関係なく、移動不可ボーンが「なんの意識もなく」移動できてしまうことは
モデラーの意図が見えなくなる点で問題あるかなあと思います。
動かすときはデフォルトで警告出しておいて、警告うざかったら切れるようにする
あたりが落としどころかな。
-
回転ボーンが移動できると、簡単にカオスなポーズを作れるので
モデラによっては嫌がる人もいるかもね
まあ回転だけでもカオスなポーズは作れるけど
-
普通は両方出力出来る様にするよね
その分内部も外部も複雑になるけど
-
今までだってPMDエディターで改造出来たんだし
-
回転ボーンが移動できるとどんなメリットがあるん？
-
微妙にでかくて指が回らないアイテムを持たせるのに
指ボーンの位置をズラしたりとか？
-
ダルシムができる
-
今までだって、無改造でも直接数値入力とかすれば回転ボーン移動できたやん。
-
叩かれて首が上下にビヨヨヨーンと伸び縮みするアメリカンな演出とか
-
ボーンと別にリギング出来れば動かせてもいいと思うんだけど、MMDの場合はPMD≒リグだからなぁ
基本的にPMDのボーン種別毎に適切に動作が制限される方が使いやすいと思うな
-
この操作をすれば、これこれこういう制限が掛かって、その結果値が画面に反映される
…というプロセスで作成するのはちょっと XPath で Dom 操作して、HTMLとしてブラウザ上に表示する
を思い出す…それ様の木構造、頭に入ってないと、何これ魔法か何かなのダルシムなのインド人を右に
みたいななりゃしませんか…とか思ったり
-
いやだぞ俺は一年後みくみくダンスがみくみくヨガ教室みたいになってるのは…
-
今まではホメ春香でネタモーションやってるような動画でも
回転ボーンの移動はあんまりされてなかった気がするのよね
>>647や>>651みたいな方法はあっても、それなりに障壁があった
それが一気に解禁されると…
-
http://www1.axfc.net/uploader/Sc/so/261012
リソース管理を一元化しました。
アセットマネージャーというウィンドウが新規に追加されていてそこで「作業ディレクトリ」を設定します。
そのフォルダ以下においてあるデータだけがシーンに適用可能なデータになります。
作業ディレクトリからの相対パスで記録されるのでフォルダ構成さえ変わらなければ
別のPCや環境に持っていってもシーンファイルの整合性は失われないというわけです。
アクターリストから読み込みボタンがなくなった代わりに
アセットマネージャーで読み込むデータをダブルクリックして下さい。
それと描画の高速化をしました。
＞ボーン移動
ボーンの移動に関しては移動不可なものはビューウィンドウからは動かせないようにしました。
直接グラフを打ち込めば動かせますのでどうしてもという場合はそちらで。
まぁチェックボックスとかで解禁してもいいかもです。
＞アンチエイリアス
ぶっちゃけ一番綺麗なのはデカイサイズで出力して動画編集ソフトで縮小する事です。
一応MMDSでも描画を「高画質」設定にすればアンチエイリアスが入ります。
＞シャドウマップ
本家よりは綺麗になるだろう方法で実装予定ですが重くなるかは分かりません。
MMDSはDirectX11でGPUゴリゴリ回すタイプの実装なのでビデオカードが熱くなるかもしれません。
＞データ
MMDSの方針としてMMDの資産は引き継げるべきと考えていますが、
現実的に可能なものは「PMD読み込み」「PMX読み込み」「VMD読み込み/書き出し」くらいだと思っています。
シーンのオーサリングはそもそもpmmがオープンではないので不可能ですし、
設定可能なパラメーターやデータもだいぶ違うものになると思います。
ただ使いまわしは当然できてなんぼなので、MMDSローカルなモーションフォーマットは作ると思います。
カメラやライトの移動回転や色のアニメーションとかは使いまわしたいですしMMDSでしか作れないので。
>>638
マニュアルに関してはこちらである程度固まったら簡単な資料としてお出しします。
その上で分かりやすいものを作っていただけたらと思います。
マニュアルとかを作るのが非常に苦手なので･･･。
余談ですけどDirectX11にはテッセレーターというものがありまして、
描画時に動的にポリゴン数を増やしたりする事が･･･。
つまりアップ時にはポリゴン数10倍！とか出来ます、やるかどうかは別として。
-
アセット格納ディレクトリについてだけど、指定されたディレクトリ自身に含まれるリソースは表示されなくて、その中に存在するサブディレクトリが表示されてますがこれはそういう仕様ですか？
必ずアセットフォルダの下にサブディレクトリを作る必要があるって事でいいのかな？
-
うひょーボーン種別が表示されてる！
で、既にちょこちょことモーションつけて遊ばせて貰ってるんですが、回転操作にバグがあるみたい。
再現方法：
http://gyazo.com/50fbbaf579b91efc2bbe99776fa61a69.png
上図みたいに右腕をちょっと上げてから肘をZ軸で回転（右ドラッグ）すると、表示上のZ軸とは違う軸を中心に回転している模様です。
-
>>657
テッセレータ実装は是非やってほしい
ぶっちゃけキャラはともかく背景に力入れなくてよくなるのは便利だと思う
まー七葉式がどういう風に割れるか興味あるだけですけどｗ
-
エイプリルフールネタでMMDがテッセレーター実装ってのがあったなｗ
ねーよｗｗｗとか言ってたが、MMDSで可能になるかもしれないのか胸厚
-
>>657
物理演算をプラグインとして分離できませんか？
私は将来MMDSで作られたモーションデータでロボットの制御をやりたいと考えてます。
ロボットのシュミレーターは
OpenHRP3
http://www.openrtp.jp/openhrp3/jp/about.html
を使おうと考えてるんですが、そのためにはMMDSの力学計算アルゴリズムも同じものを使っていないと役に立たないわけです。
物理演算部分をプラグインとして切り離していただけたらな〜と思うんですがどうでしょう？
-
ん…たしか上のほうで Bullet 使ってるって言ってなかったけか…
でもこの場合はmmdモデラ作成したモデルに対しての最適化を施しつつの
ライブラリの組み込み作業を、という話だと思うので
そこから先の部分はケースバイケースなんジャマイカ？
おそらくだけど mmd 上でそれらしくみせる最適化と
実際上のロボティクス上で有用である最適化のノウハウは違うような…
でもbullet使ったソース事態はぼちぼち公開されてるのもあるしそこは
参考になるかもしれん
-
それぞれのコンポーネントを独立性の高いものにして
API公開するとかのアプローチとれば事実上なんでもありに出来るでしょうけど
作りながら意見聴いてる段階でそこまで構造きれいに出来てるかはよくわかんないですね。
何度かソース整理しないと構造的にきれいなものは作れないって感覚はあります。
-
物理演算エンジンはゲフォユーザーだったらPhysXが使えると便利そうだし、AMD(ATI)もBulletやHavok(インテルと共同)をGPUに組み込もうとしてるからなー。
エンジンがモジュール化されてるとこういう機能を組み込むのが便利そう。
-
PMDの剛体をまんまロボテクス系演算に流用できるの？
MMDサイクルとは必要な精度がかなり違うと思うけど…
-
>>666
CNCなんかと違って二足歩行ロボットとかかなりいいかげんですから。
小型のなんか軽いから力学無視して座標打って動かしてるだけですし。
>>664
プラグイン使うプログラムは初めからそれが前提で設計されてないとできないんですよね。
ＭＭＤは設計思想にそれがないために後から実装することはできなかった。
-
専用モデル作って専用演算ロジック作って…て、利点があるのかなと
物理演算を差し替えて水中風とかスローモーションとか、夢が広がるけど
-
別にモデル作ることは難しくないし、力学計算アルゴリズムは０から作る必要はなく、
出来合のもの使えばいいだけ（というか、OpenHRPの二種類の力学計算アルゴリズム以外のものを実装できるかわからない）
-
お互いにどんなメリットがあるのかさっぱり見えない話だな
-
MMD関係ないような気が
-
>>670
私には新幹線が開通すると人の往来が増えるよね的なイメージしかできないですね・・・
-
ロボットのモーション造りが結構大変なんでモーションデータを共有したいんですよ。
ダンシングドールの人とかモーションつくるのに数ヶ月かかってるわけで。
-
訳：面倒だから人任せにしたい〜
-
MMDSの人が対応しますっていうなら止めないけど
自分でやれって言いたいわ
-
間をはしょらずに説明してほしいな。
話が飛躍しすぎて何言ってるかわからん。
-
>>674-675
自分でやりたいからプラグイン化を提案しているわけですが。
プラグイン化だけは作者でないとできないので自分じゃどうにもできないですね。
あとメリットというのも、機能が必要な人間が好きに作ればいい〜ってのがプラグイン化の思想なので
ここを否定されるとプラグイン化自体が否定されてしまいます。
どの機能まで拡張可にするかは作者さんの判断次第なのでご自由にどうぞ。
-
まぁ人間の世界の物なんてほとんど借り物ですよ、借りるルールは有りますけど
ロボットうんぬんはともかくとしてプラグインに関しては将来的に組み込めるようになって欲しい。
-
ID:xTguf.wE0のやりたい事って物理エンジンをプラグイン化しても
出来ないと思うんだがｗ
-
http://www1.axfc.net/uploader/Sc/so/261408
そんなわけで更新です。
・アセットマネージャーでルートフォルダのデータを認識できないのを修正
・背景用のＸファイルの読み込みに対応
・骨の計算軸のバグを直しました。
・テッセレーションに対応
⇒ハード的に対応してる必要あり
⇒GeForce4xx〜 or RadeonHD5xxx〜
ぶっちゃけキャラモデルに関してはそもそもポリゴン数が多すぎて
テッセレーションしてもほとんど意味ないですね。重くなるだけっぽいです。
ディスプレイスメントマップに対応してからが本番なのかな。
＞物理エンジン
現状ではキャラのゆれ物くらいでしか物理は使っていませんが、
ロボットの挙動がどうこうとなるとキャラのモーション自体が
手付けじゃなくパラメーター制御でやりたいっつーことなんでしょうか。
そもそも現状で力学計算は一切してないので（ていうかキーアニメーションですし）
どういう実装を望んでいるのかがちょっと分からないです。
-
横レスだけども、ロボットの制御への応用は、
PCでポーズ作り→実機が対応（物理制御でバランスを取る）
をやりたいのか。似た動画があるので張っておく。
【V-Sido】赤い彗星のＭＳを市販機ベースでつくってみた
http://www.nicovideo.jp/watch/sm12693302
-
MMDSでロボットを制御したい人がどれくらいいるんだろ
可動式のミクフィギュアでも発売されてて
連動して踊ってくれるとかならちょっと興味あるけどｗ
-
>>682
発売されたらぜひゲッダンをおどらせてみたいなぁｗ
-
よく理解してないけど
物理エンジンをプラグイン化するとして
そのやりたいことをするにはプラグインがボーンの挙動を決める仕組みが必要だったりするんじゃないかな
いまのMMDは物理エンジンが動かしているのは剛体であってボーンじゃないわけだけど
姿勢制御関係無しにモーション作成だけなら物理エンジンとは関係ないし
-
MMDでモーションつけてそのモーションをVMDに出力、出来上がったモーションは自作ツールでロボット用のモーションに変換、で出来ないの？
プラグインをつくろうかって人なんだからVMDからのコンバーターぐらい作れるだろうに
-
どういう実装をしたいのか考慮する必要はないかと。
「物理演算部分をプラグインにして欲しい」という具体案を出しているので、
それに対してyes/noでいいんじゃないのかな？
|
|
掲示板管理者へ連絡
無料レンタル掲示板
