Hinabita's FanArt XXX Anime Gallery

えー。すまん。
突っ込み所が多すぎだー。

■シーンについて

使ってないシーンは消しといた方が良いと思います。
現ファイルだと
Base_Room_toon
Base_Room_toon.001
Base_Room_toon.002
の3シーンがありますが、Base_Room_toon.002以外は消しましょう。
これはドライバやコンストレイント等でオブジェクトやボーンを指定する際
間違えて別シーンの物を使ってしまうとかあるから。
つか現シーンではCube.002のDriver/Location指定相手間違えてます。
ここCube_dummyじゃ無くてCube_dummy.001でしょ。

同様に名前間違いを無くすべく、オブジェクトにはわかりやすい名前つけるべき。
Cube.002とかやめ。せめてCube_inflowとか。メッシュの名前も同様。

オブジェクトを用途毎にレイヤへまとめとくのも重要。
Inflowオブジェクトとベッドが何で一緒のレイヤにありますのん。

■Fluid射出の向き及び表示/非表示について。

□1□
Cube_dummy.001
Constraint/Copy LocationでBone010の場所をコピーしてますが、同様に
Constraint/Copy rotationでBone010の回転もコピーしてしまいましょう。
なんでかと言うと
Inflow用オブジェクトのDriver設定時に場所も回転もこいつだけを参照すれば良くなるので
間違いそうな箇所が減ります。

加え、レンダリング時にこれが描かれては困るので
Outlinerのカメラアイコンをクリックしてレンダ時描画されないようにしときましょう。
（目のアイコンとカメラアイコンがありますが
目の方は3D View（編集画面）での表示/非表示
カメラの方はレンダリング画像での表示/非表示を操作します）
現シーンでは目の方しかクリックされておらず、レンダリング時には表示されてしまう状態です。

□2□
Cube.002　Inflow用オブジェクト
Armature_joel.002のBone010にペアレントされてますが外してください。
このオブジェクトの場所と回転はCube_dummy.001からDriverで持ってきます。
（ペアレントしといてもなんか大丈夫そうですが余計な計算はさせないようにしましょう）
（不具合や謎の元になる場合が多いので）
この際親が無くなることに寄ってオブジェクトのサイズが変化します。
適切な大きさにリサイズし直しましょう。

Fluid/Inflow指定でExport Animated Meshのチェックが入ってますが外してください。
これも上記同様場所と回転はCube_dummy.001からDriverで持ってくるからです。
Local Coordinatesは入れたままでOK。

さてDriver指定です。
まずは。
DriversのType:種類ですが
　Maximum Value　最大値
　Minimum Value　最小値
　Scripted Expression　指定したVariable名の値
　Sum Values　合計値
　Averaged Values　平均値
なので、
参照先が1つの値（XRotationのみとか）の場合おそらくどれでも機能しそう
だが、間違いなく安全に安定して指定するならば
　Scripted Expression　指定したVariable名の値
を選んでVariable名を指定すべきと思います。
"Var"て奴ですね。
Location3つ、Rotation3つ全て直しましょう。

先にも書いたとおり
Ob/Bone:への指定が現シーンでは間違っております。直しましょう。
んでRotationの方の指定もCube_dummy.001にしときましょう。

Y Euler Rotationへの指定にXYZ3つVariablesついてますが
これはいろいろと間違っております。
Cube.002の、Properties/オブジェクトタブでのTransform/Rotation Mode:はXYZ Eulerです。
Quaternion(WXYZ)じゃないんです。
DriverもXYZそれぞれへの設定です。故に
Y Euler RotationへのVariablesはCube_dummy.001のY Rotationのみにしなければいかんのです。
現シーンの指定だとXYZの値を足した物になっちゃってます。直しましょう。

ついでに。
Drivers下のModifiersは
使用しない場合消しちゃった方がいろいろ勘違いとかしないで済むので
消しときましょう。

最後にこのオブジェクトがレンダリングされないように
前述のCube_dummy.001と同様
Outlinerのカメラアイコンをクリックしときましょう。

現在こちらが使用しているBlenderのバージョンは
blender-2.56a-beta-windows32 r34076
Blender本家から落とせる最新の物のはずです。

あらかた説明したつもりではありますが、
Outlinerて何だ？とか
これは何言ってるかわからんとか
これはどうしてそうせねばならんのだとか
謎があったらどしどし聞いてみてください。

てことで。
一つでも読み飛ばすと上手くいかんと思うので頑張ってねー。

あー
前提条件としてCube_dummyってなんだという…
もしかして組み込んだけれど必要なかったという
元データを作ってくれた「」が言っていた物でしょうか
Cube_dummyを使わずarmature_joel.002.bone10で
良いとか言っていた奴かな？
うーん、Cube_dummyの消し方も分からない
もう元データから作り直した方が良いのかな…

ベットとInflowが同じレイヤなのは
そのレイヤがレンダリング時に消すレイヤという
用途のレイヤだったからです

シーン002に実験アニメを付けていた状態で
001や000（ではないけど元データ）を流用していました
関係ないけれどシーン001と002でジョエルのアニメが
何故か共有になってしまう現象も解決が分からなかったですね

取りあえずdummyについて
１：ジョエル股間bone10の角度・位置を
　　コンストレイントでcube_dummyにコピーする
２：cube_dummyの角度・位置を
　　driverでcube_Inflowにコピーする
と理解したのですが（そもそもここまでは合ってますか？）
１については出来たものの
２のcube_inflowの位置をdriverでコピーが理解できてないっぽいです

cube_inflow.002のTransformタブのLocationとRotationにて右クリック＞Driversを足して
X LocationにはTransformChannel Cube_dummy.002のXLocation
Y LocationにはTransformChannel Cube_dummy.002のYLocation
Z LocationにはTransformChannel Cube_dummy.002のZLocation
XEulerRotationにはTransformChannel Cube_dummy.002のXRotation
YEulerRotationにはTransformChannel Cube_dummy.002のTRotation
ZEulerRotationにはTransformChannel Cube_dummy.002のZRotation
をそれぞれ参照させてみましたが上手くいかないようです

取りあえずcube_inflowとBone010の親子関係を外してみました所
場所がおかしくなるのはやはりDriversが正しく動いてないからでしょうか？

inflowのExport Animated Meshを外してもDriverが正しければ
Bone010のアニメを追従してくれるんだろうなとは思いつつも
ExportAnimatedMeshを外してしまうと全く流体アニメしなくなりますね

あと昔のコメントでdummyは使わず直でbone010の位置角度をDriversしても平気だった
と言う旨の書き込みがあったのですが、
これはdummy要らないって事なんでしょうかね？となると
Cube_inflowにDriversでBone010の位置角度をコピーすればいいのかな？
問題は位置のコピーの仕方が結局理解できてない事っぽいですが
dummyを挟むとコンストレインツのCopy LocationにHead/Tailでオフセットが使えるので
Driversからオフセットが難しいから挟んでる？とか思いましたが合ってるのかな…

そもそもコンストレインツで直にbone010の位置角度を
Inflowにコピーしただけじゃダメなのかな？と試してみましたが
どうもExport Animated Mesh切ってると駄目っぽい？ですね
Driversを経由しないと駄目なのでしょうか…

http://atariya.dip.jp:8081/pictures/pool/neoranga_rig_110320.zip
色々弄っていたファイルです

と思ったらなんか上手くいったっぽい
Scripted ExpressionからSum Valuesにしたら
ちゃんと位置に納まりました
Scripted Expressionの指定が悪かったぽいですね

> ２のcube_inflowの位置をdriverでコピーが理解できてないっぽいです

> 取りあえずcube_inflowとBone010の親子関係を外してみました所
> 場所がおかしくなるのはやはりDriversが正しく動いてないからでしょうか？
YES。

> inflowのExport Animated Meshを外してもDriverが正しければ
> Bone010のアニメを追従してくれるんだろうなとは思いつつも
> ExportAnimatedMeshを外してしまうと全く流体アニメしなくなりますね
YES。
Driverがうまく動いてないとInflowオブジェクトがえらい変な位置に置かれてしまう
→多分Domain領域から外れた位置とかに居る
→液出ない
という具合かと。

> Scripted ExpressionからSum Valuesにしたら
> ちゃんと位置に納まりました
> Scripted Expressionの指定が悪かったぽいですね
Scripted Expressionのした際
名前入れるの忘れてたりはしませんでしたか～？

> 　Scripted Expression　指定したVariable名の値
> を選んでVariable名を指定すべきと思います。
> "Var"て奴ですね。
https://yu-hi.sakura.ne.jp/hinabita/media/driver3.jpg
の3の5ね。
入れないとまともに動きませんよ～。

Sum Valuesで動くのは
> Sum Values　合計値
だから。でも
> 参照先が1つの値（XRotationのみとか）の場合おそらくどれでも機能しそう
> だが、間違いなく安全に安定して指定するならば
> 　Scripted Expression　指定したVariable名の値
> を選んでVariable名を指定すべきと思います。
てことで。まあ動きゃいいやてんならどうでもいいかも知れんけど。

> dummyを挟むとコンストレインツのCopy LocationにHead/Tailでオフセットが使えるので
> Driversからオフセットが難しいから挟んでる？とか思いましたが合ってるのかな…
dummy挟むやり方は"夜の「」"氏のなんでちと謎ですが
> Inflowオブジェクトの位置と回転にDriverを使っていますが、
> 位置についてはboneが対象だとうまくいかなかったので
> Copy LocationしたダミーのCubeを使っています。
てことなようですな。

> そもそもコンストレインツで直にbone010の位置角度を
> Inflowにコピーしただけじゃダメなのかな？と試してみましたが
> どうもExport Animated Mesh切ってると駄目っぽい？ですね
> Driversを経由しないと駄目なのでしょうか…
これ多分計算順の問題なので説明めどいし難しいの。
まずExport Animated Meshは後回しで書きますが関係は無いつか別です。
で。
えーと
A:生のInflow位置方向
B:DriverによるInflow位置方向決定
C:コンストレインツによるInflow位置方向決定
D:ParentによるInflow位置方向決定
がありまして。射出位置方向はこのどれかあるいは組み合わせ
+Export Animated Meshや+Local Coordinatesで決定されるのね。
が、Blender内部においてABCDの順番や優先順位がある訳です。
射出位置方向決定においてそれらのどの時点でどの値を取ってくるか
てのが問題な訳ですが。

CやDだと射出が持ってくる値が欲しいのと違っちゃってるんだ。
バグじゃないよ。「どの時点でどの値を取ってくるか」が違うの。
で、Bはまともに欲しい値が得られるのでこれを使う、と。
すまん。半端ですまん。
きっちり検証しないと「どの時点でどの値を取ってくるか」はわからんのですが
ちと今時間無い。日を置かせて貰えればなんとか。

■Animated Mesh ExportとLocal Coordinates

以前にも書きましたが
> おそらくAnimated Mesh Export入れると
> オブジェクトの情報無視してメッシュの情報のみ参照してしまう
ようでして。
この場合、メッシュのワールド情報のみの参照ですから
Local Coordinatesチェックを入れても
InflowオブジェクトのXYZ軸の向きは無視されてしまうようなのです。
となると液の射出方向を指定してるInflow Velocityは
ワールド座標系のそれで決定されてされてしまうわけで。
位置は合っても方向がなんか変になる、と。

故にInflowオブジェクトのローカル方向で射出しようというのならば
Animated Mesh Exportは外さんといかんのう、と。

てことで。
いろいろ長かったり半端だったりですまん。

> inflowのExport Animated Meshを外してもDriverが正しければ
> Bone010のアニメを追従してくれるんだろうなとは思いつつも
> ExportAnimatedMeshを外してしまうと全く流体アニメしなくなりますね
YES。
Driverがうまく動いてないとInflowオブジェクトがえらい変な位置に置かれてしまう
→多分Domain領域から外れた位置とかに居る
→液出ない
という具合かと。

すまんこれちと間違ってるかも。というか要検証だ。ごめん

最新のfreestyle統合版2.56.3 35616でデータ保存したら
古い（と言っても2.56.1)blenderで読み込むと
ノードがおかしくなるようになってしまって
修正も出来ずに困ってます

基本的に公式ビルドで保存しておいて
設定差分覚えるしかないのかな…うぐぐ
Driver抜きなら2.48形式で保存しておくんですけれどね

Inflow関係まとめー

■Volume Initialization:
射出形状のタイプ

■Inflow Velocity
射出ベクトル

■Export Animation Mesh
射出位置と形状の決定において
Inflowオブジェクトの子であるメッシュの
グローバル座標空間での移動/変形等を参照する
メッシュは形状や位置の情報は持つが方向情報は無い
方向情報は親であるオブジェクトの担当
故にオブジェクトの向きに関らず射出方向はグローバル座標軸に準ずる

■Local Coordinates
射出方向の決定において
Inflowオブジェクトのローカル座標空間のXYZ軸を参照する
射出位置の決定において
Inflowオブジェクトのローカル座標位置を参照する

Export Animation MeshとLocal Coordinatesを同時にチェックした場合
Export Animation Meshが優先され
Local Coordinatesは無視される

これらのことから

射出方向
オプション無し： グローバル座標空間のXYZ軸にてInflow Velocityのベクトル
Export Animation Meshチェック時： グローバル座標空間のXYZ軸にてInflow Velocityのベクトル
Local Coordinatesチェック時： Inflowオブジェクトのローカル座標空間のXYZ軸にてInflow Velocityのベクトル

射出位置
オプション無し： Inflowオブジェクトのローカル座標数値
Export Animation Meshチェック時： Inflowオブジェクトの子であるメッシュのグローバル座標空間での位置
Local Coordinatesチェック時： Inflowオブジェクトのローカル座標数値

射出形状
オプション無し： Shape Keyアニメやボーンでの変形等メッシュの形状変化は反映しない
Export Animation Meshチェック時： Shape Keyアニメやボーンでの変形等メッシュの形状変化を反映する
Local Coordinatesチェック時： Shape Keyアニメやボーンでの変形等メッシュの形状変化は反映しない
*どれにおいてもローカルのスケール値は反映される

となる

■ローカル座標
選択されているオブジェクトのローカル座標での位置/方向は
3D Viewウィンドウ内でNキーを押した際出るPropertiesパネル→TransformのLocation/Rotationの値
あるいは
Propertiesウィンドウ→TransformのLocation/Rotationの値
で確認できる

親子関係あるいはCopy Loc/RotやChild of等のコンストレインツにて接続された
子オブジェクトのローカル座標での位置/方向は
親オブジェクトがどう動こうとも変化しない
唯一Driversのみが子オブジェクトのローカル座標の位置/方向の値を変化させることができる

これは
親子/コンストレインツの場合
子オブジェクトのローカルでの移動や回転も生かす為ローカルの数値は別扱い
Driversの場合
子オブジェクトの移動や回転関係なくローカルへ値を直にぶちこむ
という動作の違いに寄るものと思われる

■Tips
DomainのBakeをする際
指定したディレクトリ内に以前のBakeデータが残っていた場合
計算速度が低下/計算結果にも影響が出る

てことで

グローバル座標＝ワールド座標の意と考えてください
Blenderだとこういう用語になってるらしい

> 最新のfreestyle統合版2.56.3 35616でデータ保存したら
なんかPythonのdllバージョン上がってたりしてますな
あとバージョン違いを1つのPC上で共存させた場合
デフォルトだとUser Preferences共有されてるみたいなんで
File PathsのTexture Plugins/Sequence PluginsとScriptsのパス指定にはご注意をばー

つか最新freestyle統合版のみで作業て訳にはいかないのん？

freestyle統合版2.56.3 35616
が不安定なのかこのバージョンで加工したデータが不安定なのか
２～３コマレンダリングすると落ちるので前のバージョンでレンダリングしたいと思ったのですが
前バージョンで読み込むとマテリアルノードのグループが壊れていて
セーブしなおすとデータが壊れて二度と読めなくなったりします
http://atariya.dip.jp:8081/pictures/pool/neoranga_rig_110320x4.zip
これがfreestyle統合版2.56.3 35616で加工、保存したデータです
http://atariya.dip.jp:8081/pictures/pool/neoranga_rig_110320x5.zip
こっちが一旦加工後に2.56.1で再保存しておかしくなったデータですね

http://atariya.dip.jp:8081/pictures/pool/neoranga_rig_110320x4.zip
http://atariya.dip.jp:8081/pictures/pool/neoranga_rig_110320x5.zip
うちの環境だと両方とも2.56.3 35616なら読めますな。
110320x5の方だとFreeStyleのLine Styleがちょっとおかしくなってるけど落ちることは無し。

メモリ不足なのかレンダ時にFreeStyleのMesh loading中に
Warning: edge 数字 - 数字 appears twice, correcting
てのを大量に吐きつつBlender落ちますが。
ベッド等背景の乗ってるレイヤオフにすると一応レンダできる模様。
こっちはWinXP32でメモリ8G（余剰はRamDisk）なんですが
そっちはメモリどのくらい乗っててDos窓では何て言ってる最中に落ちますか。
上記と似たような具合だとポリゴン数減らすかWarningの原因突き止めて対処って感じですかのう。

うちのFreeStyle無し版は2.56.0 r34076なんですが確かにノードおかしくなりますな。
Materialsの項目もちょろちょろ違ってるしここらへん互換性無いかも知れん。
110320x5は読み込んだ瞬間落ちます。

>Warning: edge 数字 - 数字 appears twice, correcting
従来のバージョンではこれが出ても落ちなかったんですよね
新バージョンで弄ってから落ちるようになりました
落ちるときのウィンドウには
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
ランタイムの例外呼び出しっぽいエラーが出ていました
統合新バージョンが出たら治るかもしれないですが

メモリ自体は相当載せているものの統合版blenderが32bitアプリなので
２Ｇまでしかメモリは使えないと思います、それでもタスクマネージャ確認しても
８００Ｍ程度で済んでいる模様、fluidsim時の２Ｇギリギリよりは少ないです

>Warning: edge 数字 - 数字 appears twice, correcting
従来のバージョンではこれが出ても落ちなかったんですよね
新バージョンで弄ってから落ちるようになりました

うｎー。
このWarning、Subsurfaceモディファイヤ入ってるオブジェクトあると
出るみたいなのを発見。

そうかそっちも32bitか。ぬう。
ところで椅子やらベッドやら電気スタンドのようなものやらに
Subsurfaceモディファイヤ入ってるのでとてもポリゴン数食ってます。
これ外したらかなり軽くなった。試す価値あるかも。

電気スタンドsubsurf入れないと傘裏の線画が透けちゃうんですよね
ベットの陰とかも綺麗目に出そうとすると必要だったり
でも椅子辺りは既に面数多いから要らないのかな？
subsurfが原因で落ちるっぽいならsubsurf使う場所少なめにするしかないかもですね
毎回同じ場所で落ちるわけでもなく再起動するとレンダリングできたりするのが不明です

110320x4
画像サイズ16分の1にて
椅子2つ、電気スタンド、ベッドのSubSurfaceを外してレンダ、
フレーム49のBuilding the view mapでハング。
椅子2つ、電気スタンド、ベッドのレイヤを外してレンダ、
フレーム49のBuilding the view mapでハング。

…あれー？
あー49フレーム目単体でも駄目だな
でも50フレーム目はいけるなあれー？
…49フレーム目で夕姫の位置をちょっとだけずらしたらレンダできるようになったー！？

という訳で。
Importing triangular meshes into Blender中つまり
Warning: edge 数字 - 数字 appears twice, correcting
が並んでく最中に落ちるならレンダ時のポリゴン数
Building the view map頭で落ちるならジョエルと夕姫等の重なり具合を直せば
おそらく110320x4を2.56.3 35616で全部レンダできると思われます。

次からは自分でも検証してみよう！

丁度今４９コマ目で設定弄っても詰まっていて悩んでいました
重なり具合で落ちたりするんですね…

> 重なり具合で落ちたりするんですね…
Building the view mapてのは
カメラから見てどこへどういう具合に線引くかマップ作成
と思うので、
そこで落ちるならば
線引かれるべき場所のポリゴン角度や
重なり具合かのう、と推測。

他フレームと49フレームの違いは
汁、ジョエルのポーズ、夕姫のポーズ
で試しに汁消しても落ちる、と。

なれば他2つのカメラに対する角度やら位置やら重なり具合の問題かなあという訳です。

カメラ角度1度弄っただけでもいけました。

もしかすると
https://yu-hi.sakura.ne.jp/hinabita/archives/2011/01/30025645.html
にある黒い線と関係あるかも。
あれもカメラ動かすと消えたし。

>https://yu-hi.sakura.ne.jp/hinabita/archives/2011/01/30025645.html
>にある黒い線と関係あるかも。
>あれもカメラ動かすと消えたし。

この線、カメラ動かすとそのコマからは消えたものの
また別のコマに出たりするんですよね
通してレンダリングしてみないと出るか出ないか分からないのが
非常に面倒くさいです