レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
次期MMDツール開発関連スレ
-
樋口MがこのたびMikuMikuDanceの開発終了を発表されましたので
それを引き継ぐ「MMDツール」開発に関する話題を取り扱うスレッドです。
プログラマー以外の方も含め、幅広いご意見をどうぞ
-
こんな煽り高ぶったレスを先にコビペしたら
スレにプログラマ＾−が集まらないだろう。
ここで活動したら同じ様rに煽られると勘違いされるよ。
-
仕切ってる気分の奴が煽る気マンマンの馬鹿だもん
スレ消して仕切り直したほうがいい
-
>>10
コピペしてるのは一部の変な人だし明後日にはいなくなるでしょう
スレッドは焦りすぎと取られるかもしれないが、いつでも意見交換
できる場所としては早すぎることはないと思う
-
ID:a8E5ihho0が立てたスレだからしかたがない。
現在も2chで恥さらし中
-
死んでもないのに葬式あげてひとしきり泣いたフリして、速攻財産分与の話し合い始めてる下衆にしか見えない
-
>>14
まだそっちのほうがマシだよ。残された遺族の将来に関わる問題でもあるから。
たとえるなら葬式に罵倒浴びせるばかりか遺族に次これをやれと強制してる様な非常識さがあるな。
周りは怒りを超えて笑いものにしてる。
-
>>14-15
樋口Mの開発終了＝「死」と例えるような、おセンチな意見は必要ありません
ここは次期MMD開発関連のスレッドです スレッドの趣旨に即したご意見を
お願いいたします
-
MMDの次は何なんだ→NNE
そんな安っぽいオチを見たかったのにｗ
-
作る人が自由に決めればいいと思うけど MikuMikuDance Neo なんてのもいいかも
MMDN
これこそ安易かｗ
-
スレッドの趣旨に即したご意見の苦言を言うと
>>2以降にちゃんねるの煽りのレス貼られた以上
開発できる人がこないだろうと思う。
ここは仕切り直しで数日たってからまた立てたら良いと思う。
-
>>19
次期MMD開発にあまり関係のないレスですが、敢えて返答しますと
そういう無駄なことはしたくないですね 荒らす人はとことん荒らすし
立て直しは荒らしに屈することになります
開発する人が来る来ないは未来の話なので今考えるべきことでもありません
もし貴方が開発者でここに書くのがイヤなら貴方自身が立てればいいでしょう
もし、そちらがメインになるならそれでも構いません それは他の人に対しても
同じです ここは次期MMD開発に意見のある人が自由に意見交換すること
を目的として立てました どうしても気に入らないというのであれば別スレッドを
他の人が立てることは全然構わないと思います
引き続きスレッドの趣旨に即したご意見をお願いいたします
-
最悪を想定したスレですね、活用されないことを祈ります
-
>>16
おまえにはそれを仕切る能力も資格も無いつってるだけだわ いい加減気づけ池沼
-
>>20
にちゃねるのMMDスレで故意に荒らした人が>>1でないなら解る話だ。
残念ながらここにいるのはそうは思ってないようだ。
かわいそうだが他人のフリしてスレを上げ直すしかないよ。
-
妄想スレ的に書きますが。
・拡張性を確保した設計が望ましい
・pmmにはこだわらず、PMD・PMX・VMDだけ互換性あれば
・初音ミクを躍らせるソフトにこだわらなくていいんだからむしろドラマ向けに・・Crystel Engineみたいな
シナリオをならべられるみたいな形もありじゃないかと。
MMDと操作性も完全互換みたいなものをつくりにいくのは心情的にも反発される可能性も感じますし、
ソースも公開されてるVMDMixerをベースに発展させていくほうが結果が出るような気がします。
-
次期版はMMD（夏）とかMMD（ハクリエル）とかになるんですね
でないとタグとかイベント名とか色々影響が大きい
標準のモデルやステージはどうなるんだろう…
いっそ標準モデルを選定し直してみては？
-
標準モデルのキャラはともかく仕様は見直したほうがいいかもね
特にボーンの構成について、今のはシンプルでいいかもしれないけど、
足がバタバタするのと肩周りについては直したほうがいいと思う
-
うーん・・・思った通り要望スレになってる
ここのスレでは技術的な面を話し合ってまたそれとは別に要望等を話し合う場を分けた方がいいのでは？
的を絞らないと話しがグダグタになるような・・・
と言うかいささかこの話題時期尚早のような気もするんだけど
後任は誰がやる？誰がやる？なんて捲くし立ててもそうそう出てくるものじゃないしね
-
荒らしが建てたスレでまともな意見交換できる訳ないしな
-
とりあえず本スレ未だに書き込めないんでここに書くわ。
樋口M、今まで有難うございました。
お疲れ様。
また別の形でも戻ってこられるのをお待ちしております。
-
ほんとに次期・・・を考える場合は
モデル添付とかのパッケージングにあたるものの話題は避けたほうが無難だと思います。
表面的なユーザインタフェースもかな。なんせ好みが出るので、決める人がいないと頓挫する。
拡張性と下位互換性を確保したプロジェクトファイルの仕様を決めて、
PMD、PMX、xファイル、VMD、fxファイル、wavファイル、AVIファイルなどなどを読み込んで
リアルタイム再生、AVIファイル出力する基盤を確立すること。ここが最初の目標になるんじゃないかな。
MMDの場合は、wavファイルは躍らせる伴奏用、aviファイルはトレースの参照用って位置づけでしかなかった
ようにしか見えませんし、そのため複数読み込むことは、最初から考えてない設計だったんじゃないかなと
思っています。
ここで設計的に分かりやすく、ハードウェアのリソース消費状況やエラーをトレースしやすいかたちを
再設計できれば次につながる資産になる。
-
オープンソースに、という声もあるが、その場合、添付モデルのライセンスは?
プログラム同様、改造・再配布自由?
だとしたら、ミクとかのモデルはまず無理
オリジナルだとしても、どんな改造をしても構いませんん、ってのはモデル作者的にどうなんだろう?
それとも、モデルは添付しない or 別ライセンス?
-
添付しない、が無難。
基盤となる再生エンジンつくってその部分をオーブンにして、
MMD同様にパッケージへの添付はその人の責任でご自由にという形かなと。
-
実際に作れもしない人が
ぼくのかんがえたあたらしいえむえむでぃー
の妄想を垂れ流すのはここですか
-
はい、ここです
-
とりあえずこれから互換ソフトを開発する気がある人間がいるとしたら
ブレンダーという統合3Dソフトののソースも見ておくといろいろ参考に
なるんじゃないカナ。
-
とりあえず要望は「開発が決定して、どのように作って行くかのおおまかな流れ」が出来上がった後に必要性が高まる意見だから、
今の段階で次から次に要望がここに書き込まれることは、オープンソースとしての開発を始めるまでの流れを阻害こそすれ、
プラスに働くことはないと思うんだが
今後開発されるものへの何らかの機能実装を望む意見は、要望スレがまだ残ってるんだからそちらを利用して、
こちらに書き込まれる要望は「ソースなり開発する際に、何らかの機能を実装するために必要性が高そうな機能」を、
開発者側の視点から書く流れにしておかないとそっこーｇｄｇｄになりそうな感じがするんだが
ていうかソースはC#で決定なの？
-
ところで python でも MMD みたいなのつくれるの？
-
>>37
> ところで python でも MMD みたいなのつくれるの？
「MMDみたいなの」の範囲が分からないけれども
PMDモデルをVMDデータで踊らせることなら
MMD for XNA と IronPython の組み合わせで
現状でも可能
http://www.panda3d.org/
みたいな3DCGライブラリ使えば
「MMDみたいな3DCGツール」
も作れるけれども
まあ普通、Python みたいなスクリプト言語は
母体となる3DCGアプリ自体を作るためにより
その上で動くユーザースクリプト動かすために
使うよね
-
>>36
言語と、ライブラリの選択がまず最初の課題かな。
C#かC++以外の選択肢はないと思うけど。
-
まあ、最有力候補はC++だよな・・・
-
いやいや、まずは現状のMMDの仕様洗い出しが先だろ
-
仕様、というのが操作方法とかの話であれば、ハッキリ言って今は考えないほうがいいです。
モデル・モーションのデータ互換・・・再生した動画の見た目がMMDと区別つかない形で、
安定して使えれば操作性が違っても何とかなると思います。
pmm互換は諦めていいんじゃないかな。
むしろpmmにあたるものは今後の機能拡張も見越して一から考えるほうが開発が楽。
プロジェクトファイルそのものの項目にレイアウトのバージョン持たせておくとか、
追加項目は旧バージョンでは無視するってこともできるだろうし。
-
で、ソフトはどういう方向性で行くかを色々書いてるけど、
それを個人の開発者に押し付ける気なの？
ゲーム作りたいけど何もできないから企画やる！とか言ってるやつと一緒だわ。
-
とは言ってもそうするしかないってのが現状じゃね？
だれも引き継ぐって表明しないしな。居ても2ｃｈで名前もわからん奴だし
オレも一応、昔作ったゲームプログラミングを元にPMXを読み込むソフトに挑戦してるが
正直飽きずに完成させる自信はない
-
作れる能力と責任のある奴が「カンパ後開発・成果物共有」方式でやるしかないんじゃないかな
OSS界隈でも「これこれの機能開発するのにこれぐらいのコストと月日がかかるけど、
金だしても欲しい人いる？」と計画提案してまずはカンパしてもらい、
一定の総額に達したら開発開始、OSSで公開するって方式がある
まあ、日本文化にはなじまない気はするが
-
個人名出すのはなんだけど、ウィルフレムPさんを手伝ってライブラリ確立するってのが
前に進むために近い方法の一つかな。協力者募集っていってるしソースも公開してるし
今もいろいろなんかやってる。
-
微妙に長文になってしまって申し訳ないです。
昔モデルデータスレに居た人間からすると
・MMD本体部分(英名、物理、自影拡張以前の基本機能)の作成は、DirectX(GLでもいいけど)を弄ったことがある人なら可能だと思う
（要は、現在フレームの各ボーンの位置と回転をローカル*ワールド行列に仕込んで、あとはカメラと照明も似た感じに処理するだけなので）
・難しいのは、旧バージョンと動作を完全に一致させる部分
（IKはBlenderより1個分チェーンが短かいとか、その他諸々、Mが書いた計算式をどこまで推測できるか次第）
・物理はBulletをちゃんと見た事が無いのでなんとも言えないけど、実装する気になった時に調べればいいので
・セルフシャドウは、昔、変な影(板)が出てたあたりから推測すれば行けるはず
なので、やる気になれば、書く人も出てくるでしょう。
互換品を作る方向にモチベーションが向くか、右上に行くかは別としてｗ
あと、言語はUI側はC#でもいいけど、本体はC++で書いた方が無難だと思う。
MMDは操作結果の高速表示にこだわったソフトなので、
C#とC++の間のデータ移動(DirectXに渡すため)が結構ネックになるかもしれないので。
(というより、SlimDXがらみで変なバグに嵌まりたくないというのが本音)
>>42
pmmは、双方向リンクっぽい部分に、なぜかインデックスが3個あったりするので、
完全には解析しにくいんですよね。
pmm読込みは、機能的には、欲しいところですが・・
あと、PMDとPMXの両対応なら、Shift-JISとUnicodeの混在とか、C++で書くなら可変長のデータをどうするかとか。
混在環境(Blenderのプラグインとか。あれはASCIIも混ざってる)で書いた時は、デバッグが大変でｗｗ
>>35
Blenderのソースを見るのは、ちょっと・・(見るのは面白いですが。)
あれは、ドキュメントも含めて、未整理な部分が大量にあるので、
コンパイルを通すだけでも一苦労したり、予備知識(設計がどうなっているか)が必要だったり。
あとBlenderはOpenGLを使っているので、多少、実装方法が異なります。
おそらく、MMDの実装を想像しながら書いた方が早いです。
>>37
どんな言語でも、(DirectXの機能を呼べる言語であれば)作れるといえば作れます。
とは言っても、向き、不向きはあるわけで。
極端なことを言ってしまうと、
Pythonとかスクリプト系の言語は、「まとまった処理」が得意、
Cとかは、「単純化できる処理」が得意なのです。
MMDは、後者の、単純化できる方なので、Cの方が有利です。
(単純化：頂点1個ずつの処理が、例えば足し算とか掛け算の繰り返しになるとか。
実際の所、行列演算なので、そんな感じですがｗ)
-
>>47
手堅い開発方法から言えば、まずは正しく動くものをつくって、そこから高速化を図る、でしょうし
>・難しいのは、旧バージョンと動作を完全に一致させる部分
>（IKはBlenderより1個分チェーンが短かいとか、その他諸々、Mが書いた計算式をどこまで推測できるか次第）
ここでしょうね。
-
にゃぽのとある人の日記のコメントでひぐちMは
内容を秘密にする気がないのでリバースエンジニアリング等しても良いと言う発言をしていた。
まず出所の日記の人に公開していいか聞いてみる。
プログラムの解析は不可能ではないがゲームのチートするより大変だと聞いたがどうなんだろう。
-
逆コンパイルしたら負けかなって思ってる
ってのは冗談で、実際やったことないが
C言語の復元は難しいらしいって聞いたことがある。出来ても見難いソースに復元されるらしい
C＃なら復元しやすいらしいが・・・
-
MMDクラスのソフトで本気でコスト計算したら
とんでもない金額になる気がするんだが・・・と底辺PGが言ってみる
-
とりあえずこれがリリースされたらデバッグの手伝いはしようかなと思います。
ttp://wilfrem.blog116.fc2.com/blog-entry-105.html#comment152
MMDX ver2
よーやく仕上がってきました。
間に就職とか引越しとか入って当初予定からだいぶ遅くなってますが(^^;)
とりあえず、もうすぐリリースできそうです。
なお、XNA4.0対応の他にSlimDX(DirectX9)にも対応させる予定です。
それでは。
-
>>48
Mも、PMX対応で他ソフトと動作を一致させるのに苦労していましたね。
>>49 >>50
高級言語(Cなど)まで戻すとしたら大変、
アセンブラまでなら、ただの変換。
というのは置いておいて・・
C#は、クラスブラウザなどで見れば関数名、変数名がわかるので、比較的楽。
(外から呼べるものは、呼んでしまえばいいし・・)
C/C++は、(デバッグ時に逆アセンブラ画面を見るのと同じで)
可読要素が少ないので解析が面倒なのです。
(どの部分が、どの関数だか想像しながら読まないといけないので)
チートについては略ｗ
>>51
計算しちゃだめですｗ
あ、でも、コスト計算だと、1人でやってるから低め・・
-
初代バージョンを70時間で作ったらしいが信じられない。
天才すぎる。
-
次のが在るならボーンの角度を調整するだけでなく子のボーンを移動することにより親ボーンの角度を調整できるように
して欲しいです。それならボーズをつけるのもかなり楽になるはず。
-
>>56
IKでもなく、回転連動でもない、それ以外の何かを求めているのかな
調整って言うだけでは何をしたいのかわからないんじゃないか
-
PMXの解説生でやってたIKっぽく使えるアレとは違うのかな
-
ああ、そうか、腕IKってそのためにあったのかぁ。そうそれです。ごめんちゃい
-
えっとね。やっぱり出来なかった。言いたかったのは、普通ボーンを回転させてボーンの位置を角度を決定するんだと
思うんだけど。子のボーンを移動させることにより動かしたいボーンの角度を決定させる。要は根元を回転じゃなくて
先を移動させることにより位置を決める。例を出せば腕の根元を回転させるより、肘の位置を移動させた方が
より直線的にポーズを付けやすいのではないかと考えたわけです。
-
そんな感じのやつPMXモデルの説明生でやってたけど作り方がわからないｗ
-
>>60
いや、それが腕IKなわけで・・・
足にはIKボーンがあるだろ？ 移動させると連動して足が動くやつ
だが制限なしでははっきりいって使い物にならないわけ。PMDだと足にしかその制限がない
PMXだと各ボーンに制限が付けれる。つまり腕にもIKが付けれるってことだ
-
一応PMDにも昔から腕IKモデルあるけど
特別だった足とは違って何か問題があるんだろうとは思っても
あまりおかしいところはわかんないな
-
それは作り手が苦労して調整してるんだよ
制限なしでは腕としてはありえない方向に曲がる可能性が出てくる
-
>>62
いや、そう難しく考えなくても、肘の位置を決める方法を根元から先に変えるだけの話で。
腕IKだと捻りまで加えるとどこに行くかわかんなくなるし。
-
>>65
言いたいことがようやくわかった気がする
それってXYZにどの角度で割り当てるか決まらないという問題が出てくるんじゃないかな
IKと同じ仕組みにするのかな
うまく実装できるなら良さそうな気もするけど
-
だからIKじゃない先を持って動かせるボーンを
PMXの説明生でやってたってば…
-
その「PMXの説明生」というのはどこにあるのだ
-
>>66
いやぁ、説明へたでごめん。技術的にはまったく分からないのでこのスレには合わないかも。
ただモデル作りの様な操作方法のほうがやりやすいとヘッポコモデラーが思っただけなので。
-
>>68
MikuMikuDanceコミュニティで5/14にかんなさんがやってたけど
タイムシフト再生はもう終わってるので見れぬ
-
こういうのじゃないのかな？
ttp://gyazo.com/f17ed3b43152bce64bee8ed3dde192f1.png
これはででさんが作ったモデルなので、かんなさんが説明してたものと
同じかどうか分からないんだけど。
腕ボーン自体をIK化するんじゃなくて、外側にIKボーンを追加して二人羽織
みたいにできるやつ。
-
子ボーンの種類を、回転ボーンから移動ボーンに変えるだけでよいのでは？
と思ったりして・・・
(子ボーンは親ボーンの先の位置を決めるだけの存在なので。)
IKだと親ボーンの長さでは届かない位置にも移動できるので、
うまく動かないように見えるのかも。
あと、問題が起きるとしたら、親子関係にあるボーンが複数ある場合。
(PMDの「子ボーン(≒親の先の位置決め用)」ではなく、「手首の子≒指ボーン」的な意味で。)
制御側が複数ある場合は、一意な移動ロジックが組めないと思います。
(例えば、人差し指と中指を同時に別方向に動かしたら、手首をどう移動する？？ ということ)
-
もう、いっその事、ニコ動とかで祭りと称して技術者集めてみては？
…なんてやっぱり安直すぎるかなぁ。
-
MMD知らない人からも開発者を募ろう、という提案？
-
人が多ければそれだけチカラが増えるし
今の状態を知れば「俺がやったる」て人も出るだろうし
もちろん人が増える事でトラブルも増えるだろうけど
むしろMMDを知らない事で新たな道も開けるんじゃないかなと…。
駄目ですかねぇ。
-
>>75
今の理想型はアプリケーション開発の基盤とかライブラリが出来て、
その上で作りたい人が思い思いに作るって形かなあ。
せかすつもりはありませんが>>52の動きを静かに注目しています。
過去に実績あることを考えるとここが本命と思っています。
-
一応オレも作ってるぜ
今はまだPMX読み込んで表示させるくらいだがな・・・
-
>>78だけど、トゥーン処理で躓いたわ
よくわからんけど影になる部分の一部が斑点のような模様になる(´･ω･`)
-
>>79
法線が急に変化する場所で補間するとか・・
-
ああ、一応原因が特定できた
内積1.0ｆ、トゥーンテクスチャの端がどうも上手く所得できてないっぽいわ・・・
-
>>81
セルフ影の色で、また出てきそうな･･
-
>>81
トゥーンテクスチャのサンプラーの設定がClampになってないのでは、とエスパー
全然違ったらスマン
-
>>83
的確な指摘でした。ありがとうございます
単純なミスで泣いたけど、解決できてスッキリ
今こんな感じ・・・(´･ω･`)
ttp://www1.axfc.net/uploader/Img/so/118774.png
-
おぉ、ちょっとAE風な感じでカッコイイじゃまいか
なんでカメラが沢山あるのか分からんがｗ
そしてエスパーも乙ｗ
-
もしかしてこれは補間キーフレームAEみたく連続で弄れるのだろうかそうならマジ楽しみ
-
ゆるアマクリエイターの日記 MMDX2.0リリースしました。
ttp://wilfrem.blog116.fc2.com/blog-entry-106.html
readme一部引用。
------------------------
MMDX version 2 alpha readme
はじめに
MMDXをダウンロードしていただきありがとうございます。
MMDXとは樋口M氏が作成されたMikuMikuDance(以下MMD)を元にしたアニメーションライブラリです。
MMDのモデル・モーション・アクセサリをWindows(XNA or SlimDX)/XBox360(XNA)で再生することができます。
このライブラリの対象と目的
このライブラリは
MMDを「アニメーション作成ツール」として活用し
それを各種ゲームやツールで再生するための
MMDのC#実装系となります。
そのため
「MMDを活用したゲーム/ツールを作りたい！」
という人向けとなっております。
：
：
：
注意事項
・C#実装なんで本家(C++)と比べて重たいです。
・凝りまくったモデルつっこむと重たくて死にます。
・(ゲーム用途としては使いにくい重たいモデルがMMD界隈には多いです。もっと軽くして〜＞＜)
・私としてはどちらかと言えばゲーム/ゲーム用ツール向けとして作ってるので、使いにくいところがあるかも。
・バグが恐らくあります。人柱募集
・Windows Phone 7は非対応です(持ってないです＞＜)
------------------------
-
>>87
右のサイドバーからSourceForgeへ飛べ、とあるからしばらく探してしまった 左に置いてあるのなｗ
｢軽いモデル｣ってどういう風に軽くしたらいいんだろ
-
MMDXまわりがなんか面白くなってきました。
ゆるアマクリエイターの日記 Nico Visual EffectsのMMDプラグインを作ってみた
http://wilfrem.blog116.fc2.com/blog-entry-107.html
>MMDXのスペシャル・サンプルとして
>NiVEでpmdファイルが読めるプラグイン作ってみました。
-
どうもこんにちは〜。こんな板があったのか。
>>88
軽いモデルがほしい理由は
1.本家MMD(C++)と違って実装が純粋C#なので、どうしても遅い。
2.MMD以外の用途に使用する場合、「モデルを描画する処理」だけで手一杯だと他のことやるのが厳しい
3.MMDはデフォルト30FPSだけど、ゲームは基本60FPS(よりシビア)
実際、MMDつかって3D東方作ってる方いらっしゃるけど
MMDモデルそのままだと、やっぱ処理落ちするみたい。
どう軽くすればいいかは次レスで書くわ。
連レスいきなり失礼します〜
-
>>88
重たい処理ランキング(MMDXの場合。DXLibとか本家MMDだと違うとおもう)
1.物理(剛体/ジョイント)
物理は重い。CPUにメチャ負荷かかる。
別スレッド立ててマルチコアCPU利用しても、物理スレッドがフレーム落ちすることがある
（その場合、なんかふわっとした感じの動きになるはず)
出来れば全部モーションだけで抑えたい。
2.base表情の頂点数/表情数
モーフィングは重た目の処理。CPUに負荷(箱はGPUに負荷)
MMDXは実は超セコイことして、なんとか速度出してるｗ
3.ボーン数&頂点数
ボーンとスキニング計算。ボーンはCPU、スキニングはGPU
base表情程じゃないけど、結構重たい
4.パーツ数やテクスチャ数
少ない方が早い。
綺麗なローポリが充実してると
MMD上でも複数モデル出すときに、軽くなると思うから
皆のためになると思うんだけど、どうかな？
-
逆に複数CPUコア、超豪快なメモリー空間を潤沢に使いまくれるバージョンも欲しいかも知れない・・。
-
MMDerはわりとマッチョだからなｗ
まあでも軽いモデルがより充実する方向性も有って良いと思う
-
>>92
そこはモデル作者に頑張って欲しいなぁと
フルverとコンパクトverという感じで。
ディテールにこだわるときはフルverで
モブとして出すときはコンパクトverという使い分けとか。
-
軽いモデルの線引きってどこぐらい？
モブ子さん？
-
>>95
線引きはできないと思う。
理由として目的とターゲットマシンと時代によって変わる
例えば、携帯目指すなら今のままだとどうにもならないし、
箱はGPU>>>>>CPUだから、それに合わせて基準が変化する。
ただ、こっちが重たいモデルテスト用として使ってたのは
レア様とか魂魄妖夢(ボーン255超え)とかだから
俺の独断と偏見によると、その辺が重たいモデル。
MMD付属のミクを中ぐらい〜少し軽い方って考えてる。
-
モブ子さんも見てみた。
剛体数とボーン数が多いのが気になるけど
物理切れば軽そうだなー。
-
そっかー要するに標準ミクさんより軽ければいいのか。
覚えておこう。
-
個人的に軽いと思ってるのはさぼてんさんのモデル群かな
初代ミクはギミック多すぎで重そうだけど
-
物理を使わずモーションだけで、となると
物理で生み出される動きを
モーションとして記録する何かが必要？
さすがに今まで物理でやって来たことを、
急に手作業で、と言うのも酷な話だろうし
-
MMDでディティール確保しようとすると、メカ物なんかはどうしても頂点数増える方向になっちゃうな。
ノーマルマップにディティール落とし込んだモデルも作ってみたけど他のMMEと両立出来なかったりして使いづらかった。
-
ゲームのモデルでも対戦格闘と無双系ではディテールレベルがかなり違うだろうし
MMDモデルのディテールは対戦格闘寄り
-
ttp://www1.axfc.net/uploader/Sc/so/252148
まだほとんど実装ないが、ここまでで、みんなの環境で動くかどうか知りたい。
中にx86版の無印と、x64版がある。
pmdを読めるようにしておいたが、ドロップは未実装なので、「ファイル→モデル読込」で。
Lat式ミクVer2.3は読めた。
-
むしろ動かないかもしれない懸念がどこかにあるの？
-
Os Win７ 64bit
重いモデルといわれるレア、マリエルですが両版とも表示されます
マウスの動きが感覚と逆なので違和感あります
-
DirectX使ったアプリ配布してみたの初めてなもので。。あとx64版も初めて作ったので。。
-
オレの自作モデルも問題なく読み込めたな
64bitOSじゃないんでそっちの方は確かめれなかったが
今の所、次期MMDツールは三種類か
-
>>103
o CRTが/MDだとmsvcr90.dll等がインストールされていない環境で動かないかもしれない
o DirectXランタイムが古い環境だと動かないかもしれない
pmdは色々読み込ませてみたけど安定してると思うよ〜
-
>>108
的確な指示ありがとう。/MTに直しとく。
あと、ごめん。モデルデータ読み込んで終了すると、モデルデータと同じディレクトリに 〜.posinfo
ってゴミが出る(´・ω・｀)
消してください。。
|
|
掲示板管理者へ連絡
無料レンタル掲示板
