【MMD】紳士動画製作者のダベり場22

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
■ＭＭＤでえっちな動画を作ってる人専用の『だべり場』です

動画制作者のレベルは超初心者から上級者までさまざまです
互いの「作品」「モデル」「テーマ」「フェチ」を尊重し、建設的で楽しいスレにしましょう

“建設的”というのは、
動画のダメなところを指摘し叩くことではなく、キラリとひかるものを賞賛、分析、考察、公式化して、皆の技術水準が向上するように努めることです
『見る専』のいう“評論（投稿者叩き・作品叩き・モデル叩き）”とは、その本質がまったく異なります

互いの技術向上の為の「動画交換」「オリジナルモデルの交換」は大いに結構です
盛り上げていきましょう

また、次スレは>>980を踏んだ人が宣言をして建てること
(流れが早い時は>>950)
・メル欄に[ ageteoff ]を忘れずに
・ワッチョイは１行目に
!extend:checked:vvvvv:1000:512


■前スレ
【MMD】紳士動画製作者のダベり場21
https://egg.5ch.net/test/read.cgi/streaming/1565114438/
【MMD】紳士動画製作者のダベり場20（27レスdat落ち）
https://egg.5ch.net/test/read.cgi/streaming/1564830850/


■紳士MMD製作者お役立ちリンク（随時追加）
MMD紳士動画製作wiki
http://seesaawiki.jp/gentle/
MMDArchive(利用規約的にグレーなものモデルもあるので自己責任で)
http://mmda.booru.org/index.php

---

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

>>515
たちが悪いのはジョイントが剛体に付いてなくても
直前に読み込んでたモデルとMMDが誤認してると
一応動いたりすんだよね
新規で読み込もうとすると100％落ちるけど
モデル修正しながら再読込を繰り返してると
何処で間違えたのか解りにくい

>>516
要らないと思ったけど必要だったボーンを消したらなったわ
メモリ上の領域確保されたままなのか直してる間（再読み込みで対処してる間）は問題ないんだよね
MMDごと起動し直すとエラーで落ちて前バージョンのモデル読んでから呼び出すと動いたり

何を変えたかわからないので答えようがない
HDDが死にかけてるとかもありえる

>>517
MMDで再読み込み出来るのはテクスチャだけ
モデル自体の再読み込み機能はない

モデル情報の使いまわしっぽい現象が起きてるなら、初期化漏れのバグの挙動っぽいな

>>514
いつも使ってるモデルでいろんなシチュで保存してるんだがたまに開けなくなるやつがあるんだよな。

自分もモデルの衣服に透明モーフ追加したらｐｍｍが読み込めずにMMDが落ちるようになってしまった。
で、今しがた509のやりかたを試してみたら上手く読み込めた！
ありがとう！

隠しモーフ表示枠残存とエラージョイントはずっと前から既知のクラッシュだけどとうとう修正されなかったな

>>523
エラーがあって落ちるのが当然だし「エラーがある」ってわかるから助かると思うけど。
エラーがあるモデルを読み込んでも落とさないなんて、実現しようがないと思うし。
極端な話「ジョイントはひとつもありません。それでも踊れます」ってことだよ？

>>524
エラーダイアログ出ずにクラッシュしちゃうって話よ

多少重くなってもいいからVAMみたいな感じに動かんかなぁ

もうエロいモデルはbodyをIZUMIで統一してほしいわ
バランスが一番いいわ

IZUMIはバランスよくてエロい。
だが、足が長いTDA系列もとてもエロい。
だがしかし、胴長短足なモデルも妙にリアリティあってエロい。
だがだがしかし、腹筋を表現してる（ｋｓ式とか）のモデルも筋肉エロい。

要は中身があればなんでもエロいんだ。

izumiはウエイトが抜群にいいから弄りやすいな

流れを読まずに表面吸着プラグイン更新
dotup.org/uploda/dotup.org2033236.zip.html
・ウェイト吸着できないバグ修正
・従来の面への吸着だけでなく、辺/頂点への吸着モードを追加
頂点吸着モードは専用プラグインの約３倍重い＆メモリ喰うので、他のオプションとあわせて使わないとメリットが少ない点に注意
形状維持＋頂点吸着とか、吸着位置から離す＋頂点吸着等が需要ありそうな気がする

尻が破綻しないモデルがいいな…。

カッパさんのモデルですね>破綻しない
ただ、貧弱なんだよな

>>530
使ってみたいんだけど起動時にエラーが出てdll読み込めない。
きっとおま環なんだろうからあきらめるけど。

>>533
どんなエラー？zipファイル(or dll)のプロパティからセキュリティの解除はしてある？

他に、ソース(zip中のsource\*.cx)から実行する方法もある
PMXEのメニュー [編集]-[プラグイン]-[CSScript]-[C#スクリプト]で開く → [ファイル]-[スクリプト読み込み]でcxファイル選択 → 実行ボタン
試してみてくれ

https://gyazo.com/747b4d718df03f9866b18731e6374af7

PMXエディタでこういう変形ってできます？いっつも下の図みたいになってしまう

こんな感じに、っていうのがよく分からない
ちょっと面倒だが、とりあえず[動]ウィンドウのローカル軸タブあたりの設定をごにょごにょすれば上の図の意図通りの事はできるはず

ローカル軸自体は折り曲げ位置の頂点座標に２点適当なボーンつくって、片方の表示先をもう片方に設定、ローカル軸の自動設定して、XかZの値のどちらかをクリップボードにコピーすると取得できる
過去ログ掘っていけば選択した２頂点から単位ベクトルをコピーしてくれるスクリプトを貼ってくれてる人がいるから、それを使うのもいい

ボーン入れてTFVで曲げればいいのでは

ああ、ウェイト塗られてないならそっちが楽か

tdaは体が奇形だし華奢すぎる
あと胸やマンコが微妙

>>538
ウエイト塗られていてもオブジェクト操作の個別記憶でウェイトだけ復元できたりするからそれほど面倒ではないよ

手首持って後ろから突かれてるモーションどなたか教えてくだされぃ

tdaはモデル体型だから挿げ替えには向かない
でも一番勢いがあった(？)時期の海外勢がtda大好きだったから衣装バリエーションは圧倒的に多い

特に中華は服にこだわりあるねー
フワッとした衣装とか上手いね
で内容はハクが虫に犯されてるんだけどw

草

>>535
やりたいこと、どうしたいのかもっと詳しく正直わからん(°ω°=)

ただモデルの形を変えたいというならPMXエディタの
頂、面ボタンが押されてる状態で動かしたい所を
SHIFT押しながらマウス左クリックのまま選んで、
（要らない所はCTRL押しながらで消す）
これで支点の所を回転させればいいんじゃないかな
モーフとかで動かしたいなら頂点モーフで同じように変形後を作れば

>>539
服無しの体はほぼTDAのものでなくて他所のモデルのがくっつけられてるだけ
>>541
全親手首IK（or腕切IK）でポーズとって手首固定して
センター動かせばいいんじゃない？後はmmさんのcakefaceの
モーションの中にもあった気がするけど

>>540
あ、すまん、楽ってのは「手順がわかりやすい」って意味だった。説明と理解が楽、たぶん。
純粋な手数としてはどっちも大差ないと思うが、2頂点の単位ベクトル取得スクリプト(プラグイン)が用意できてたらボーン追加不要な分、手数も少ないと思ってる

とにかく敵の家を壊すゲームになるかなぁ・・・？資源無限は

ごめん誤爆

mmdって首とかを自然に動かすのがむずい気がする

頭IK作ると楽かも、想像してるのと違ったらごめん

人間の首は7つの骨が連動して動く（ていうかバラバラには動かせない）ので、首ボーンだけ、頭ボーンだけを動かすと基本的に不自然になる
頭ボーンの動きを首にも7:3くらいで分散させる（首側も同様にする）と多少マシになる
本格的にやるなら首ボーン７つ作って連動もアリ

おとがいのウェイト次第だけど
大半のモデルはポン付けというか差込み型だからね

前後(X軸方向)に傾ける→首はほとんど動かす頭側が大きく動く
左右(Z軸方向)に傾ける→首が大きく動く、頭はあんまり動かない
水平に回す(Y軸方向)→首も頭も同じくらいねじれる
標準的なボーンのままものすごく雑に分けようとすればこんな感じになる。自分の首に手を当てて動かしてみると分かるぞ(傷めないように)

動かす→動かず

どの動きについても
頭だけでキョロキョロすることも
首からグイングイン動かすことも出来ますが

曲線、加減速のバランスを調整しないと
補間曲線に頼った直線移動だけでは自然に首とかを動かすのは難しいだろうね

フィットした襟のあるモデルは頭だけ回すとまぬけに見えるから、元モーションに無くても首を少し回して襟も動くようにしてるわ
誰も気づかないだろうけどなw

チョーカーのように首に巻き付いて固定されてるのでない限り、襟が傾くことはあっても「回る（捩れる）」ことはないんじゃないかな

襟というかほとんどチョーカーみたいな首の周りだけある襟もどきのことを言いたかったorz

ビームマンPのキラキラZを下の方に向けて降らすことってできます？
コントローラーのX,Z軸移動で手前奥や左右には動くんですけど、雪や花びらみたいに降らないかなぁ・・・と

561です。桜吹雪エフェクトで代用しました。

足のブーツなんかを着せ替えるのは比較的簡単な方かと思いますが、
PMXEでモデルを読み込んで そのあと追加でブーツを読み込む…このときに同名ボーンのマージにチェックを入れると、
正直期待する動きは「マージしたボーンに沿ってブーツが変形、移動する」（例えばひざボーンが短かったら、ブーツが短くなる）なんですが、なんかそういうことは一切なく盛大にずれてますね。
https://gyazo.com/13f1bb887cddbb7ee2ac3cb726a0c1bd 簡単に位置合わせする方法ありますか？

解決したならいいけど、速度調節 0(上昇)〜1(停止)~2(下降) になるので2を設定すればよい
1より大きい数や0より小さい数は盲点になりがちだが、手入力で入れられる
ただし、MME作者(やモデル作者)は想定してない場合もある点には注意

>>564 ありがとうございます！

って、>>563は期待しすぎ
同名ボーンのマージは、ボーンの名前が同じものを重複させないってだけで、頂点まわりは変形させないのが期待の動作

ボーンに沿って移動拡大縮小するのトランスフォームビューで出来てることなので・・・ここでできなくてもどこかでできるはず・・・。プラグインにありませんか？

ざっくり言って「解が多すぎてひとつに絞れない」って点がネックで、例えばボーンの長短に関して、伸びているのか巨大化しているのか区別する方法があるだろうか？

プラグイン化するには制約条件(例:ボーンの回転は考慮しない、巨大化に絞る等)を加えれば希望はあるかもしれないが、
制約が緩いとプラグインは作れないし、制約が厳しすぎると用途が限られるのでプラグインを作る手間のぶんだけ損になる
たぶん普通に頂点を編集したほうが楽

確かにそのとおり・・・

俺なら大まかに位置合わせしたあと、はみ出た足を透過させちゃうな

あくまで我流だけど（°ω°=）
PMXエディタ2枚開いて素体にインポートした時にずれている
ブーツモデルの頂点のみ選んで手前側に移動させて再度インポート
これを繰り返して場所、大きさとか変えてる非常にシンプルだけど
着せ替えレベルはこの程度なんでお察しください↓
https://www.nicovideo.jp/watch/sm34638125

グロ

systemプラグイン「画像ボード追加」で参照したいPMXファイルを読み込めば済むので、わざわざPMXE２つ起動とか面倒なことしなくていいです

ryzen9 3900Xにしたら AVI書き出しで猛烈に早くなります？

そういう質問する時点で大体お察し。パーツ替えるならベンチマーク等で自環境のボトルネックを調べたほうが費用対効果でお得
CPUがネックになってるなら速くなるだろうし、HDD/SSDがネックなら速くならない。あるいはグラボがネックなのかもしれないが、とにかく質問に情報が足りなすぎる

コーデックのフレーム分割数を論理プロセッサ全部使えるのかなーって。 i9の16とかryzen9の24とか。

少なくとも現状を書かないとどうしようもない
並列化を期待してるならなおさらメモリやストレージの速度が重要になるが、そこまで細かい話になると同じ環境の人がいなくなる
自分で調べて納得するか、どうしても相談したいならそういう検証をしていそうなスレにお邪魔するかだが……

�@mmd→aviはシングルスレッド
�Aavi→mp4はマルチスレッド
多分�@は猛烈な変化はない
それどころかmmd自体ベースが古いので変な（固有の）不具合があるかもしれない

じゃあAVI出力のutvideoコーデックのフレーム分割数と論理スレッドって無意味です？

論理スレッドじゃないや、論理プロセッサ数と同じにする オプション

MMDはシングルだがエンコーダはマルチ
MMD側が必要なコマが供給できてないならエンコーダが爆速で動いても意味がないが、供給できてるなら恩恵がある
ただし、MMDがシングルで動いている以上、マルチコアの恩恵は制限されるという話。ボトルネックって概念を理解してくれ

もっと基礎知識つけて出直せってところか

グラボ変えれば早くなるって程単純な話じゃないし
いちいち基礎知識レベルの話を説明してたんじゃキリが無い

まあ早くなるかも知れないが猛烈には早くならない可能性が高いぐらいなら言えるが

ｍｍｄで一番恩恵あったハードはＳＳＤだったな
頻繁にデータ読み込みするし、ｎｖｍｅ導入したら編集の時の快適さが全然違う

基礎知識であろうと、それを書けば解決するってのならいちいち説明する事もやぶさかじゃない
とはいえ、現状の環境を提示できれば見込みくらいは言えるかも知れんけど、提示できないなら自己解決しか道がないんだ

最近までUtvideo知らずに生AVI吐いてたそこそこ有名なmmderがいるってこの前Twitterで見て驚いたわ
書き出しにすげー時間かかるだろ

cinebench みたいなMMDエンコードベンチみたいのもあって良さそうなものだけども。
この構成ならこの動画のAVI出力が5分！ こっちの構成なら7分！サンディとSSDなら50分とかな
「同じMMDデータをエンコードする」という部分が難しそう。

AviutlでCPUエンコからGPUエンコに変えたのと同じように、
3770k＋GTX1060+sataSSD+DDR3から3900X＋RTX2070super+ PCIe GEN4のSSD+DDR4でavi書き出しが3,4倍くらい早くなるととてもいいな。

>>585
たしかwikiにも書いてるレベルの話だけど
案外と古参程そういうモノを観ないで始めるのかもしれよね

>>583
m.2ならもっと速くなるかも

GPUエンコのノイズって気になる程出ますか？

>>585,587
質問させてください
「生AVI吐いてた」というのは、「未圧縮」での出力という意味でしょうか？
普段、MMDから「未圧縮」で出力 ⇒ AviUtlで「プラグイン出力」「拡張x264出力(GUI)Ex」でMP4に変換してるんですが
こういう手順を踏む場合にコーデックを入れて良いのかよくわからず、未圧縮で出力していました
FullHD以上の画質でつべやニコ動に投稿したい場合、MMDから「UtVideo RGB DMO」等で出力し、
そのAVIファイルをAviUtlの「プラグイン出力」「拡張x264出力(GUI)Ex」でMP4する、という方が画質劣化無く短時間で処理できるのでしょうか？

ZIPやRARなどの圧縮ファイルの中身が劣化するかい？
UT-Videoも同じこと

画質劣化気にするならそりゃ生avi出力が一番劣化しないだろ
俺はUTで422の奴使ってる

生=未圧縮
UtVideoのRGBなら可逆圧縮だから未圧縮と同じ画質でファイルサイズが小さくなる
出力も速い

どうせmp4にするならYUV420で出力してさらにファイルサイズ小さくしてもいいと思う

>>591-593
ありがとうございます
一通り試してみます

どうせニコ動で再エンコされるしな

UT-VideoのYUV420やYUV422は精細情報（明暗）は無劣化だけど色情報は間引きされてるよ。

ttps://www.ite.or.jp/contents/keywords/FILE-20120103130828.pdf

「人間の視覚特性には，例えば暗闇では物の形は認識できても色については
認識しにくいといったように，輝度に対する感度に比べて色に対する感度が
低いという性質があ」るという特性を利用している

もっともニコ動にせよYou Tubeにせよ再エンコで色情報は最終的にyuv420相当になるので
最初からMMDからYUV420でAVI出力してる。
そのほうが軽いし、MP4にエンコする時間も短くて済む

>>595-596
つべやニコ動にもアップしてるけど、自分で観賞するときはローカルのファイルで見るので、
できるだけ劣化は抑えられる方が良いなと思ってます

ひとまずMMDからUtVideo RGB DMOでの出力を試してみましたが、
俺の環境だと未圧縮での出力からあまり時間が短縮された気がしなかったです
3000フレーム程度の動画で、時間を実測したわけではなくあくまで体感でしたが…
もっと長い動画とか、モデルの人数が多いものになったら差が顕著になるのかな？
とりあえずしばらくは引き続きUtVideo RGB DMOでの出力でやってみるようにします

MMDからのavi出力に要する時間でボトルネックになるのはほとんどレンダリング。
無圧縮またはUtvideo による可逆圧縮の種類の差とかHDDに書き込む時間とかの影響はほとんどない。
ためしにaviの出力先を外付けSSDにしてみたが、全然かわらなかった。

YUV420とRGB DMOで差が出るのはAVIからMP4に変換するときのエンコードに要する時間。

自分用に少しでも画質の良い動画を残したいなら、RGB DMOでavi出力してH265でエンコード。

>>598
ありがとうございます
H265、使ったことなかったので試してみます

>>598
レンダリング速度はエフェクトの量にもよるから、その辺を無視して一般化するのはどうなんだろう
エフェクト量をグラボ相応に抑えている人ならエンコード圧縮率向上の恩恵はあるよ

そのh264/h265変換こそマルチコアのパワーを発揮するところだよね
まー4kでないとそんなにストレス感じないけど

AVI 出力に関しては GPU の VRAM は最低でも 4GB ほしいところ。
モデルをたくさん読んだりして、これが足りていないとめっちゃ遅くなるよ。

低速なドライブ使ってると書き込み速度もボルトネックなるよ

自分の環境の場合無圧縮だと5400rpmのHDDでタスクマネージャのアクティブな時間がほぼ100に張り付いて遅くなる
出力先SSDにしたりHDDでもUt使うと余裕できてコーディックによる差もなくなる

現状余裕あるなら気にしなくていいけどね

ボトルネックねｗ

俺もつい最近までそのまま（生）AVI出力していた
これがハードディスクに負担かけてたと思う
俺もUtVideoのビデオ圧縮コーデック使うのは
処理の負担抑えるのにいいと思う（CPUの負担は増えるけど）
俺は（たしか）案内の説明で選んだと思うが一番上の
Utvideo YUV420 BT.709DMOっての使ってる
俺のPCはOSがWin10の日記作業のワードエクセル使う位のノートPCなので
エンコードはH.265とかCPUの負担大きそうなのは使えなくて
H.264を使ってる。ここらへんは動画投稿サイトに合った
画面サイズ、エンコードを選んで、もう一度エンコードされて
画質が落ちないようにすればいいんじゃないかな？
MMEは（普段使ってないｗ）ray-mmd-1.3.1v2　Ray（マテリアル特に設定無し）
1280x720　60fpsでAVI出力つんでれんこのエンコード2時間位
https://www.nicovideo.jp/watch/sm36036901

こんな感じで作ってますあくまで俺の場合だけど(°ω°=)ｻﾝｺｳﾅﾚﾊﾞ

生AVI→XMedia Recode
これで事足りてる、コーデックは何も入れてない
Win10そのものがアップデートでコーデック対応してるし
エンコードっても3分くらいの動画なら10分もかからない
720Pの30FPSだけど

>>573
ども、お陰で作業の負担減りそうだわ(°ω°=)ｻﾝｷｭｰﾐｽﾀｰﾎﾟﾎﾟ
そうかーまだまだPMXエディタの使い方知らない機能多いな
いやMMDもだけどｗ

>>600
レンダリング速度はエフェクトの量にもよるから、その辺を無視して一般化するのはどうなんだろう＞
たしかにそれはありますね。

じぶんはRAY-MMDを使って2560ｘ1440ｐ60fpsや3840x2160p60fpsとかの動画ばかりなので
レンダリング時間とエンコード時間の長さが現状での目の上のタンコブ状態なもんですから

>>601
それよりGPUに任せた方が速いぞ

>>609
ハードウェアエンコードって画質落ちませんか？
自分が前やったときはソフトウェアエンコードにくらべ明らかに劣化を感じたんですが。
長さ10分とかの動画を毎日投稿とかだったら背に腹は替えられないですが,
MMD動画は長くてもせいぜい4，5分ですし投稿も週イチとか10日に1辺ですし

テストしたハードウェアエンコードソフト
ttps://www.gigafree.net/media/conv/As-Video-Converter.html

Adobe Premiereあたり使って比較するといいかも

動画投稿サイト用ならNVencでいいだろ。
fantiaとかでより高画質なのを支援者にっていうのなら、ソフトウェアのマルチパスエンコードにすればいい。

ファイル書き込み処理そのものはPCの処理としては圧倒的に遅い
MMDでの出力の場合は膨大な物理演算や重いMMEがボトルネックになってる場合もあるからそういう場合はUtVideo使って圧縮しても効果は無いんだが
それでもその動画編集したりエンコードするならファイルサイズが馬鹿でかければ読み込みで時間がかかる分確実に遅くなるんで未圧縮使うのはデメリットにしかならない
単純にディスク容量食うしコピーしたりバックアップしたりするんでも時間かかるし

敢えて無劣化圧縮のデメリットあげればインストールしないと使えないのと使用時にコーディック選ぶ分手間がかかるぐらい

前にAviutlのH264、H265、NVEncのプラグインでエンコードして比べてみたけど
エフェクトray-mmdのみだと見た目的には大した違いは無かったように感じた

自ツイッターで悪いけどその時の軽い検証した動画と結果
ttps://twitter.com/inwerwm/status/1160514003983982592
https://twitter.com/5chan_nel (5ch newer account)

動画の画質は未圧縮状態からの劣化の度合いだから比較すれば数値で出せるけど
ビットレートが十分あれば見た目での違いは出にくいと思う
動画サイズに厳しい制限があるとその中でできるだけマシな画質にしようとするからノウハウが出てくる
画質とは少し違う話だけどYUV420や色空間の変換で色味が元と変わるのが気になって一時期エンコ設定沼に落ちたわ