次期MMDツール開発関連スレ Ver2 - 1313760874

703：名無しさん＠お腹いっぱい。：2012/09/06(木) 21:34:39 ID:DrXnJeis0: >>699
たとえばボールが床に何度か弾んで
転がるモーションをＭＭＤ（ＭＭＭ）で作成するとき
タイムラインで「まぁこんな感じかなぁ～」と適当に補間曲線を付けて
ブックマーク間のフレームを再生してみてイメージと違ったら
再生を止めて、また補間曲線を調整し直して・・・
再生を止めて、また補間曲線を調整し直して・・・
の繰り返しですが。

これを再生中に補間曲線を弄れてたらすごい便利じゃないかと

再生途中のボーン操作はこれの二の次の願望ですね。
704：名無しさん＠お腹いっぱい。：2012/09/06(木) 23:29:52 ID:kj1mNBlU0: MMD曲線の表示はまだ組み込んで無くて申し訳ないけど
イメージ的に
http://www.dotup.org/uploda/www.dotup.org3394430.png
↑の右下画面が指定時間を無限ループ
別画面でボーンをいじったり
下に出してる補完曲線とキーフレームを視覚化したグラフをいじったりできて
それが右下のうっとりループ画面にもリアルタイムに反映されればokでしょーか？
705：名無しさん＠お腹いっぱい。：2012/09/07(金) 02:37:34 ID:oK3FLAH60: PMDエディタの対抗ソフト…
なんて誰も作れないか
706：名無しさん＠お腹いっぱい。：2012/09/07(金) 03:59:42 ID:j6Hbbqsg0: ・PMDEの開発はPMXEとして継続中
・操作対象(PMX)の仕様が、今後PMXEに合わせて変更になる可能性が大きい
・機能的に大きな不満を持っているユーザーの比率が多いとはいえない
・画期的な新機能が広く必要とされる状況ではない

・・・現状だと、対抗ソフト作る動機が乏しい気が
PMX対応しても、本家押しのけて新仕様を追加できるわけで無し

PMDの仕様の範疇なら、操作性の改善や操作方法の変更くらいしかやることが無いだろうし
もし作ったとして、使ってみる人は居ても、使い続ける人が居るかというと、相当ハードル高いんじゃなかろうか
707：名無しさん＠お腹いっぱい。：2012/09/07(金) 07:33:54 ID:Nhb04Azc0: PMDエディタはモデルデータをPMDとPMXにするコンバータみたいなもんだからな
つーかPMXEとか初耳だわ
708：名無しさん＠お腹いっぱい。：2012/09/07(金) 07:35:12 ID:Nhb04Azc0: ああ、PMXエディタのことか・・・
新形式かと思ったぜ
709：名無しさん＠お腹いっぱい。：2012/09/07(金) 20:23:49 ID:kEp24Iis0: >>704
良い感じですね！
下の補間曲線は連続ベジェなのでしょうかもしそうだとしてキーをベジェで弄れるなら
それだけでも十分なくらいですね
連続ベジェならその曲線だけでも動きが想像できますから
それに加えて実際リアルタイムで動きが見れるならまじ嬉しいです
710：名無しさん＠お腹いっぱい。：2012/09/07(金) 21:20:47 ID:f45GhlF60: >705
対抗できる可能性があるのは
メタセコイアの作者さんぐらいじゃないかな。

今プラグインで無理やりやってる機能を本体に取り込んだ上で
もっとMMDとの親和性を高めればPMDEの対抗馬となりうるかも。
711：名無しさん＠お腹いっぱい。：2012/09/07(金) 21:24:03 ID:QfLh5j1k0: 張り合うために対抗するとか無意義じゃね
712：名無しさん＠お腹いっぱい。：2012/09/08(土) 02:57:12 ID:TWuPLjEw0: 自分の場合むしろ一番の原動力になりそうなエネルギーだな
713：名無しさん＠お腹いっぱい。：2012/09/08(土) 09:36:56 ID:HGgOoEcc0: 俺ならこうするのに！　って動機で突っ走るのは悪い事じゃないと思うがな

一極化しちゃうと停滞するのは何でも一緒だし
714：名無しさん＠お腹いっぱい。：2012/09/10(月) 01:43:38 ID:bd9Ck3XQ0: >>709
トライ＆エラーをできるだけめんどくさくなくしたいのでリアルタイムは必須条件かとー

で、下の曲線はハンドルを自動生成したベジェですがMMD曲線ではありません
*画像左下ペインの足元のぐにょぐにょっとした線をグラフ化したものです
*っていうかこのアプロダ、保存期間短いですね。

で、「連続ベジェ」というとキー位置の左右のハンドルの傾きが同じベジェのことだと思いますが
vmd(MMD曲線)の仕様上新たに自動もしくは手動でキーを追加しなきゃいけなかったりするので
操作性においてどこまでご期待に答えられるかはまぁ頑張るッスとしか言えないです
*完全にベジェ仕様で作ってvmd化ボタンを付ける可能性すらあります

ネギドリルなどのドラマ作成支援として
UTAU音源読み込んだりVOCALOID2とVSTi接続してツール上で喋らせるの作ろうとしてたけど
まぁまずはモーション作成がひと段落してからですねー
715：名無しさん＠お腹いっぱい。：2012/09/10(月) 02:35:46 ID:MOrfxI660: >完全にベジェ仕様で作ってvmd化ボタンを付ける可能性すらあります
個人的にはこれでいいと思うな
MMDとの完全互換を狙うつもりでないなら（そんなのはMMD使ってれば良い話だし）何も内部構造にまでVMDフォーマットを維持する必要はないと思う
パッと見での分かりやすさという意味ではMMDの補完曲線も優れているのかも知れないけど、モーションの完成度を突き詰めていく過程であっという間に限界がやってきて、その限界を超えるために多段化したりとか本来なら必要のない工夫が必要になってるしね
716：名無しさん＠お腹いっぱい。：2012/09/10(月) 04:07:30 ID:bd9Ck3XQ0: 位置のグラフ化は良いとして回転のグラフ化はどうしたもんか
ローカル方向ベクトルのＸＹＺとひねりのRollでお茶を濁すか。

多段ボーンの場合また違った最適なグラフもあるだろうからちょっと沼へ旅立ちますね。
717：名無しさん＠お腹いっぱい。：2012/09/12(水) 05:58:59 ID:zmTq6/QE0: 別にクォータニオンの補正を各軸に分けなくてもいいと思うが
718：名無しさん＠お腹いっぱい。：2012/09/15(土) 22:37:48 ID:eVZ2G3us0: クォータニオンのグラフ化、数値で見せるのに直値は無いなー、じゃ方向ベクトル見せるかーってことです
ボーンのローカル方向からの差分でRoll、Pitch、Yaw (ひねり、緯度、経度)出してそれのグラフ化かなー
719：名無しさん＠お腹いっぱい。：2012/09/15(土) 23:30:48 ID:hFvxssjQ0: 回転成分に関しては諦めてクォータニオンまんまで行くか、もしくはそれを捨ててベクトルと真っ向勝負するかどちらかが良いと思うな。
クォータニオンとベクトルとのいい所取りみたいなの目指すと結構泥沼にハマると思う。MMDSもその辺で苦労してた気がする。
どの道クォータニオンだと軸成分毎にleapって出来ないから仮にグラフ書くとしても分けない場合と同じになるし。
720：名無しさん＠お腹いっぱい。：2012/09/16(日) 00:34:15 ID:hAC39DSI0: ４つのクォータニオンでのBezier係数つかったSlerpは考えたりもしたけどそこはいろいろめんどくさそうなんでvmd準拠で２姿勢のslerpで
グラフの表示だけを人が見て理解できる数値にしようかとー

*やっと無料VC2010でx64のビルドできるようにできたーめんどくさかった…。
721：名無しさん＠お腹いっぱい。：2012/10/02(火) 01:07:10 ID:NHZACyKA0: 樋口さん嫌がるかもしれないけどikx.cppの気になるところを修正

ここ↓
// Z*X*Y順
// X軸回り
float fLimit = 1.535889f; // 88.0f/180.0f*3.14159265f;
float fSX = -temp._32; // sin(θx)
float fX = (float)asin(fSX); // X軸回り決定
float fCX = (float)cos(fX);

// ジンバルロック回避
if(fabs(fX) > fLimit){
fX = (fX<0)?- fLimit: fLimit;
fCX = (float)cos(fX);
}

// Y軸回り
float fSY = temp._31 / fCX;
float fCY = temp._33 / fCX;
float fY = (FLOAT)atan2(fSY, fCY); // Y軸回り決定

// Z軸回り
float fSZ = temp._12 / fCX;
float fCZ = temp._22 / fCX;
float fZ = (FLOAT)atan2(fSZ, fCZ);

　↓

fCXはtemp._31とかを割るために使っているけど
fSY、fCYはatan2に渡すベクトルなので同じ値で割ったところで精度が落ちるだけなんで削除
ジンバルロック回避のところでfXを±88度以内に抑えているのでfCXはマイナスになることもないので問題なし

それを踏まえたコード
// Z*X*Y順
float fX = clamp( asin( -temp._32 ), -fLimit, fLimit ); // X軸回り決定
float fY = atan2( temp._31, temp._33 ); // Y軸回り決定
float fZ = atan2( temp._12, temp._22 ); // Z軸回り決定

その下の// 角度の制限もよく見れば同じコードがＸＹＺと３つ並んでるだけなので関数化して見やすく

fX = LimitAngle( fX, p_bone[tv].rdlimit.x, p_bone[tv].rulimit.x, j<ikt );
fY = LimitAngle( fY, p_bone[tv].rdlimit.y, p_bone[tv].rulimit.y, j<ikt );
fZ = LimitAngle( fZ, p_bone[tv].rdlimit.z, p_bone[tv].rulimit.z, j<ikt );

とかやると角度制限のソースZ*X*Y順、X*Y*Z順、Y*Z*X順の３つが１画面に収まる
722：名無しさん＠お腹いっぱい。：2012/10/03(水) 08:28:22 ID:PpSxnnb20: ああ、すげぇいい情報だったわ
マイプログラムの質が一歩上がったって気分だ。ありがとう
724：名無しさん＠お腹いっぱい。：2012/11/16(金) 17:03:20 ID:dg2.vWqs0: テスト
725：名無しさん＠お腹いっぱい。：2012/12/13(木) 16:02:31 ID:wpvugyQE0: なあ、MMDの色の算出ってどうなってるか教えてくれないか？
テクスチャ使われてない材質がMMDのような色にならないんだが・・・
726：名無しさん＠お腹いっぱい。：2012/12/13(木) 19:36:23 ID:VsYrwRLk0: >>725
拡散色と環境色の混合らしい
PMDColorCalc使うと便利ですよ
727：名無しさん＠お腹いっぱい。：2012/12/13(木) 20:40:57 ID:wpvugyQE0: いや、ソフトじゃなくて・・・計算式を知りたかったんだ
MMEを見るとアンビエント*ライト色+デュフューズになってるっぽいけど
それでもなんか合わない気がするんだ
728：名無しさん＠お腹いっぱい。：2012/12/13(木) 21:56:11 ID:VsYrwRLk0: >>727
後足りないとすればtoonじゃないか？
729：名無しさん＠お腹いっぱい。：2012/12/13(木) 22:02:43 ID:1qdDTl6Y0: ディフューズ×ライト＋アンビエントだよ
730：名無しさん＠お腹いっぱい。：2012/12/13(木) 22:24:29 ID:IJPwEDyo0: まあ普通はそうなんだけど、MMDをPIXで覗いてみると
Diffuseは0(黒)で、AmbientにDiffuse色が、EmissiveにAmbient色が入ってるんだよね

初めてこの設定を見た時はたまげた憶えが
731：名無しさん＠お腹いっぱい。：2012/12/13(木) 22:38:25 ID:1qdDTl6Y0: つまりはどゆこと？
732：名無しさん＠お腹いっぱい。：2012/12/13(木) 23:09:20 ID:wpvugyQE0: MMDはちょっと特殊ってこと・・・
733：名無しさん＠お腹いっぱい。：2012/12/13(木) 23:29:26 ID:1qdDTl6Y0: んーと、MMDではDiffuseとかそういった色の名前は出てこないから、
PMDEが色名を間違えたってこと？

それとも、MMD内部での色の名前とその扱われ方に食い違いがあったから
PMDE側で意図的に別の名前をつけたってこと？
734：名無しさん＠お腹いっぱい。：2012/12/13(木) 23:46:50 ID:T3sctgiQ0: full.fxかMikuMikuDance.exeのリソース(無圧縮テキスト形式のシェーダ)をバイナリエディタで取り出してそれみりゃ良いんじゃね？
735：名無しさん＠お腹いっぱい。：2012/12/14(金) 09:28:33 ID:tAfrzOxk0: あー、色が合わない原因がわかったわ。フォーマットが原因だったようだ。
DXGI_FORMAT_R8G8B8A8_UNORM_SRGBからDXGI_FORMAT_R8G8B8A8_UNORMにしたら
狙った通りの色になった。なんつー罠だ・・・
736：名無しさん＠ダヨー：2013/02/25(月) 19:17:09 ID:4.9T9oEo0: 今からMMD始めるなら本家MMDとMMMどっちがいいんだろう
737：名無しさん＠ダヨー：2013/02/25(月) 20:10:33 ID:I1c/LH/.0: うむ、MMMには未来がありそうだよね。
でも、未来しかなさそうなんで、現在やるならMMDだな。
738：名無しさん＠ダヨー：2013/02/26(火) 18:11:34 ID:fAmo2g4U0: 本はMMDのしか出てないし、講座動画なり記事なりもほとんどMMD。
MMDでないとうまく動作しないモデルがある。
MMDでないと使えないエフェクトがる。
MMDの方が起動がはやく、軽い。
バグが無いわけではないがまあ安定しているし、開発終了してるので操作も変わったりしない。
64bit版がある。

MMMの方が多機能でいろいろ便利な機能があり、さらに機能が増えつつある。
MMMでないとPMXの新機能、フル機能が使えない。

好きな方を選ぼう。
739：名無しさん＠ダヨー：2013/02/26(火) 18:24:14 ID:rbSz.yrU0: MMMはもうちょっと安定して、MMEが問題なく読み込める様になってからかなぁ。
740：名無しさん＠ダヨー：2013/02/26(火) 22:46:06 ID:oP3M/5Fg0: ５年後も並走状態が続いてるんだろうね
使用比率が逆転するのはいつの日か
741：名無しさん＠ダヨー：2013/02/27(水) 04:12:07 ID:I0q8RviE0: 逆転するかな？
しないんじゃないかな
742：名無しさん＠ダヨー：2013/02/27(水) 08:02:22 ID:37WbLmCU0: MMDは開発がとまってるからねえ。
MMMが安定性を増していき、
かつ便利機能を加えていけば逆転できるとは思うが。
743：名無しさん＠ダヨー：2013/02/27(水) 12:32:47 ID:2m.K.8ec0: 機能追加が止まらないから安定する日はしばらく来ない気がする。

安定版欲しい。
744：名無しさん＠ダヨー：2013/02/27(水) 23:14:34 ID:w4Q8EiZ.0: まーでも開発者のモチベーション的には
安定版より新機能追加の方がテンションあがるでしょｗ
745：名無しさん＠ダヨー：2013/02/27(水) 23:18:10 ID:e8xTy59s0: でもそのままじゃ永遠に安定版出ないって事に…ｗ
746：名無しさん＠ダヨー：2013/02/28(木) 09:14:04 ID:/2g2vvU.0: やれるときにやれるだけ詰め込んでほしい
バグ取りも随時やってるわけだし
使う側としては常に最新バージョンにする必要はないし、その時々でエラーの出ないバージョンを使えばいいこと
747：名無しさん＠ダヨー：2013/02/28(木) 09:49:37 ID:9Xa.WKZ60: そんなに落ちるのか？　MMMって
・・・俺らも気をつけんとな
748：名無しさん＠ダヨー：2013/03/01(金) 01:13:36 ID:PpK1Q/nM0: バグ報告がメールベースになって遭遇したバグが未知のものか
報告済みのものか俺だけのものか判らなくなってしまったのがなぁ
再現手順を確立してメールにまとめてる最中にFIX版がきて、よかったメールしなくてって
事が２，３回あってから手の速い誰かがもう報告してるだろうとか思ってあんまり
再現調査もしなくなってしまったｗなんかごめん
749：名無しさん＠ダヨー：2013/03/01(金) 07:07:34 ID:OnIh71Rk0: >>748
いや、俺も同じ事思ってる
数回メールで報告した事があるが既出なのかどうか確認するすべがないから結構躊躇する
なぜ掲示板ベースじゃダメなのかと思う
750：名無しさん＠ダヨー：2013/03/01(金) 18:08:17 ID:XFR9PbkM0: メールだと、自分も報告しないなぁ。
バグらしいの見つけたら、まずここの掲示板に書いてる。

それと、更新履歴がその他もろもろの修正ってなってるから、いつどのバグが修正されたかわからないのが不便。
751：名無しさん＠ダヨー：2013/03/01(金) 18:39:09 ID:k0O0Rmy60: いちばんいいのはトラッカーを設置することだろうね
752：名無しさん＠ダヨー：2013/03/09(土) 06:09:35 ID:UIxm6zuw0: 開発者がそう言ってるのだからそれに従うまでなのだが、「なぜ窓口がメールだけなのか？」は知りたい
俺なら直接メール飛んできたら面倒くさくてたまんないんだけどなぁ
753：名無しさん＠ダヨー：2013/03/09(土) 07:11:39 ID:jbG5Ff6.0: 現状その方がノイズが少ないんじゃない？
でもバグ報告スレに書いておけば検証・改善されてるからどうでもいい
754：名無しさん＠ダヨー：2013/03/09(土) 07:40:26 ID:63aPJMDc0: 丁寧に再現情報をまとめてメールしようとする人は同時に
「既出で重複してたら迷惑だし」と気を使う人で貴重な情報を出し渋る一方
「〇〇できねーじゃねーか早くなんとかしろゴルァ」的な人は
遠慮しないのでそういうメールはどしどし届いてたりして
755：名無しさん＠ダヨー：2013/03/09(土) 10:30:28 ID:tbBgX0/Y0: メール出したこと無いけど、似たような報告が多数あっても対応したら全て返事してるのかな。
それだけでもすごく面倒そうに思うんだけど。
重要度が低いのは対応は後回しになるだろうから、なお更管理が大変そう。
756：名無しさん＠ダヨー：2013/03/09(土) 20:39:51 ID:3Q6BNY5o0: バグ報告が来たら、即座に対処して、そのたびにアップデート出しているなら、メールで足りるわな。
バグ報告する側も、最新版を使っている限りは未報告と考えて良い
757：名無しさん＠ダヨー：2013/03/09(土) 22:49:17 ID:63aPJMDc0: >>756
>バグ報告する側も、最新版を使っている限りは未報告と考えて良い
どうしてそう言い切れるのかよく分からんが。確かなのかそれ
758：756：2013/03/09(土) 23:43:50 ID:Z20I9SHA0: >>757
ああ、ごめん。仮定の話。

もしも、
> バグ報告が来たら、即座に対処して、そのたびにアップデート出している
という状況であるなら、

> メールで足りる
> バグ報告する側も、最新版を使っている限りは未報告と考えて良い
ということ

逆に、修正が追いつかず、積み残しがあるなら、メールは不適切だと思うよ
759：名無しさん＠ダヨー：2013/03/16(土) 06:11:26 ID:AW0W6c4U0: 音声波形に応じてアドリブでミクさんが踊るソフトを作って下さい
760：名無しさん＠ダヨー：2013/03/16(土) 07:34:44 ID:FF7rCjy.0: もしかすると>>759は知ってるんじゃないかと
疑いながら、「キャラミんOMP」があると書いてみる。
761：名無しさん＠ダヨー：2013/03/16(土) 09:40:30 ID:BktAUMlo0: ソフトの完成度がまだアドリブで踊すどころじゃないってのが俺らの本音だろう
MMMの開発速度には勝てんわ
次期になるのは諦めてwin8のWindowsストアアプリで作り直している俺がいる・・・(´･ω･`)
directx11使用のマイナー路線でいくぜ
762：名無しさん＠ダヨー：2013/03/17(日) 02:24:12 ID:DIQkYyfM0: 一度ベースを作ればあとは楽なんだろうが、まずIKで躓き、PMXで躓き、Bulletで躓く。
763：名無しさん＠ダヨー：2013/03/17(日) 05:12:14 ID:8a/KUyPQ0: モーフィングとかBDEF-SDEFのデフォームをシェーダーでやろうかなと思ったけど
VTF必須になるからやめておこう・・・。
764：名無しさん＠ダヨー：2013/03/24(日) 10:15:16 ID:YLdJfdKo0: やべぇ、Windowsストアアプリでbullet動かせねぇ
原因わかんねぇ、アプリで使えるようにコンパイルしようとするとエラーはきまくりで詰んだ
これは黙って従来型を作れっていうお告げなのか。俺はそっとWindowsストアアプリ版MMDをあきらめた・・・
動かせたって人がいたら教えてね(´･ω･`)
765：名無しさん＠ダヨー：2013/03/24(日) 23:34:53 ID:SAunhxdg0: Win32APIやCRTにかなり制限かかるから、既存のネイティブライブラリ使おうとすると
結構手直し必要なんだよねアレ
766：名無しさん＠ダヨー：2013/04/04(木) 03:30:58 ID:gnCB3gos0: PMXのIKに関する資料の少なさにキレてる
PMDなら割といろんな人が実装してるんだけども
767：名無しさん＠ダヨー：2013/04/04(木) 03:52:59 ID:mntfTRs20: 資料というかオフィシャルの実装（>>72>>75）を読んでしまうのが一番早いような
768：名無しさん＠ダヨー：2013/04/04(木) 04:54:36 ID:gnCB3gos0: いじめですか？
769：名無しさん＠ダヨー：2013/04/04(木) 04:54:58 ID:9ol7sCHE0: 消えてて落とせないんだが
770：名無しさん＠ダヨー：2013/04/04(木) 10:14:26 ID:kMMGwR8A0: >>764
bulletってvectormathでsse使ってるからそこが原因？

#if defined (BT_USE_SSE) && defined (_WIN32)
#include "sse/vectormath_aos.h"
#else //all other platforms
#include "scalar/vectormath_aos.h"
#endif //(BT_USE_SSE) && defined (_WIN32)

ってあるからscalar使うようにするとか

>>72>>75は>>69で再配布OKってあるけどまだOKなのかな？
771：名無しさん＠ダヨー：2013/04/05(金) 10:18:14 ID:lkILkPdc0: 俺がPMX用に作ったIKでよければ見せるが、果てしなく見難いものだ・・・
772：名無しさん＠ダヨー：2013/04/10(水) 18:32:48 ID:Z66rZMbg0: OKか動画かは知らんが上でやり取りしてる人はいるな
773：297：2013/05/19(日) 22:31:02 ID:DIkCoJbk0: 前回のUPから一年以上空いてしまいましたが、MikuMikuAnimeを更新しました。

MikuMikuAnime Ver.0.130519
ttp://www1.axfc.net/uploader/so/2908046.zip

・表情
・IKを修正
・複数カットの編集・再生（シーン編集モード）

いつの間にかXNAの終了が決定してたorz
中身を全てDirectXで作り直すので、次の更新もかなり先になりそうです。
774：名無しさん＠ダヨー：2013/05/20(月) 14:58:00 ID:X6y..wKM0: >>773
アップデート乙です
OS変えたの忘れて起動しなくてあせったけど
XNAフレームワーク入れたらちゃんと起動しました(Windows8)
775：名無しさん＠ダヨー：2013/05/20(月) 22:19:10 ID:RmgkLcGQ0: XNAが開発終了しても使えなくなるってことはないんじゃないのかな・・・
776：名無しさん＠ダヨー：2013/05/21(火) 00:04:05 ID:72c0DYsY0: 今の世代のDirectXがサポートされる限りは互換性サポート続けるだろうし結構しばらくの間は使えると思う
(Direct3DのRMは開発終了したあといつの間にかdllすら付属しなくなったんだっけか)
777：名無しさん＠ダヨー：2013/05/21(火) 02:29:11 ID:8mWJj04w0: 今の世代のDXはいいとして、DX9がサポートされなくなるのは近いかなと気になる所。
XPのサポート終了も近いし、次のWindowsは大丈夫だろうか。
778：名無しさん＠ダヨー：2013/05/21(火) 09:26:51 ID:6zV3wX7k0: D3DRMは1999年に更新終了
ランタイムが載らなくなったのはVistaからだから、実際のところ結構間はあるよ

D3D9は本当に普及率高過ぎてむしろいつサポート切る時期がくるのか全然見えないくらいだなあ
MS謹製の最新GUIフレームワークであるはずのWPFも、インフラがいまだにD3D9だし
D3D9をちょっとでも利用しているアプリが全滅するWindowsなんて現状考えにくいと思われ

(StoreアプリはD3D9もOpenGLも切ってるけど…）
779：名無しさん＠ダヨー：2013/05/22(水) 01:13:32 ID:/wiFRxeU0: AeroもD3D9Exだし
10以降はインフラが共通だけど9とは大きな差があるものだからしばらくは互換対応されそう
新しく作るなら10以降のが楽だけど

XNAからの移行ならMonoGame(OpenGL)かSharpDX Toolkit(D3D11)あたりがスタイル似てておすすめだよ
780：名無しさん＠ダヨー：2013/05/22(水) 22:17:07 ID:lN1BiwoA0: >>773
いいコンセプトのツールですね
うちの環境だと起動はするけどちょっと挙動不審なので残念です
せっかくだからもっとアニメ制作に尖らせてもいいかも
前後の原画が単色半透明でオーバーレイ表示されるとか
フレーム移動にctrl+ホイールあたり割り当てて動画チェックを手軽にするとか
無理のないペースで更新して下さい
陰ながら応援していきます
782：名無しさん＠ダヨー：2013/08/29(木) 09:50:07 ID:5nps7KX20: レスがあったから何かと思ったら・・・

ところで皆は進行度はどうよ、開発あきらめてるなんてないよな？(´･ω･｀)
俺はDirectX11版をそろそろ見せれるくらいにはなるぜ
783：名無しさん＠ダヨー：2013/09/08(日) 15:53:31 ID:ZSrsqHNo0: MMDにSweetFXを使ったら綺麗になるだろうか
AVI出力の時に効果が反映されないとかあるかもしれない
784：名無しさん＠ダヨー：2013/09/19(木) 06:34:13 ID:LLd94UzU0: MMEのdirectx11化か・・・これは俺らの立場危ういなw
785：名無しさん＠ダヨー：2014/05/15(木) 19:28:46 ID:.G.RpnQk0: DirectX11実装のための開発をしてるとこ増えたなー
本家本元のMikuMikuDance
次期MMD筆頭らしいMikuMikuMoving
ビームマンPと舞力介入Pが技術協力してるとかいうMikuMikuFlex
786：名無しさん＠ダヨー：2014/05/17(土) 19:20:52 ID:tjQIRnM.0: もう何年も次期とか言ってるし、たぶん今後も変わらんよ
本家が開発してるなら俺らは趣味で作る程度さ
787：名無しさん＠ダヨー：2014/05/18(日) 00:05:14 ID:naAwL1Bg0: エフェクトばりばりな動画が増えてきたけどそうなるともうDirectX使ってのリアルタイムはいらないんじゃないのかと思っちゃう。
外部レンダラへ出力して物理レンダリングとかできたらいいなあ。
でもMMDのレンダリングは遅くても1枚数秒、一方物理レンダリングは1枚数分から数時間。
やっぱ時間対効果はMMDがすごく高いなあ
788：名無しさん＠ダヨー：2014/05/18(日) 01:16:23 ID:Vl7tgv3s0: >>787
ttp://www.nicovideo.jp/watch/sm14216695
MME排他になるけど・・重いよ
789：名無しさん＠ダヨー：2014/07/25(金) 23:37:22 ID:01EQ74ko0: DirectX11対応でエフェクトとかそのままじゃ使えなくなるし、
MMMのほうが対応早いからMMD9とMMM11の二極に分かれるかもね
790：名無しさん＠ダヨー：2014/08/07(木) 19:19:02 ID:AsAHaJhw0: DX12特化にしたら幾分か軽くなるのだろうか、マントルみたいに何かのオーバーヘッドを減らすとか書いてあるし
MMMってマルチコア対応以降のx64MMDより
物理演算が幾分か重い感じがする（その分最適化の余地が大きい？）
791：名無しさん＠ダヨー：2014/08/07(木) 23:32:14 ID:6YNkbTpw0: 使ってる物理演算ライブラリのバージョンが違うから、その影響もあるかも。
792：名無しさん＠ダヨー：2014/08/14(木) 18:12:51 ID:AFAAUf5I0: endorphinやMorphemeタイプのモーション作成環境が欲しいな
793：名無しさん＠ダヨー：2014/10/11(土) 20:26:25 ID:huW9r5C60: MMMが重いのはWPFやC#だからだろ
794：名無しさん＠ダヨー：2016/02/09(火) 20:55:19 ID:oGChmVcA0: もうポストMMD開発界隈は下火なのかな？
795：名無しさん＠ダヨー：2019/06/20(木) 05:35:02 ID:4DZZzYXI0: いつの間にか2014年に開発頓挫してたM
MikuMikuFlexの開発後継者が現れててビビるわ
今さらなんの目的で開発してんのか気になる
796：名無しさん＠ダヨー：2019/06/21(金) 20:31:17 ID:kUaYK5cY0: BC7テクスチャとかちゃんとGPUで使えるものがあれば
テクスチャの解像度維持しつつ劣化を極力抑えてVRAM使用量もう少し現実的になるのかな？
797：名無しさん＠ダヨー：2019/06/21(金) 20:35:50 ID:kUaYK5cY0: そういえばPhysXオープンソース化したんだっけ
Bulletと切り替えられるようになれば
物理の互換性落ちるけど散々悩ませられるピクピクしたりブルブル抑えられる可能性がありそうな気も
798：名無しさん＠ダヨー：2019/06/24(月) 21:12:52 ID:MqgqSfy60: ダイナミックボーン実装されんのかな
バネを横にした時みたいに重力に逆らって元の位置に戻ろうとする感じの奴
799：名無しさん＠ダヨー：2019/06/25(火) 12:10:46 ID:4405TFF20: そういう動きをするモーションを作ればいいだけなので別に
自動で動かしたいなら物理演算のジョイントにバネ設定もあるし
800：名無しさん＠ダヨー：2019/06/25(火) 16:33:22 ID:eyw8cNGw0: まぁMMDで今使われてる物理周りは暴れやすいとか融通効かないとか
手軽に動かそうってものから少しかけ離れてきてる感はあるよねぇ
801：＜みく～ん＞：＜みく～ん＞: ＜みく～ん＞
804：名無しさん＠ダヨー：2019/10/15(火) 18:47:55 ID:pz9/bXmc0: MMD杯ZERO2ではどうなるか
805：名無しさん＠ダヨー：2020/09/22(火) 20:34:53 ID:cDoLSK.Y0: 皆さんの意見をお聞かせいただきたいです

やることが高度になってきてMMDは機能不足感が否めなくなってきました
かと言ってBlenderなどの他のエンジンでは要件を満たせないからこそMMDを触っています
そのため有志の方々がDLLインジェクションを用いた拡張機能が実装されているわけですが、
逆にこの実装方法が弊害となってしまいMMMやnanoemなどの他のMMDクローンにてエフェクトや拡張が機能しないことがままあります
さらにハードウェアのスペックが高くてもMMDがそれに追いついていません
この状況を打開することは可能なのでしょうか？
nanoemはOSS化されるようですがMMDをエミュレートしているわけではないので完全な再現が難しいのではと思います
（結局主要なプラグインが動作しないとユーザーも増えない）

また、アセットに関しても問題があると考えております
MMDは膨大なリソースがあるにもかかわらず、GitHubのような巨大な配信プラットフォームがないため、分散配布されてしまい扱いにくいと考えています
MMDにアセット管理システムが統合されれればアセットのダウンロードや管理、クレジットの生成なども自動で確実に行えます
しかしこれもすでに配布されてしまっているため打開策が難しいです

現在、MMD界の盛り上がりが欠けていますがこのあたりにも要因の一旦があるのではと思います
可能なら、このあたりを改善してもっと盛り上げていきたいなと
806：名無しさん＠ダヨー：2020/09/24(木) 20:50:21 ID:tdDktf/c0: >>805
マジレスすると金
金が動かないコミュニティは一時的に盛り上がってもすぐに衰退する
MMD　MMM開発者　モデル　ステージ　エフェクト開発者もほぼボランティア　誰も責任を取る立場にいない
こんなんで発展するはずがない
807：名無しさん＠ダヨー：2020/09/24(木) 21:27:57 ID:N1nAXlC20: >>805
個人が作った勝手アプリに対して自分の都合で生じた齟齬を他人に求めるのは
少し違うと思うかな

>DLLインジェクション
DLLインジェクションはAPIをフックして関数をコールした時に別のdllを読ませますが
それ自体オーバーヘッドにはなりません

>エフェクトや拡張が機能しないことがままあります
DLLで実装されてるとかそういう以前の問題で、UnityシェーダーのHLSLをUE4に持って行って
動作しませんと言っているのと何も変わりません

>さらにハードウェアのスペックが高くても
ハードウエアの性能が引き出せないのは大方DirectX9のオーバーヘッドや
高速化の手法が取り入れられてない事によるものだと考えられます

基本的にDirectX9は勝手に最適化や高速化をしてくれる訳じゃないので
専用アプリ（ゲームとか）はシーンごとに全て専用チューニングが施してあります
つまり自分で用意した環境に対応する専用シェーダーを自分で書いて最適化をしないと
DirectX9はパフォーマンスが出ないって事です

>アセットに関しても問題があると考えております
楽曲や素材の勝手配布サイトが増殖したようなものであって、拡張子がmp3やwavから
PMXやVMDに変わっただけに過ぎず、トップダウンで何かの命令に従っている訳じゃありません
各々が自由意志で自由行動を起こした結果で何の企画も意思統制もない訳で
楽曲や素材の配布サイトに対して何かを強制するのは正直ナンセンス以外の何物でもないでしょう

>巨大な配信プラットフォームがない
BowlRollでもニコニコモンズによる収益はうまい棒数本～数十本程度という事なので
完全に自腹みたいだけど、同等の代替サーバを提供するならその維持費は一体誰が
負担するのでしょう？
808：名無しさん＠ダヨー：2020/09/25(金) 09:12:21 ID:n.ukgSuw0: ＞BowlRollでもニコニコモンズによる収益はうまい棒数本～数十本程度

そ…そうだったのか…
何かもっと貢献者に還元できる方法があればいいんだけど。
809：名無しさん＠ダヨー：2020/09/25(金) 15:00:12 ID:U9SOCq4A0: >>806
お金は確かにそうかもしれませんね
ただ、OSSのソフトウェアの発展を見る限りあれもボランティアだと思うのであっちのようにもっと賑わってくれればいいかなって

>>807
お前らもっとこうしろと文句を言っているのではなく、こういう問題があるからなんとか解決したいって話です
有志の方々のおかげでここまで発展があったことは事実ですし、そういうのをまとめる環境があるともっと賑わうんじゃないかなと

DLLインジェクションについてはオーバーヘッドのことではなくアプリの拡張性の話です。このような形でしか拡張できないのに不便だと感じたので
ハードウェアについてはシングルスレッドシングルGPUでしか動作しないなどのことを示唆していました。DirectXの話は確かにそうかもしれませんね
アセットに関しては別に強制しているわけではないです。ただ事実として現状使いにくいと感じたことはありませんか？
配信プラットフォームの経費についてはそのとおりだと思います。分散システムを活用すれば個人の負担を軽減できるかもしれませんが、それも有志でやるしかなさそうですし

MMDは素晴らしいアプリですしその周辺技術も本当に皆さんの努力の賜物だと思います
ただ、やはり当初想定されていないようなレベルで使われていて機能不足感は否めないと思います（周辺技術や環境なども含め）
このままの状態で行くのも一つの選択肢だと思いますが、この状況を打開するために何か手を打てるならやってみたいなと思ったのでレスを投げさせていただきました
810：名無しさん＠ダヨー：2020/09/26(土) 00:08:04 ID:WVVqyKH.0: >>809
そもそもMMEは拡張が前提とされてないソース非公開のMMDを
凄腕エンジニアが勝手に解析してハッキングした只の非公式MODですからね

拡張性がない物を強引にこじ開けて勝手に作ってしまっただけで
MMDもMMEも拡張できるように設計されてないですし本体の仕様について
一切の情報が提供されてませんから、拡張もへったくれもないんですよ

逆にPMXEは作者がプラグインなどである程度の拡張を許容してますし
必要な情報については全て公開してます
最もPMXE（PMDE）も元はPMDをハックしたもので、最初の想定外は
PMDEで2つめがMMEなのでしょうけど

>ハードウェアについてはシングルスレッドシングルGPUでしか
>動作しないなどのことを示唆していました
シングルスレッドであるかどうかはあまり関係ないんじゃないかな
インテルのターボブーストが1コアしか利かなかった時
AMDよりスコアがよいゲームが多かったのは、リアルタイム3Dは
マルチスレッド向きではないからと言われていますね

Unityも録画プラグイン使うと書き出しが強烈に遅くなったりしますが
GPU→CPU間のコピーが遅いんじゃないかな？とは疑ってますが

>ただ事実として現状使いにくいと感じたことはありませんか？
鶏と卵の順番が逆なのではないかというニュアンスを感じます
後付けじゃ不可能な事だから、そこをどうにか言った所で
堂々巡りで何も始まらないと思います

例えばUnityのアセットストアはデパートやショッピングモールのような
場所を提供する事で出展者にストアライセンスを適用させています
BowlRollも提供形態を規定（何かを読ませるとかPassを設定できるとか）
できているのは場所を提供したことによる引き換え条件ですから
そのような形式でしか、何かを制定することはできないでしょう

>分散システムを活用すれば
掲示板に書き込まれたトレントファイルを起点にしたP2Pネットワークなら
サーバは要らないとは言え、シードやトラッカーが要るので半永久的に
ぶら下げ続ける必要があるので何かしらの負担は強いられる事になるでしょう

個人的にMMDには全く依存する所がなく完全に独立してるので静観してますが
恐らくMMDは緩やかな死を迎えるんじゃないですかね
811：名無しさん＠ダヨー：2020/09/26(土) 03:56:11 ID:lONzhAk60: >>810
何故かあまり会話が噛み合っていない気がしますが
> 恐らくMMDは緩やかな死を迎えるんじゃないですかね
つまるところ、こういうご意見ということですよね。正直このままの状態だと自分もそうなるなと感じています

> 後付けじゃ不可能な事だから、そこをどうにか言った所で
堂々巡りで何も始まらないと思います

こちらについては本当に不可能なのでしょうか？
MMMやnanoemのようなクローン実装がMMD実装を完全に実現できればここについてはある程度打開することは可能かと考えています
>> 805 でも申し上げましたが、自分の質問は「この状況を打開することは可能なのでしょうか？」ということです

この状況を打開するには今のMMD実装だと難しいかと思います
OSSでアクティブな新規MMD実装とそれを取り巻く周辺環境の整備があり、
かつ現状のアセットのほとんどが使える状態になってこそ打開できるのではないかと考えています
他の界隈にはないMMDの特徴はその膨大なリソースです
これを活かしながらなんとかMMDを次のステップへ進めることができないのかと
やはり難しいのでしょうか？
812：海外ツール難しい：2020/09/26(土) 15:23:03 ID:cMxSC10g0: でも、国産キャラのモデルが大量にあって、他にはない日本の風土が表現できるステージがあって、
殆どのアイテムが無料（無料が義務化してる）なプラットフォームはMMMとCMD位ですし、
Fantiaの様な寄付システムで、モデラ―さんエンジニアさんに金を投げることが出来れば、普通に続きそうですけどね。
同人誌にしろ、エアガンにしろ、フィギアやなりきりグッズにしろ、物質的で所有できるアイテムには、安定した産業が付いてくるのだし、
上手い金融方法、購買方法を考えたら逆転できそう。
教育用CGとか、ダンスの教材とか、技術解説用CGとか、医療用とか、イラストのデッサン用とか、の操作の簡潔さを求める分野でやってけないかな
813：名無しさん＠ダヨー：2020/09/26(土) 19:23:39 ID:9oDMnpxU0: このままだとMMDが衰退するからなんとかするぞって話題はいったい何周目なんでしょう？
この板にも「わかりやすいMMDを作る」なんてスレがありますが。。。

MikuMikuPenguin以来繰り返されてきた話題のような気がします。

堂々巡りでっていうだけなら誰でもいえます。出きるのでは？と思うのならやってみせれば良いだけのことです。
もし「出きる」って答えをもらえたらどうするおつもりなんですか？出きるって言ったんだからやってとか言わないですよね？

技術的には今のプラグイン（MMEのことか？）の互換性を求めるとDX9ベースになってしまい、一方で新しいＨＷの恩恵にあずかりたいならDX9を捨てないといけないという矛盾をどう解決してくれるのかに興味がありますけどね。

あとOSSに夢を見すぎだと思います。MMDをオープンソースにすべしって意見を定期的にみるんですが、今のままやるとオレサマ仕様のMMDが乱立して収拾がつかなくなるだけです。MMDが分裂せずにこんなに長くやってこれたのは実はMMDといえばこれしかないという状況があったからということは理解しておいた方がいいです。
成功しているOSSはソースがオープンであることよりもカリスマリーダーがいたりしっかりしたステアリングボードがあって参加者がその決定を受け入れているという状況ができているから成り立っているんです。
それでもLibreOffice/OpenOfficeのような分裂が起こりますけどね（外的要因が大きいので良い例ではないんですが）。
今のMMD界隈でこの人・グループならみんなが決定を受け入れるってあるんでしょうか。MMD杯終末期のごたごたを考えるとなかなか難しいそうですね。
814：名無しさん＠ダヨー：2020/09/26(土) 21:20:38 ID:WVVqyKH.0: >>811
うーん、MMMovingは2年前から死んでるので先がないんじゃない？
nanoemは数か月前にDLした時は動かなかったけど、今回は動いた
暇つぶしにきしめん720pで出力してみたけど、本家の倍くらい掛かる

>MMMやnanoemのようなクローン
MMD/MMEに限った話でその他は入ってないよ

>OSS
kritaでクラウドファンディングがあって日本円で250万ほど獲得してた
OSSと言ってもメインプログラマは仕事する余裕がないほどの激務なので
生活費を募りたいって事だったらしい
日本ならプログラマの平均収入は40万くらいあるし普通に働いて
得られる収入を投げ捨ててまでOSSに従事するメリットがないよね

>MMDの特徴はその膨大なリソース
レンダラもマテリアルもPBRですらないし正直負の遺産の方が大きいと思うかな

負の遺産と言っているのは、PMD由来のボーンのロール（左右非対称）や
マテリアルが多くドローコールが増えやすい製作者のスタイル
ドローコールはレンダラにモダンな最適化手法が取り入れられない限り
パフォーマンスが改善される事はない訳で、既にゲームとは同列に並べられない
技術格差が生じてるだけじゃないのかな

>次のステップへ進めることができないのかと
複数の方法論が人気の名の下に自然淘汰されるだけの自然現象だから
第三者/当事者がコントロールする方法はないんじゃないかな

少なくとも行動を起こして成果/結果を出さない限り是非を問うことも出来ない
必要な事は物理的な現象（結果）だと思うよね
815：名無しさん＠ダヨー：2020/09/27(日) 05:59:24 ID:YwDoVTZ.0: >>813
> もし「出きる」って答えをもらえたらどうするおつもりなんですか？出きるって言ったんだからやってとか言わないですよね？
こちらについてはすでに回答済みです。なんでそう喧嘩腰なんでしょうか？ひとまず落ち着きましょう

> 技術的には今のプラグイン（MMEのことか？）の互換性を求めるとDX9ベースになってしまい、一方で新しいＨＷの恩恵にあずかりたいならDX9を捨てないといけないという矛盾をどう解決してくれるのかに興味がありますけどね。
ある程度話は理解できますが、私はバリバリのクライアントエンジニアではないのでマイグレーション含めてこれが可能なのかどうかを質問しているのです。どうなるのかは私も気になりますね（笑）

なんとなく会話が成立しない理由がわかってきました

> あとOSSに夢を見すぎだと思います。MMDをオープンソースにすべしって意見を定期的にみるんですが、今のままやるとオレサマ仕様のMMDが乱立して収拾がつかなくなるだけです。MMDが分裂せずにこんなに長くやってこれたのは実はMMDといえばこれしかないという状況があったからということは理解しておいた方がいいです。
解決するためにはどうすればいいと思いますか？建設的なことを話しましょう。今のままやるとということは今のままではないのなら不可能じゃないのかと思ってしまうのですが

> 成功しているOSSはソースがオープンであることよりもカリスマリーダーがいたりしっかりしたステアリングボードがあって参加者がその決定を受け入れているという状況ができているから成り立っているんです。
概ね同意しますが、カリスマリーダーかどうかは問題ではありません。アクティブなリーダーかどうかだと思います。成功しているOSS全てにカリスマリーダーがいるわけではないことはGitHubを見れば明らかです

>>814
> 得られる収入を投げ捨ててまでOSSに従事するメリットがないよね
仕事以外の時間でコミットするものなのですが……
仕事でOSS活動している方もいますけど多くは趣味の時間でやっているのではないでしょうか？

> 少なくとも行動を起こして成果/結果を出さない限り是非を問うことも出来ない
結果を見ないと判断できないのでしょうか？仮説検証やPOCという段階が必要だと思います
おっしゃるとおり私も生活がありますのでその片手間の作業となるわけですが、無理なものに対して変に時間を注ぎたくないので質問させていただいています

> 複数の方法論が人気の名の下に自然淘汰されるだけの自然現象だから
第三者/当事者がコントロールする方法はないんじゃないかな

そうかもしれませんね

何故か話がそれがちですが、私がお聞きしたいのは >>805 にあげたような問題の打開策があるかどうかです
細かい技術スタックの話がメインではありません（理由の説明に必要な場合はあると思いますが）
ここの問題についてはこういうことができるからなんとかできそう、逆にここについてはこういう理由で難しいのような感じで回答して頂けると助かります
816：名無しさん＠ダヨー：2020/09/27(日) 13:11:07 ID:ieMdlVCo0: すまんが体裁は整ってるんだけど出してる内容の理解が出鱈目で
その部分の知識の誤りを訂正してるだけなんだよね
要は仮説Aがあるので仮説Bは成り立ちますよねって言うから
仮説A自体が只の誤解なので仮説Bは成立しないと指摘してるだけです

ハッキリ言ってしまうと>>805は80～90％が別の原因によって生じた事柄を
憶測/妄想でこじつけてるだけで因果関係がないのよ
>やることが高度になってきてMMDは機能不足感が否めなくなってきました
>かと言ってBlenderなどの他のエンジンでは要件を満たせないからこそMMDを触っています
正しい内容があるとすればここだけですね
817：名無しさん＠ダヨー：2020/09/27(日) 13:47:21 ID:ieMdlVCo0: 手短に要点だけあげるなら
・ハード性能に見合うモダンなソフト若しくはオクルージョンカリングやシェーダーバッチングなどモダンな最適化手法を用いたレンダラ
・fxの高い互換性を確保した実装
・MMD資産の転用をしたい
というものを作りたいって話じゃないの？

多分普通に歓迎されると思うのでexeを作ってβテストすればいいだけなんじゃ？
反対する人もいないと思いますよ
818：名無しさん＠ダヨー：2020/09/27(日) 19:19:59 ID:rQmWhgd60: いつもより言葉使いが丁寧で知識もそれなりにあってきちんとはしてるものの、内容は結局いつも通りなのか
819：名無しさん＠ダヨー：2020/09/28(月) 17:18:01 ID:7JW3uxrE0: どうせいつもの僕ちゃんのgtx1060最新ハードなのに4k書き出しが
紙芝居なんでちゅプンプンって面白生物だろ
ハードが異常動作しなくなるまで仕事量を減らせばいいだけなんだが

そもそもソフト/ハードの中で何が起きているのか知る事が出来るのは
プログラマ（エンジニア）だけだし寧ろ解析はエンジニアの独壇場なんだが

専門家が素人に解析できないので教えろ下さいとか流石にねーわ
820：名無しさん＠ダヨー：2020/10/06(火) 21:59:59 ID:fbi28JaQ0: D3D9やOGL3みたいな古いAPIの方が
低位層で現代的なHWに最適化しやすいような気がする
821：名無しさん＠ダヨー：2020/10/07(水) 00:13:53 ID:ekgTtUh.0: MMDにはあんまり関係ないけど
リアルタイムレンダラーにおけるFPSってホント意味ないんだなって思った

アプリ側で自己申告してるドローコールが60fpsや120fpsだったとしても
実際モニタに出てるのは倍速再生とかアレやソレやで有耶無耶になってて
それでもエンドユーザの大多数はそれで満足してるとか

動画作成のためのMMDには関係ないんですけどね
822：名無しさん＠ダヨー：2020/10/07(水) 08:55:22 ID:IJ13yhRc0: >>821
MMDの場合は60fps設定と120fps設定で挙動が違うんですがそれは
823：名無しさん＠ダヨー：2020/10/07(水) 21:26:15 ID:ekgTtUh.0: >>822
ごめん
MMDの動画出力の出力レートとは関係ない話なの
824：名無しさん＠ダヨー：2020/10/08(木) 01:56:40 ID:C9crlPYc0: Bullet physics simulation runs at an internal fixed framerate of 60 Hertz.
Bulletの物理演算は内部的には60ヘルツ固定と書いてある

240だろうが120だろうが60fpsでしか演算しないって事
825：名無しさん＠ダヨー：2020/10/08(木) 08:31:12 ID:yedcoERA0: >>824
By default,って前に付いてない？
826：名無しさん＠ダヨー：2020/10/08(木) 17:40:13 ID:C9crlPYc0: 付いてはいるが、変えても反映されないという話もある
普段使いもしないVC++を検証するために
わざわざVS2019再インストールするのが面倒なんだよ
ビルドして確認して報告しくよろ
827：名無しさん＠ダヨー：2020/10/18(日) 14:36:13 ID:4IKskrko0: Sabaだと簡単にBPのレート変えられるから比較してみた。
動画出力は60fpsでBPは120fps(Sabaのデフォルト)と480fps。
120だと足の貫通が見えるが480は貫通はしないが暴れやすい。

ttp://tstorage.info/c1vgl0g87o35
828：名無しさん＠ダヨー：2020/10/18(日) 14:41:55 ID:iWJKIBFw0: それ使ってりゃいいんじゃね？
829：名無しさん＠ダヨー：2021/09/08(水) 04:27:27 ID:aPriq16Q0: ここも動きがなくなったな
830：名無しさん＠ダヨー：2021/09/08(水) 04:48:44 ID:cKPpDAJk0: なんかMMDも下火になりつつあるし今更アップグレードされていってもね
831：名無しさん＠ダヨー：2023/04/16(日) 17:42:55 ID:BVv7IAAE0: Blender で問題なし。終了