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

1：名無しさん＠お腹いっぱい。：2011/08/19(金) 22:34:34 ID:K4ujWrrk0: 樋口M氏がMikuMikuDanceの開発終了を発表されましたので
それを引き継ぐ「MMDツール」開発に関する話題を取り扱うスレッドです。

■話題に上がったソフト一覧
MMD丼（MMDS）
MMDp
MikuMikuStudio(仮称)

■前スレ
次期MMDツール開発関連スレ
http://jbbs.livedoor.jp/bbs/read.cgi/music/23040/1306501296/

■次スレは>>970が建てる事
次スレに必要な議論はそれまでに済ませておくべし
>>970が音沙汰無い場合は>>980に一任
>>980も音沙汰無い場合は誰か適当に
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 で問題なし。終了