3Dソフト Archive

ポリロボ界は若干管轄外なので巡回経路から外れてたんだが、ひょんな事で凄いページにぶち当たった。

造形も凄いんだけど、やってる内容も凄い。

スクリプトをガンガン自作してたり、c++でOpenGLのビュアー作ったり、課題のためにSDK調べてたり、Furを使って髪の毛を………ってあれ？
課題？　え？　学生さん？
SDK？　Fur？　つまりAdvanceユーザー？

学生さん、テラスゴス！！！！！

凄いっす。
なんつーか、格が違います。
モデリングして、スクリプト打って、プログラムも作って、アニメーションまでさせて…
学生の時からこんなに多機能、高性能な人間になってしまったら、しまいにゃどうなってしまうのでしょうか？

ってか、自分の出た経済学部なんざ、こんな面白そうな課題出なかったぞ！
（↑出るわけが無い）

そーいや、学割のadvって幾らだっけか？

製品標準価格

v.5.0 Advanced 教育機関用 日本語版　　　　　　\120,750
v.5.0 Advanced 教育機関用 保守価格（12ヶ月） \80,850

んー、12万で、年8万かぁ。
そんなにムチャな金額じゃないなぁ、良いなぁ。

まぁ、何が言いたいかって言うと、

俺にも FoundationユーザーにもSDKクレ！！！

ってなわけで、キャラ作ってますよ。
いまだに誰を作ろうか確定してないんだけど、オッパイでかくしちゃったから、宇宙人じゃなさそう。
たぶん未来人。

いまんとこ△2370だから、まぁ△4000以内には抑えようかなと。
自キャラは当たり判定をバウンディングボックスでやるので、別に頂点数増えてもいいんだけどね。

テクスチャさ、もう面倒だから、全部レンダーマップでやろうかと。
（↑レタッチソフト使うのが苦手な面倒くさい人）
そうすりゃUV展開もかなーり適当で良いし。
まぁ、最終的にはキッチリ展開させるだろうけど、作業段階では、テクスチャサイズ2048位にして、バシバシベイクしてく予定。

ってなわけで、早速ベイク。

ウヒョー、ムダだらけｗｗｗｗｗｗｗｗｗｗｗｗ
まぁ、今日はアタリ付けるだけだし良いでしょ。

んじゃ、さっそくエクスポートと…

あれ？

なんですかこれ？　UV壊れてますよ？

昨日褒めた途端にこれだよ…

それから３時間あまりの時間が原因調査に費やされた。
出力オプションを弄ってみたり、UVプロジェクションの設定を弄ってみたり。
標準のモデルデータにテクスチャ貼ってテストしたり、吐き出されたファイルを解析したり。

そして、ついに判明した。

こうやると上手く行く！＞＿＜／

しかも、このエクスポーター、X軸反転させやがるという新たな事実も判明。

…もうね、なんつーか、さすがはDirectX。
そこにしびれるあこがれるぅ。

そんなこんなで……

テクスチャのムダこそあれ、UV自動展開である程度のテクスチャリングができるのは判った。
あとは、素体をFixして、それとは別にハイポリモデルでディティール詰めてサクっと焼き付ければOKだ。
UV展開はその時でいいや…。

最悪やらんでも良いや…。
（ローポリ界からは、冷ややかなコメントが来そうだな…）

.x ファイルは、長年に渡りDirectX入門者の野望を砕いて来た。
異論はあるにせよ、一般的には「X Fileは使うな！」が通説であり、「スキニングメッシュアニメーションのXファイルはどうやって作るのですか？」という質問は、少なくともプログラム板界隈ではかなり忌み嫌われる質問のひとつである。
この種の問答は、最終的に「モーションやるなら自腹の独自フォーマットでやれ」と、質問者の望む結論を得られぬまま、幕を閉じる事になる。

しかし、仮にも、SDKに付いているMeshViewerで読み込めるXファイルの何と少ないことか。

X Fileは（内容が）柔軟すぎる故に、出力側が対応しきれない。
そして、高速化や独自仕様のため、結局独自のパーサーを書かざるを得なくなり、「だったら独自形式でいいじゃん！」ってな具合に。
（意味ねー ＞＜）

各3Dツールとも、X Fileのエクスポートに関しては何処も同じだろうと思う。
ガチのハードコーディングなら、MayaのFBXやdotXSIのような物や、どうなるんだか判らないCOLLADAを使った法が色々便利だとは思う。
でも、まぁ、とりあえず手軽にやろうと思ったら、x fileが、楽って言や楽だわな。

XSIの場合

まぁ、いろいろ不都合があるにせよ、出力データの機能を絞って行けば、特に問題は無い。
一応、第一感として、メモを残しておく。

まず、標準のリグを使うと、MeshViewerの管轄をいきなり超える。
（具体的には、腰から上への親子関係が特殊になる）
古風だが、手堅く全部ボーンでやるのが無難。
まぁ、標準モデルのスケルトンは、FK/IKの各種設定がそこそこできてるので、それを使うのがよさげ。
（自腹スケルトンでも、変な事やってなければ多分OK）

モデル（なんとなく女性）出したら、”スケルトン-女性-基本”で出して、間接位置を合わせる。
設定済んだらエンベローブ設定して、必要ならウェイト調整。
この時、あんまし複数のボーンとミキシングしないほうが色々と平和。

設定済んだらモーション付け。
余分なヌルを消して、IKで動かすヌルの形状をBOXにしとくと良い。
メタセコ的に言えば、Mikotoの操作感覚に近い

出力オプション

モーション付けたら、フレーム調整して、出力する。
個々のパラメータは色々と深い意味があるんだけど、アプリ側の実装に依存するので、ここではMeshViewerで見れる設定をSSに撮ってみた。

ファイル名は適当に。
ファイルタイプはテキスト形式が無難。
バイナリはなんか非常に安定しないケースが多いので、独自実装の時以外はオススメしない。

FrameOffsetが１になってるけど、このままだと多分100倍速くらいで動くので数値は上げておいたほうがいいかも。

TypeはSRT (Scale, Rotate, Translate)かMatrixKeyだけど、これはお好みで（実装次第）
三角形化もお好み。
ExportHiddenObject(隠しているオブジェクトも出力する)は、以外にもチェックを外すと上手く動作しない事が多い。
CompressMeshは、共有頂点をファン等の連続したメッシュにするためのチェックらしい。

テクスチャ関連は、割と使い勝手が良く感じた。

無理は禁物

ってなわけで、一応出して、動かす所までは持っていけた。

６月末はまるまる１週間マップ作成してたけど、ちょっと飽きたので、来週はキャラ作成週間にしようかと。
とりあえず、明日の夜中26:00までは様子見ですが…。

NormalMapとベイキングフル活用のローポリモデリング

Softimage Tutorial Bankの
“Low Polygon Technique for Next Generation Systems”
(PDF 2.3MBと書いてあるけど、実は10MB)

ネタ元は、2chローポリスレ。

やっぱ、NormalMap実装しようかなぁ…。

わーい。
おねだりした光源方向の取得関数実装してもらったぜ　ヽ(´ー｀)ノ

Stationプラグインに関して

なんかまだ変更ありそうな予感。
こういうのは、外野がどーのこーの言っても始まらないので、もう暫く静観。
まぁ、リリース後、多少問題あっても、適当に回避できればそれでよし。（←アバウトすぎ）
それに、自分はUI系の拡張プラグインは管轄外だしな。

UV PowerToolの人は、Stationベースにすると色々と変更大変かも。

その他

・UniqueFaceID / UniqueVertexID
ありそうで無かった値。
モーフターゲット作るとき、ドキドキしなくて良いと言えば良い。（そういうプログラムを書けばの話だけど・・・）

・OBJ出力でmtllib
ありそうで無かったファイル。
なんだかんだでobj使う事も多いので、良いのではなかろうか。
まぁ実装次第だけど・・・。

前回書いた記事の事例をSAKANA-Yaさんが実際にレンダリングして頂いたようなのですが、ちょっとトラブルが。

全透明のサーフェイスが、片面ポリゴンの裏面を通過したとき、例外的なα値が設定され、結果として、このレンダーツリーでは誤動作します。

でも、まぁ解決法は簡単で
「キャラの背面に背景画像用のビルボードを立てておけば良い」

どーしても、ビルボード無しで解決したい人は、ポリゴン面が閉じた状態にすればOKです。
（上の画像で言う、青いエッジの部分を無くす）

それも嫌だって人は、カスタマイズで。
たとえばこんなやり方。

SAKANA-Yaさんとこのコメントでは「スイッチ」⇒「裏 -表」 　（英: switch⇒front back）をすすめしたけど、こっちの方がわかり易いかも。

これでバッチリ！(｀･ω･´) ｼｬｷｰﾝと思ってたら

眉毛消えてて(´･ω･`)ｼｮﾎﾞｰﾝ

まぁ、直接の原因判ってるし、どうでもいいや…。

6/23　追記

「カラーブーリアン」とか適当な事言ってたけど、”Color Math Logic”ってヤツです。

基本的にはカラー２つを入力して、結果に応じ、TRUE or FALSE (XSIだと1or0か？)が返ります。

自分のテクスチャだと、眉毛の黒が(0,0,0)の完全な黒なので、華麗に消えました。
(1,1,1)とかの黒なら、多分上手くいくとおもいます。

前回の記事の最後では、ToonInkの「しきい値」の「方向」を使用したときの問題点が浮き彫りになりました。

しかし、これは一体どういう原理で、発生しているのでしょうか？
今回はこれを解明したいと思います。

いきなり免責

さて今回の記事に関してですが、実は裏付けが取れていません。＞＜
つまり、以下の文章は自分の経験と、検証結果から導き出した推論に過ぎません。

この記事を信用するかどうかはお任せしますが、信じた結果、それが間違いであったとしても、当方はなんら関知しませんので、あらかじめそのつもりでお願いします。

XSI-Toonのインキングアプローチ

繰り返しになりますが、以下の文章は推論です。
Toon関連の論文を軽く読んでみて、あながち的外れな推論ではないとは思ってますが、その辺は一つよろしくお願いします。

さて、この記事で、ちょっとだけ触れましたが、XSIのToonInkは、モンテカルロ法のようなアプローチを行っているようです。
（ちょっと判りにくい人は、モンテカルロ法で円周率を求めるやり方解説したページが多数あるので、それを読むと感じが掴めるかと思います。）

レンダリングの際、レイトレーサーはポリゴンとの交点が算出します。
インク処理は、その後に、交点周辺の狭い範囲にいくつかのサンプリングレイを飛ばし、周辺の情報を集めます。
各交点の情報に何らかの”差異”が生じている場合、その結果に応じて線を描画するかどうかを確率的に決定します。

上記の説明図に関して言えば、青線と赤線の割合は半分くらいですので、この領域に輪郭線が「ありそうな感じ」がします。
あとは敷居値や、レイの放射角度、サンプリングレイの数等のパラメータ設定に応じ、輪郭線の有無を決定し描画を行います。
その結果、線がハッキリするかもしれないし、ウヤムヤになったりもします。

とまぁ、こんな事を、各レンダリングピクセル毎にチェックしていくわけです。

図は結果イメージ（笑）なので、正確ではありませんが、まぁ「イメージ」だし、伝わればいいでしょう。

この図では、輪郭線の描画のアルゴリズムイメージですが、例えば、マテリアル間にエッジを引く場合や、角度の敷居値でエッジングをする場合も同じです。

各サンプリング点で、マテリアルの異なるポイントが検出されれば、線を引く。
各サンプリング点で、法泉角度差が敷居値を超えたら、線を引く。

評価するモノは違えど、「サンプリングして、差が出てたら描く」これの繰り返しです。

まぁ、この「評価」ってのがクセモノで、凄まじく量が多い上に、相互間で重複を許しています。
思いつく限りでざっと、あげると
　・法線角度が異なる
　・マテリアルが異なる
　・オブジェクトが異なる
　・距離が離れすぎている
　・環境カラーに接している
　・継ぎ目のグループが異なる
　・継ぎ目の非ブレンドグループが異なる
　・ファセットが設定され、ポリゴンをまたいでいる
なんとまぁ、これだけの量（多分もう何種類かあるはず）の差異をチェックして、全てにON/OFFの設定があり、そのうち一つでも「有る」と判定されたら、線が引かれてしまうのです。

高機能と言うべきか、やり過ぎと言うべきか… orz

ともあれ、以上が標準搭載のToon Inkのアルゴリズムの推論となります

エッジ検出の限界点

さて、何度も言ってますが、Toon Ink Lensのプロパティで弄れるエッジ検出には問題があります。
大雑把にまとめると、
　・三角ポリゴンに分割し判定する
　・エッジ以外の場所には線が引かれない
が問題になります。

前回の記事の最後では、エッジ検出の敷居値を限りなく0に近づけましたが、結果は三角形のワイヤーフレームが現れました。
ピクセル単位でエッジ検出を行い、しきい値が0に近ければ、本来、面全体が真っ黒くなるはずです。

しかし、どんなに頑張って角度設定を弄っても、
ポリゴンエッジ以外の場所に自由な線を引く事はできないのです。

とはいえ、回避策は幾つか考えられます。
一番簡単なのは、サブディビジョンレベルを何段階も上げて、エッジの濃度を上げてしまえば良いのです。
こうすれば、ミクロレベルではギザギザになるものの、普通のサイズでは十分な解像度が得られます。

もう一つは、ToonHostのブレンドグループをレンダーツリーに繋ぎ、ピクセル単位でのToonInk制御を行う方法です。
この手法に関しては長くなるので、また後日に解説をしようかと思います。

まとめ

境界線の描画はかなり安定しているXSI-Toonですが、面の起伏を検知する機能に関しては、なかなか運用が難しいです。
（まぁ、この辺りはどのToonエンジンでも、お家事情は同じかと思いますが）

ここまでの説明を聞いた上で、どーーーーーーーーーーーーーしても、ポリゴンエッジ以外の部分に自由なToonInkを引きたい方は、また次回にでも。

ディスプレイスメントマップのDownload

どういうツール？

こういうツール。
説明画像が全てなんで、後は勢いで使ってください。

自分で使うため用に作ったツールですが、一応汎用的なモノではあるので公開しときます。

今後とか

これに関しては、もう更新しないと思います。
（自分に必要なデータは作れてしまったので）

念のため免責

このソフトを使用して何らかの損害があったとしても、当方では一切責任を負いませんので、ご了承下さい。

ちょっとワケありで、XSI Mod Toolを触ってみた。

製品版との違い

基本的にはXSI 4.2 foundationとほとんど同じ。
むしろ、上に幾つかのコントロールが付いている分、インターフェイスは4.2fndの標準より豪華。

会社のPC(MatroxG450)でテストしたんで、RTS描画は壊滅状態…

機能面では、MentalRayの書き出しの制限と、エクスポートがdotXSIのみって点以外は、ほぼ4.2fndフルスペック。
でもインポートはobjやら、xやら色々出来るという大盤振る舞い。（しかも、多分addonで拡張できる）

リグも、クロースも、ソフトボディも、パーティクルも、Toonも、OpenGLリアルタイムシェーダーも何でもあり。
しかもdotXSIはフォーマット公開されてるワケで、ゲーム関連だったら何でも出来そうな勢いだ。
（やる気と技術さえあれば）

ただ、MentalRayに限らず、リアルタイムシェーダー等を使っても、ビュー上にウォーターマークが入るのがネック。
（良く見ると、冒頭のリアルタイムシェーダーの画面にもウォーターマークが入ってるのが判ると思う）

レンダリングは（多分）リージョンレンダリングのみで、サイズは512×512まで。
連番でのレンダリングは出来ないっぽいので、プレビュー的にしか使えないと思う。

MentalRayを使用すると、左下に、お馴染みのマークが記載され、ウォーターマークも入る。

レンダマップでテクスチャの焼付けも可能っていや可能だけど、テクスチャにもMentalRayのロゴが入った。

感想

全く弄った事なかったんだけど、凄いなこりゃ。
ちょっとdotXSIの研究のためインスコしてみたんだけど、モデリングからリグ入れてアニメーション付けるだけならFoundationすらいらねーじゃんって感じ。
まぁ、Viewポートのウォーターマークが超邪魔だけど…。
（それでもワイヤーフレームで作業をする分には全く見えない）

ラインナップ的にはＭＡＹＡのＰＬＥに近いのか？

かなりビックリした。

前回の解説で、線の品質と、太さを変える方法は解説しました。
次は、表示のON/OFFの制御です。
（テーパー、圧力、多様性なんて飾りですよ。　お偉い人にはそれが分からんのです）

なかなかややこしい問題を含んでいるので、順番に整理していってください。

基本の外観

ではToon Ink Lensタブの１つ目、「基本の外観」からいきます。

まずは「バイパス」
これをチェックすると、全てのToon Ink Lens関連エフェクトが消失します。
(ToonPaintは管轄外なので何も変化しません)

「インクのみ」は、Toon Paintの結果を無視します。
今回はインクの解説なので、これは要らない子です。

「カラー」は、インクカラーで、ToonHostで個別に設定されない限り、この色で線が塗りつぶされます。
「合成」は、その色と下地を塗りつぶす際の合成モード。
「スプレッド」は前回説明したとおり、線の太さです。

多分ここまでは、全く難しくないので、サクっと次に行きましょう。

サンプリング

選択的に線のON/OFFを制御するにあたり重要な設定がこの「サンプリング」タブです。
有る意味、この制御がToonInkの心臓部です。

「サンプル」ですが、これは前回解説しました。
画質を決定する、重要なパラメータです。
なお、サンプルを０にしても、線は描画されなくなります。

「トレース深度」は、反射屈折を伴った場合、ToonInkを何処まで追跡するかの深度です。
まぁ、普通のレイトレース深度と同じようなモノですので、感じは掴めるかと思います。
不要なら、低い値にすると、パフォーマンスが向上するそうです。

「環境」「マテリアル」「オブジェクト」は、境界検出のオプションです。
チェックが入っていると、その部分に対してのInk描写を許可します。
説明すると難しいので、画像で比較してみてください。

球とグリッドが別オブジェクト、①の青と、②の赤が別のマテリアルです。
大抵の場合、全部ONでもOKですが、状況によってやむを得ず切らなくてはならない事が発生します。

ホストマテリアルの「ペイント」「透明度」「シャドウ」は、ToonPaintを使用した面にのみ有効なオプションです。
ToonPaintで塗り分けられた領域の境界に線が引かれます。
個人的にはToonPaintは使いにくいのであまり弄る機会のないオプションですが、透明体を貫通した時のみえInkを描画したい時などは、使う機会もあるかもしれません。

ちなみに、透明度とシャドウはともかく、ペイントはちょっと使いにくいです。

というのは、普通に使ってしまうと、ハイライト、ディフューズ、リムライト等、全てのToonPaintエフェクトの境界線に線が引かれてしまい、例えば、ハイライトの周囲にだけ輪郭線を付けるといった選択権が無いからです。
また、ToonPaintにグラデーションを掛けると、変な場所に線を引っ張ります。

「ファセット」は、言わばワイヤーフレームレンダリングのようなものです。
「同一平面をマージ」すると、法線が同じの面同士の内部は輪郭線を描画しなくなります。

「ワイヤーフレームをレンダリングしたい」という質問は、割とFAQっぽいようですが、この機能を使うのが一つの解決法です。

最後に残った「しきい値」ですが、これが少々厄介なシロモノです。
別項を設けて説明します。

しきい値

「方向」と言うと漠然としてますが、隣接するピクセルと法線差異があった場合、そのくらいの角度差までを境界線とするかの値です。

例えば、正方形の面と面の間の角度は90度です。
試しに、しきい値を91にしてみると…

こんな感じで、エッジが消失します。

「距離」の方はというと、境界とみなす高さの差の最小値です。
（単位はSoftimage単位）

画像を見ればわかると思いますが、しきい値が1.0の時と2.0の時で、中の部分の輪郭線に差が出ます。

①と②のZ軸方向の差は1.0ですが、カメラの向きを考えると、実際には√3=1.732くらいの落差があると思います。（正確に測ったわけじゃないけど…）
つまり落差が設定値を下回れば境界とは見なさず、輪郭を描かないというわけです。

「方向」と「距離」の良くある利用法は、鼻の線なんかでしょうか。

こんな感じで「方向」をある程度浅めに取っておけば、なんとなく、鼻の線が出ます。
ただ、これはポリゴンの形状にもよるので、綺麗な線が出るかは状況によりけりです。
また、ある場所だけにエッジを立てたいのに、「方向」が緩くなると出てほしく無い場所にまで、エッジが立ってしまう事もあります。
（この例だと、耳の線と、前髪の一部に異常が…）

しかも、「しきい値」によるエッジ検出には重大な欠点があるのです。
例えば鼻頭の線を出すために、しきい値をどんどんゆるくしていくと………

工工工ｴｴｴｪｪｪ（´д｀）ｪｪｪｴｴｴ工工工

待て次号！

まとめ

最後はややショッキングな画像で締めくくりましたが、角度によるエッジ検出は非常に制御が難しいです。

しかし、線を描いている筈なのに、何故メッシュのエッジが出てしまうのでしょうか？
これに関しては、また次回に。
（実は記事自体はもう書きあがってるんだけど、解説図とか色々必要で…）