第六回 modoユーザーグループTOKYO勉強会

modoユーザーグループTOKYO勉強会に参加してまいりました。今回は大阪から柳村さんと日比さんが講師としてお見えになっていて非常に有益なお話を聞くことができました。今回は残念ながら懇親会には参加できませんでしたが幾つかのポイントをメモとしてブログに書き残しておきます。

まず、柳村さんの「建築モデリングTips」ですが、JWCADから出力したDXFデータをQuantize（量子化）ツールを使用して、誤差を含む頂点座標値を丸めてから作業されている工程が興味深かったです。外部ファイルから取り込んだデータの座標値はmodoとは座標系が異なったり、1.4999999 mなどのように誤差を含んでいる場合があります。Quantizeツールを使うことによってこれらの誤差を含む値を1.5 mのように丸めることが可能になります。

また、素晴らしいと思ったチップスはグリッドスナップを必要に応じて上手に変更して、スライドなどのツールの相対移動量に対するスナップとして使用する手法です。modoにはグリッドスナップツールというツールはありますが、これはあくまで空間上の絶対位置にマウスカーソルを吸着させるためのもので、移動量そのものを0.5 m, 0.75 mのように丸めた値として入力させる目的には向きません。Coordinate RoundingをFixedにすることによって、指定した増分値にツールの入力量を吸着させることが可能です。柳村さんは、この機能を頻繁に切り替えて使用するため画面の右上にグリッドスナップの設定値入力のフィールドを表示していました（通常は初期設定パネルのInput/Unitsにあります）。これはフォーム編集で下記のコマンドを追加してあげることで任意の場所に設定値の入力フィールドを持ってくることができます。追加するフォームの場所は、フォーム編集のFind Formを使ってあげると簡単に見つけることができます。


pref.value opengl.gridSnap ?
pref.value opengl.gridFixed ?

このCoordinate RoundingおよびFixed Incrementの変更は、このワークフローでは重要なのでmodo 701ではスナップパレットで変更できるように工夫してみようかと思います。

次の日比さんの「スムージングについて」の講義は、非常にベーシックかつ重要な内容でポリゴンでCGを表現する場合に避けては通れない問題について解説していただきました。modoを含むポリゴンをベースとしたCGツールでは、面法線ベクトルを何かしらのルールに基づいて補完し、なめらかな曲面のようなレンダリングを行っています。このスムージング処理は、通常はあまり意識することは少ないかもしれませんが、丸めを表現する形状と平坦な平面が隣接するような部分では、平坦な平面のサンプリング法線ベクトルが丸め部分の法線ベクトルとスムージングによって影響を受け、歪んで表示されてしまう場合があります。ボックスのエッジをエッジベベルで丸め処理を行い、丸めていないボックスとリフレクションを付けて比較してみると、本来平坦になっている部分が歪んでレンダリングされているのがわかります。上が普通のボックスで下がエッジベベルでエッジに丸めを付けたものです。

大きな隣接する平面に隣接するエッジベベルによって作られた平面が角度を持っているため、平坦な平面上のレンダリングサンプル点の法線ベクトルはスムージングによってこれらの隣接面の法線ベクトルとで補完された値になっています。これを解決するにはこの中央の平坦な平面に隣接するポリゴンはこの平坦なポリゴンと同じ方向の面法線を持つようにしてあげる方法があります。これによりスムージングしてもサンプリング法線は面法線と一致しますので歪みがなくなります。具体的にはループスライスを使用して平坦な面にエッジを追加してあげることで解決できます。また、hisakoさんから601のRound Edgeレンダリングでも同じ問題があるのかという質問がありました。Round Edgeは、形状レベルで面ポリゴンを生成せず、シャープエッジに対してシェーディングレベルで丸め処理を行うため、スムージングによる問題は発生しません。

法線ベクトルマップを使って、接続部の頂点に別々の法線ベクトルを設定するという方法もありますが、現在modoの法線ベクトルは外部から入力したモデルの法線ベクトルを保持するために使われていますので、自由に編集して使えるほど汎用性がありません。従ってループスライスでループを追加する方法が現実的だと私も思います。この処理はエッジベベルのオプションとして用意されていると便利なのでエッジベベルの機能拡張を検討してみたいと思います（大昔にEnhanced Requestのリストにあった気もするのですが長い間忘れていました）。

また、SDSのサイズに関してのチップスの説明がありました。SDS（サブディビジョンサーフェイス）は、面ポリゴンを繰り返し分割しながらその頂点の座標値をあるアルゴリズムに基づいて移動していきます。ボックスを作った後にDキーを数回押して分割する方法と同じです。このSDSは、面ポリゴンと同じように曲面を扱えるため非常にフレキシブルにモデルを表現する事が可能な便利な表現なのですが、曲面のケージ（元になる面ポリゴン）が、限界曲面（Limited Surface）を包含するように作製されるため、ケージのサイズよりも限界曲面のサイズの方が小さくなってしまいます。これはサブディジョンサーフェイス固有の特徴であり、NURBS曲面などのようにコントロールポイントを通過する曲面表現ではこの問題はありません。

日比さんはこの問題を解決するために多角形ポリゴンの限界曲面の収縮率を実験的に算出しておき、必要に応じて作製したSDSの円に対してスケールを行ってからモデリングをされています。限界曲面上のポイントの位置は、オリジナルのケージポリゴンメッシュの位相とケージ上の頂点情報によって計算されるため、厳密にはリニアにスケールの値は求まりませんが、形状を単純な多角形に限定すれば実用的には十分な結果が得られると思います。この場合のスケール値は、ケージの頂点座標値から求めたバウンディングボックスのサイズを境界曲面上の頂点座標値から求めたバウンディングボックスのサイズで除算してあげれば簡単に求めることができます。この境界曲面上の座標値を求めるAPIはmeshserviceのCornerメソッドを使用して求めることができます。layerserviceには存在しないので機会があればプラグインとして作って見ようと思います。また、境界曲面のサイズをベースとしてプリミティブを作成する機能は、Sphereツールなどにあると便利なので、こちらも機能拡張を検討してみたいと思います。

今回の勉強会はとても勉強になりました。柳村さん、日比さん、ありがとうございました。