background

法線といふもの。

2005年09月09日(Fri)

今回の内容は長文な上、いまいち精神衛生上よろしくないかも知れない。と、前置き。
 
既に棚上げしつつ進行しているのだが、作成中のブツはまだ別の問題を抱えている。
Shade上で作成した形状をPoserへ読み込むと、一部に沁みができてしまうのである。
 
060909-1

ポリゴンが裏向いているんじゃないの?とお思いのアナタ、私もそう考えたのだが、
そもそも裏向きのポリゴンはプレビューでは描画されないのだ。
さらに、この通りShade上では法線はすべて外向きに揃っているのである。
 
050909-2

Shade側のOBJ出力時には、法線情報を含めるか否かのオプションがある。
この情報が上手く反映されていないのかと、何度か設定を変えて出力を繰り返し、
しまいには形状そのものを作成し直したのだが、はやり結果は変わらない。
どうもPoserは最初から法線情報を使用していないような気がするのだ。
さらに、出力の度に沁みができる部分が異なっている。
 
……ここで途方に暮れる。
 
しかしこの沁み、よく見ると面の中の一点だけが妙になっているように思える。
問題の点だけ削除してもう一度面を貼り直そうとしたが、
ンな事をするとShadeはUVを破棄してしまうのであった。最初からやり直し。
 
……ここで怒りに震える。
 
まぁテクスチャを貼れば多少は誤魔化せるか……と諦めていたとき、
モデラーズギルドのチャットで、頂点にも法線があるということを教えていただいた。
法線というのは「面に垂直な方向」のことだ。なら頂点の法線とはなんぞや?
と不可解なままネットを徘徊すると、Wavefront OBJ形式の仕様書を発見。
無論英語である。PDFで78ページある。
 
……ここで眩暈を覚える。
 
が、ざっとナナメ読みしたところで驚いた。そもそも普通に法線と呼ばれているvnは、
"Vertex normals"つまり「頂点の法線」と記述されているではないか。
そんなわけで部分的な翻訳を試みてみた。以下が引用である。
~・~・~・~・~・~・~・~・~・~・~
[vn i j k]
 
Polygonal and free-form geometry statement. Specifies a normal vector with components i, j, and k.
 
Vertex normals affect the smooth-shading and rendering of geometry. For polygons, vertex normals are used in place of the actual facet normals. For surfaces, vertex normals are interpolated over the entire surface and replace the actual analytic surface normal.
 
When vertex normals are present, they supersede smoothing groups.
 
i j k are the i, j, and k coordinates for the vertex normal. They are floating point numbers.
~・~・~・~・~・~・~・~・~・~・~
(試訳)点法線vn i j k
ポリゴン形状と自由型形状のステートメント。i・j・kの成分で垂直なベクトルを指定する。
 
点法線は形状のレンダリングとスムースシェーディングに影響する。
ポリゴンにおいては、点法線は実際の面法線の代わりに使用される。
自由型形状の表面においては、点法線は全ての面にわたって補完され、
実際の解析による面法線を置き換える。
 
点法線が記述されていると、スムージンググループは使用されない。
 
i・j・kは点法線のためのijk座標系であり、浮動小数点数である。
~・~・~・~・~・~・~・~・~・~・~
[f v1(/(vt1)/(vn1)) v2(/(vt2)/(vn2)) v3(/(vt3)/(vn3)) . . .]
 
Polygonal geometry statement. Specifies a face element and its vertex reference number. You can optionally include the texture vertex and vertex normal reference numbers.
 
The reference numbers for the vertices, texture vertices, and vertex normals must be separated by slashes (/). There is no space between the number and the slash.
 
v is the reference number for a vertex in the face element. A minimum of three vertices are required.
vt is an optional argument. vt is the reference number for a texture vertex in the face element. It always follows the first slash.
vn is an optional argument. vn is the reference number for a vertex normal in the face element. It must always follow the second slash.
 
Face elements use surface normals to indicate their orientation. If vertices are ordered counterclockwise around the face, both the face and the normal will point toward the viewer. If the vertex ordering is clockwise, both will point away from the viewer. If vertex normals are assigned, they should point in the general direction of the surface normal, otherwise unpredictable results may occur.
 
If a face has a texture map assigned to it and no texture vertices are assigned in the f statement, the texture map is ignored when the element is rendered.
~・~・~・~・~・~・~・~・~・~・~
(試訳)面要素f v1(/(vt1)/(vn1)) v2(/(vt2)/(vn2)) v3(/(vt3)/(vn3)) . . .
ポリゴン形状のステートメントである。面要素とその頂点の参照番号を指定する。
任意でuv頂点と点法線の参照番号を含むことができる。
 
頂点とuv頂点、点法線の参照番号はスラッシュ(/)で区切られなければならない。
参照番号とスラッシュの間にスペースは入れない。
 
vは面要素中の頂点の参照番号である。最低三つの頂点が必要である。
vtは任意である。vtは面要素中のuv頂点の参照番号であり、常に最初のスラッシュの後に続く。
vnは任意である。vnは面要素中の点法線の参照番号であり、常に二つ目のスラッシュの後に続く。
 
面要素はその向きを示すために面法線を使用する。
頂点が反時計回りに並んでいる場合、面と法線は視点に向かう方向を指す。
時計回りに並んでいる場合は、視点から遠ざかる向きを指す。
もし点法線が割り当てられていると、点法線は面法線の一般的な方向を指し示す。
そうでなければ、予測不可能な結果が起こるかもしれない。
 
面がテクスチャマップを割り当てられ、かつfステートメントの中でuv頂点が割り当てられていない場合、要素がレンダリングされるとテクスチャマップは無視される。
~・~・~・~・~・~・~・~・~・~・~
以上。引用おわり。
 
肝心の"Specifies a normal vector with components i, j, and k"と"they should point in the general direction of the surface normal"がどうにも訳し切れない。
なので点法線がどうやって算出されるのか、どういう影響をおよぼすのかがわからない。
分かったことは、
 
・点法線はスムースシェーディング時に、頂点近辺の向きを示すために使用される。
・面の表裏は単純に、見た目頂点が時計回りに並んでいるか否かで決定される。
・点法線が面法線とぜんぜん違う方向を向いてたら、よー知らん。
 
ということぐらい。そして、点法線を持たないオブジェクトでもスムースシェーディングをかけることができるということは、そもそもPoserは全く別の算出方法で法線を決定しているということだ。
結局のところ、UVを貼って法線を抜いた形状で、沁みができる現状に変わりはない。
 
……ここで無力感に苛まれる。
 
徒労に終わってしまったわけだが、折角なので翻訳文をUPすることにした。
いつの日かこんな知識も役に立つ時が……来るかな。
 
050909-3

……ねぇ?
 
■頂いたコメント■


コメント:(kirakira)
こんばんは (・o・)/
 
点の法線…
CG に縁のないσ(・・*)には、なんのことやら(爆)なのですけれども、
曲線が何かしら関係しているような…
 
Poser ちゃん…
他ソフトからの取り込みは、かなりやっかいです(笑)
出力形式を obj 以外にしてみても良いのかも?知れませんね…
(モーフのみ、obj 以外はダメ… な感じですけれども…)
 
あとは… 六角・Shade には気をつける…という感じでしょうか?
自分で出力形式や取り込み方法などをあらかじめ調べて、決めておかないと、
やり取りで混乱してきますし(笑)
(; ̄ー ̄A アセアセ・・・
 
たいへんですね~(苦笑)
 

コメント:(rose)
最初に忠告されたにも関わらず、読んでて具合が悪くなりました(笑)
よくまあここまで調べたものだと、例によって尊敬してしまいます。
 
Kyotaroさん、しっかりっ!突き詰めちゃだめよ!世の中には見て見ぬ振りという生活の知恵もあるじゃないですか。
……だめ?(笑)
脱力する前にAさんを……あ、Aさん……(笑)
 

コメント:(Raika)
わーい英語で幾何学ー!すいませんちょっと眩暈が・・・(爆)
理系の友人と飲んだ時「この世の物事は全て法則の上に成り立っているのよ。ひひひ。」と
絡まれたこと(!)を何故か思い出しました。
しかしえらいこっちゃですね。奥の深さが身に沁みます。さすがKyotaroさんだ・・・
 
Aさん・・・パーツ余ってますよ?
高速回転させた羽根が前に飛んでこないことをお祈りいたします(爆)

コメント:(基上(motokami))
初めまして。ぽざくら非会員の基上です。
 鍵の画像の妙な陰…
 陰のあるところの頂点が二重になってやしませんでしょうか?
 鍵の胴体部分を楕円の掃引体で作ったとしたらその可能性は低いですが…。
 私の経験上、あの手の陰の下には頂点が重なっていて、面が折りたたまれているケースが多いです。
 的はずれor確認済みでしたらゴメンナサイ。スルーして下さい~。
 

コメント:(MUKA)
のーん(´-ω-`)
また難しいことをしていらっさる・・・・・
 
えーと絵として使うには問題有るかもしれないですが、Poser上で歪むんですよね?鍵のオブジェクトだけ「スムースポリゴン」のチェックって外してみました?結構奴悪さして不正な影?生成してくれやがリマす。
 
Aさん・・・・
扇風機のボタン無くなってますぜ(笑)
 

コメント:(Kyotaro)
>kirakiraさん
どうやって算出するんでしょうね……>点法線
おそらく隣接するポリゴンの法線の総和なのでしょうが、まだわかりません。
頃合いをみて、他の入出力を試してみます。それにしても、
こうしてみるとメタセコイアがPoserと相性がいいと言われるのがよくわかりますねぇ(^^;
 
>roseさん
相変わらず攻撃力の高いブログですみません~A^_^;)(笑)
生活の知恵!(笑) そうだ、見えないことにしてしまおう!
Kyotaro、もうオトナにならなきゃ!(←バカ)
 
>Raikaさん
そりゃ~災難です(笑)理系の方にはそういう方多いですけどね~。
という自分も一応理系なんだな、気をつけよう。まちがっても「法線ベクトルと男の色気について」なんつーテーマで語ってしまわないように(死)
 
>基上さん
初めまして&ようこそいらっしゃいませ(^^)
ご指摘ありがとうございます。
実はこの形状、ラップマッピングしたテクスチャをUVにしたかったので、円筒部を残し、蓋と底は一本一本ポイントを繋いで面を貼るという非常にプリミチブ(笑)な造り方をしておりまして。
非常に心当たりオオアリだったので早速確認いたしました。
プラグインによると、頂点の重複はない……ようです。
ちゃんと出力前に確認しておかないといけないですね。勉強になりましたm(__)m
 
>MUKAさん
スムースシェーディングを0度にすると染みは出ないのです~。でもカクカクなのです~(TT
と、言われてフと、スムースシェーディングの角度をいじってみました。
37.54度を超えると問題の部分にスムースがかかるようになり、その途端に染みができるようです。それ以下の角度だと問題の部分にエッジが立ち、染みは現れません。
……そもそもこのエッジを立てたくないから……ないから……゜・(つД`)・゜・
 
あとこの形状、UV値を書き出さない(頂点データのみにする)と、スムースシェーディングでも正常に表示されました。
UVは円筒部はラップマップで、蓋と底は平行投影で別々に割り当てています。
なので、どうやら不連続なUV値を持っていると、Poserはシェーディング時に上手く計算できなくなることがある、ということになりそうです。
……そもそもテクスチャを貼りたいから……貼りたいから……゜・(つД`)・゜・
 
さてこの後のAさん。果たして正解は!?
1.動かない扇風機を燃えるゴミの日に出して大家さんに叱られる。
2.今度はエアコンを分解しようとして感電。まいそうされる。
3.やっぱり暑いので、風を起こすべく室内で真空波の呪文を使い、猟奇的大惨事。
 

コメント:(seisui)
shadeからの読み込みには、過去に何度も泣きました(^^;)。
問題の部分の横軸の分割数をあげてみても駄目かしら?
面張り方向を変えてみるのも、時々(笑)効果がありましたが
解決できない事の方が多かったです(--;)。
頑張ってください(><)。
 

コメント:(kirakira)
頂点の法線ベクトル…
 
わたしには、なんのことなのかさっぱりわかりませんので(爆)
http://homepage1.nifty.com/t_kuji/3DCG_guide/normal_vector/normal_vector.html
こちらをご覧ください。
他にもいろいろと探せば見つかると思います~。
 
あの…
とあるところで質問されているのは、Kyotaro さん?(笑)
パイソンとか…(笑)
ちがうのかな?…
 

コメント:(Kyotaro)
>seisuiさん
Shadeとのやり取りは、いろいろ難しい問題が多いみたいですね(^^;
教えて頂いたようにに分割数を上げてみると、まだちょっと怪しいんですが
シェーディングで殆ど目立たなくなりました! ありがとうございます~m(><)m
でも、UVが飛んじゃった……あう……(悲)
 
>kirakiraさん
ああ、これは分かりやすいですね。有り難うございます(^^
やっぱり総和の単位ベクトルか~。これにUV情報その他がどういう補正をかけるのかは、
もうPoser独自の処理なんでしょうね。(;--)
とあるところ……? あ、ホントだ(笑)なんてタイムリーな。
では、お答えされているのは、kirakiraさん?(笑)なんちゃって(^^;
お答えしておくと今のトップ画の鏡は片面ポリゴンです(笑)




Menu

Profile

Kyotaro

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

Categories

Calendar

09 | 2017/10 | 11
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 31 - - - -

Comments

Archives

Track back

RSS feed

Links

Search

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

※Internet Explorer非推奨。