background

もしもし亀よ

2007年09月06日(Thu)

そんなわけで、簡単な形状を使って実験。

クロスの大きさは大体2m四方。60cmの高さに配置する。衝突対象は拡大した円柱(基本小道具)と床で、円柱は床から少し浮いている。
シミュレーションは自己衝突にチェックを入れただけの初期状態。計算開始ボタンをクリックしてからシミュレーション中のプログレスバーが消えるまでの時間を携帯電話のストップウォッチで(笑)計る。
ちなみに、シミュレーションは一度最後まで行ってから、計算結果を消去して2度目に行ったものを測定対象にした。最初にシミュレーションを行う時、たぶん衝突対象とかクロスを計算用のテータに変換するような処理が入ってるんじゃないかと思われるためだ。

(1)まずは単純な四角ポリゴン。Shadeで長方形をポリゴンに変換して、8分割を2回かける。
4096枚の四角ポリゴンで、結果は51秒2。

070906-1

(2)次に、これをエクスポータで上限を三角ポリゴンにして出力した形状。
8192枚の三角ポリゴンで、結果は46秒1。

070906-2

四角ポリゴンに比べて滑らかな仕上がりだ。しかも、速度は四角ポリゴンだった時よりも速くなっている。が、案の定右手前の角と左右の角では明らかにドレープの現れ方が異なっている。

ここからわかるのは、結局四角ポリゴンも内部的には三角ポリゴンに分割して計算しているのだろうということだ。その根拠は、(1)と(2)で計算時間が変わらないかむしろ三角ポリゴンの方が早いこと、そして四角ポリゴンのクロスにも三角ポリゴンと同じドレープの偏りが見られることである。おそらく、PoserのDCもShadeのエクスポータと同じ分割をしているのだろう。四角ポリゴンの方が三角ポリゴンよりも遅いのは、三角ポリゴン2枚として計算した結果を四角ポリゴンとして辻褄合わせるための処理のようなものが間に入るからではないだろうか。と、憶測。

(3)そこで、Stellaterで作成した「流れ」のない三角ポリゴン。
4096枚の三角ポリゴンで、結果は24秒6。

070906-3

圧倒的に早いが、品質も圧倒的だ(笑)

それでもまあ、クロスの角を見れば均一にドレープが現れているのがわかる。

(4)では、最初の四角ポリゴンクロスをStellaterにかけてみる。
16384枚の三角ポリゴンで、結果は1分41秒7。

070906-4

やはり目が細かくなった分、ドレープも奇麗になった。ポリゴン数が4倍で、計算時間もほぼ4倍。見事な比例だ。しかし、気になるのは(3)のクロスと同じく、スムースシェーディングがうまく効かないのか、斑点のようなムラが多く現れていることだ。

070906-5

疎密の違いというよりは、稜線(辺)の長さの違いなのかもしれない。
どちらにせよあまりにも酷くなると、レタッチでも誤魔化せないレベルになってしまう。

(5)で、前回の方法で作ったやつ。
6726枚の三角ポリゴンで、結果は48秒6。

070906-6

残念ながら、(2)~(4)の三角ポリゴンのクロスよりも、ポリゴン数に比べて時間がかかる結果となってしまった。原因の一つは、布を四角形にしようとムリヤリ端のポリゴンを切って、小さいポリゴンを並べたことだろう。円柱の下に巻き込まれている辺りを見ても、不要に細かいポリゴンが絡まっているような印象を受ける。
しかし、(2)のようなドレープの偏りもないし、(3)や(4)のようなスムースシェーディングのムラも目立たない。はやりクロスシミュレーションに適しているのはこのような形なのだろう。

ちなみに、Euclidシリーズにはポリゴンメッシュにランダムな擾乱を与えるツールもある。ある程度加減して適用すれば、布の柔らかさにムラのあるようなメッシュも作れると思う。

問題は、フチの処理なんだよな……。

スポンサーサイト







Menu

Profile

Kyotaro

確定名:Kyotaro
ネタを探しているらしい。

Categories

Calendar

08 | 2007/09 | 10
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 - - - - - -

Comments

Archives

Track back

RSS feed

Links

Search

※2011年4月6日のサーバ障害の為、エントリのアドレスが以前のものからズレています。当Blogのエントリにリンクを張っておられた方は、お手数ですがアドレスのご確認をお願い致します。

※Internet Explorer非推奨。