ラベル work flow の投稿を表示しています。 すべての投稿を表示
ラベル work flow の投稿を表示しています。 すべての投稿を表示

3/03/2016

3D CGI: trilobites manufacturing work flow 11 扱えるdata サイズの上限について

自分のPCで扱えるdata sizeの上限を調べてみた。


方法
サイズの異なるfileを用意し、特定objectをclickしactiveになるまでの時間をstopwatchで計測した。その所要時間を操作の快適性の指標とした。Blender以外のapplicationは起動しなかった。


用いたhard ware spec
Linux KDE 17.3/ Blender2.76
Core i3,3.2GHz,  8Gbite, SSD+HDD, GTX750Ti, dual monitor, Logicool G300 game mouse, WACOM intuos, 400W power supply 


条件
全layerのobjectを表示し、特定objectがactiveになるまでの時間を、表示modeを変えて測定した。rendered modeは実施しなかった。textureを多用していないのでtexture modeも実施せず。



結果

1回目
141M/ v 1321000, f 15c0000, objet 3570


表示時のmemory消費量2.2G、選択時CPU稼働率は1 threadのみ100%

material mode 4.7秒
solid mode 4.5秒
wire mode 4.4秒

暫定評価としてダメです。


viewport表示はそれなりに緩慢ですが、それに関してはかろうじて受忍限界内。





2回目 上記ファイルよりtrilobiteを複数削除
94M/ v 940000, f 1000000, object 2460

表示時のmemory消費量2.0G、選択時CPU稼働率は1 threadのみ100%

material mode 3秒
solid mode 2.98秒
wire mode 1.22秒


3回目
74M/ v 770000, f 85000, object 1930

選択時CPU稼働率は1 threadのみ100%

material mode 2.3秒
solid mode 238秒
wire mode 1.2秒



4回目
55M/ v 460000, f 650000, object 1300

選択時CPU稼働率は1 threadのみ100%

material mode 1.52秒
solid mode 1.6秒
wire mode 1.2秒



5回目
35M/ v 380000, f 420000, object 700
かなり寂しくなりました。

操作に遅延感がないので測定は実施せず




考察

141Mのデータはobject選択に4秒以上かかり、到底快適な操作性とは言えない。

74M データの2.3秒は、どうにか受忍限界内とおもえる。

wire mode では所要時間は短いが、作業上実用性にかける。

自宅PCで全object表示で作業するには35-54Mあたりで、上限に達するようです。
もちろんlayerにより現実的対応が可能でしょう。



object選択にかかる時間は、このcpu稼働ピークのベースラインと思われます。
どうも1threadしかCPUが使われないようです。
そういえばclothやfluid similationも1 threadしか稼働してなかった気がします。


これが原因なのか結果としてそうなるのか不明。

まあsingle Coreの速度が必要なのでしょうね。


もしここでmulti Coreでプロセスが作動してくれれば、劇的な改善になるのでしょう。
逆に考えるとマルチコアCPUに換装しても、シングルコアのperformanceが劇的にあがるわけがないので作業効率の改善はさして期待できない頃になりますね。
まあ個人的考察だから正しいかは不明、

他のメジャーな3d applicationはどうなんでしょう。

3/03/2015

3D CGI: trilobites manifucturing work flow 01

Linux mint17環境を使い始めましたが、何か寂しい気がする。
理由は、Comic sans MS fontがないから。
個人的に緊張のない雰囲気を醸成させるこのfontが好き、同様の理由により嫌いな方もおられるようです。

そこでComic Neue fontを代替に使用してます。
しかしComic sans MS の醸成する緊張感のなさは再現しきれないようです、残念。





trilobites manifucturing work flow  01



0. 好みのtrilobiteを決定する
1. 頭部(cephalon)と胸節(thorax)を並行して制作を始める
2.cephalonに先行してthorax nodeを凡そ完成させる
3. 頭部以降に連結する胸節と頭部を馴染ませるため、頭部後端に胸節をboolean union
4. shape keysを使い連続した形状変化を伴う8-10個の胸節を制作
5. 同様にshape keyを使ってモーフした複数のThoraxから尾節(pygidium)をboolean unionで作成
6. 頭部から尾節までrigを設定する
7. 出来合いのlegをappendする。legはinstanceで使用する。



作成方針

trilobitesの由来は体軸からみて中心と左右肋で合計3つのlobe(葉)。
頭部、胸部、尾節ではないらしい。

trilobitesは節足動物Arthropodaであるから、human modelingのようにone-peace meshである必要はない。
また外骨格なので各節は剛体とみなせる。

つまり制作自体は可動関節付きロボットなどのモデリングと同様のflowとなる。


まずはwikipediaから
(引用はじめ)

節足動物の特徴


体表面はクチクラキチン質タンパク質等)でできた外骨格でおおわれる。成長に伴い体のサイズが大きくなるときには、脱皮により古い外骨格は脱ぎ捨てられ、新しい外骨格が形成される。

体は、体節の繰り返し構造、つまり体節制をとり、体の表面を被う外骨格も体節単位になっている。体節の間は関節状に可動であることが多い。ただし、複数体節の融合や分化など、いわゆる異規体節制がある程度以上発達し、頭部はそれぞれの群で独特の複数体節が融合(合体節)してできたものである。口器は頭部に含まれる体節の付属肢に由来する。種類によっては、体節のうちの特定のものが組み合わされてひとつづきの外骨格で覆われる場合などもあり、外観上あるいは機能上の単位を構成する。例えば、体を頭部、胸部腹部の3部、または頭胸部、腹部の2部に分けて呼ぶ場合があり、これは節足動物の各分類群ごとの特徴として用いられる。
各体節からは、それぞれ一対の関節肢と呼ばれる脚が出ている。関節肢も体と同様に外骨格で覆われ、途中に関節がある。
(引用終わり)

これが三葉虫作製の基本的方針のヒントになりました。

端的に述べると意外にzeroからmodelingするobjectは少なく、インスタンスおよびその派生物の流用が可能ということ。

Kayserops megaspina

例としてこのtrilobiteで実質的にvertex編集を主に伴う作業をしたmeshは、

  • 胸節 1個 
  • 頭部 1個 
  • 尾節 1個 
  • 複眼 1個
  • 触手 1個
  • hypostome 1個  既存object使い回し
  • 二肢脚(6節からなる歩脚+鰓脚)既存object使い回し
合計 13 object

触手はスプライン exclureですので、まあモデリングとは言えません。

つまり新たにtrilobiteで必要なmeshは、頭部、胸節、尾節、複眼となります。

なお尾節は節足動物の形態学的または発生学的側面から胸節融合により形成されるとします。


つまりこのようにboolean operation で作ります。尾節は胸節が癒合して形成されたようですから。

胸節は、node1のshape keyをベースにnode tailendのshapeを追加し、新たなshapeを形成し、duplicateを必要数を用意して作ります。

結果非常に綺麗に連続的変化をnodesに与えることが出来ました。
なお特段問題ないならこれらモーフは最後までfinalizeしないでおいたほうが8日もしれません。

tipsとしては、同じmeshにshape keyを追加するとlatticeがかからないようなので、複製したmeshからshapeをコピーした方が自由度が高いかもしれません。


結論trilobite作成上、shape keyは非常に有用な手法。特に連続的な形状変化を示す 3-11個の胸節作成に大きなアシストとなる。



当然頭部も後端は。thorax nodeと融合 boolean unionにより馴染みやすい形状にします。



振り返ると、意外なほど作成すべきmesh dataは少ないことがわかります。

その分、thorax nodeは充分に納得できるまで作り込むことが重要ですね。