kanra-blog

8になった頃に、輪郭のレンダリングでポリゴンのエッジ全部に輪郭が出てしまう問題がありましたが、あれと根本的な理由は同じかもしれない。
UVを自由に編集できるようにするために、VMAPデータの持ち方を変えたようですが、そのせいで本来エッジでは無いところをエッジと判断したのではないかと。
そして、それはポイントが内部で複数の情報を持ってるからではないかと。
で、エッジウェイトの設定の仕方がおかしいため、ポイントの情報がばらけてしまい、変な壊れ方をするのではないかと推定してやす。
モーフマップ関連でも似たようなバグがあったし。
そういえば、8のsdkは見てなかったけど、その辺の情報が載ってるかもしれない。
つーか、エッジもポイントやポリゴンのように扱えるんだから、エッジウェイトはエッジデータ自身に持たせればいいのに、今の仕様ではポイント、もしくはポリゴンのポイントにデータを持たせてるっぽいのが、ややこしくなってる原因だろう。
（逆に、エッジにウェイトを持たせてる事が、既存の処理でデータが壊れる原因という可能性もあるけど多分違うと思う。）
とにかく、使う使わないの話じゃなくて、使えないレベル。

Catmull Clark曲面自体も、レイアウトで表示してみたら無茶苦茶重いし。
つーか、分割結果が変。
Catmull Clark曲面は1枚の四角ポリゴンを4分割する事を繰り返して滑らかな曲面を形作るわけですが、その過程で収縮していきやす。
最初の分割は、最初の面の情報を参照して行われます。
次の分割は、最初の分割で作られた面の情報を参照して行われます。
そうやって同じ処理を再帰的にかけてるそうです。
だから、分割するごとに4倍に増えていきます。(三角ポリゴン等は別)
分割数は(2のレベル乗)の2乗というか、4のレベル乗でした。
分割数が多くなってくると、隣り合う面が平面に近づくので縮みにくくなっていきます。
立方体にメタフォームを複数回かけてみれば、どういう事か分かると思います。
メタセコのCatmull Clark曲面も、同様のものだと思われるmaxのNurmsも同じように収縮します。

ところが、
LightWaveのCatmull Clark曲面は縮みません。
正確には1回目の分割では縮むのですが、その後の分割では、その前の分割でできたポイントの位置を通るメッシュが生成されます。
サブパッチなら、最初のポイントの情報を元に分割するので、そのような挙動をするのは想像できますが、Catmull Clark曲面の仕組みを考えるとおかしいです。
なぜそうなるのか、謎です。
ある意味画期的です。
つまり、変な実装してるから重いんじゃねーのか、と、これが言いたかった。

それに、サブパッチみたいに、曲面上のポイントをつかんでドラッグしたりということが出来やせん。
既存技術の後追いにもかかわらず、ろくな実装ができない今のLW開発者は、MetaNURBSを開発したFori Owurowa（現pmG）の足元にも及ばないのだろうと思った。

SnapToBGのMinDistance設定時の挙動がおかしい事に、つい最近気づいた自分はその開発者の足元にも及ばないんですがね、げひひ。