日々適当

これ、Closest LocationのNormalを軸にして、Nullの方向にパーティクルを回転しているってものですけど、それの基礎になるコンパウンドを組んでみました。何となく車輪の再発明のような気がするんですけど、該当するものが見つけられなかったので…

Projection on Plane

こいつを、以下のようなツリーに組み込んでいます。

入力が Normal , Point on Plane , Prj Src の三つ。出力が Result ひとつですけど、意味としては、Point on Plane という点を含み、法線が Normal の平面に、Prj Srcの点を正射影した点の位置が Result に出てくる、というものです。

コンパウンドの中身は、まぁ愚直なもんでして…w、処理、遅いかもww

トポロジーが同じなら、単純にハードエッジになっているエッジのインデックスをとってきて、それを元に目的のオブジェクトに ApplyOpでハードエッジにしたればいいんだろうね。

このやり方だと速度が遅いのは想像に難くないけど…(^^;

from win32com.client import constants as c

app = Application
log = app.Logmessage

oObj = app.Selection(0)
if oObj.Type == "polymsh":
	oPicked = app.PickElement(c.siGeometryFilter, "pick poly obj", "pick poly obj" ,"","","2" )
	tgtObj = oPicked(2)

	oEdges = oObj.ActivePrimitive.Geometry.Edges
	oHEdgeArray = []

	for oEdge in oEdges:
		if oEdge.IsHard:
			oHEdgeArray.append(oEdge.Index)

	app.ApplyOp("MarkHardEdgeVertex", tgtObj.FullName + ".edge" + str(oHEdgeArray) , 3, "siPersistentOperation", "", 0)

でもたぶんこんな単純な話じゃないんだろうなぁ…。
あと、こんな話だとしてももうちょっとスマートな方法はどう書くべきなんだろう。

基礎研究っていうか、メモというか。
Softimageのシェーダに Point Cloud Lookup ってのがあります。
これ"Procedural image sampling" [Vimeo] なんかで使われていると思われるTexture instancing Shader（rray.deにて"Texture Instancing"で検索すると見つかります）内の肝となるシェーダだと思うんですけど、それの使い方の本当に基本的なところのメモです。

このシェーダは、マテリアルを共有するポイントクラウドから、ポイントのベクトル系のアトリビュートを取得できるという物という理解でいいのかな？（なんか間違っているような気もするけど…）。ポイントクラウドと実際にマテリアルの設定をしたいオブジェクトのマテリアルが同じであることが大切
なもんで、以下のようなシーンで



グリッドからパーティクルを発生させて



それで以下のようなレンダーツリーを設定すると

何となくボロノイ的な感じで領域が分割されたようなイメージでテクスチャを並べることが出来ました。



たぶん、レンダリング時、ジオメトリにレイがヒットすると、そのヒットした位置から一番近い位置のPointCloudのポイントの位置を Point Cloud Lookupシェーダが返しているのだと思います。だから、ポイントの位置とレイがヒットした位置の差分をとって、それを0～1の範囲の収まるように整形してやれば、こんな感じの結果を得ることが出来るのでしょう。

Point Cloud Lookup の IN で PointPosition を指定しているのは、Vector State からの入力に一番近い位置にあるポイントを取得するためですな。で、Outではこの例では PointPosition を指定しているけど、取得したポイントのもつベクトル値のアトリビュートを任意に指定可能のはずなので、ここから何か別の効果を狙うことも出来ましょう。

少し、有用な結果を得ることが出来ましたですよ。

メモ。
下図のように、文字を押し出したオブジェクトがあり、その前面（背面）と側面の質感を分けたい場合、その手法はいくつか考えられると思います。UVを設定したり、ポリゴンクラスタを設定してマテリアルをわけたり。



で、オブジェクトの法線に注目すると、前面にはXとY方向は0が、側面はXもしくはYに必ず0以外の値が入っていると考えることが出来ると思います。そんなわけで考えてみたのが以下のマテリアルです。



ジオメトリの法線のX方向もしくはY方向に0以外の値が入っている所と、どちらも0である所で質感を分ける設定になっています。
ここ、0以外の値が入っているところを調べるべく、Scalar Logicノードを使っているのですけど、これ、ICEの比較のためのノードのように、精度を指定することって出来ないんですかね。ICEだと、input = 0 って比較をするとき、精度を0.001とかにしておくと、-0.001～0.001の範囲の入力については0と一致していると返してくれます。
それがScalar Logicには無いようなんで、上図ツリーのようにちょっと面倒くさい組み方になっている次第。

Clone Pointノードはソースとなるポイントの複製を作成するノードです。つまり、Strandが設定されたポイントがソースの場合、Strandも複製されます。
それじゃ、例えば下図のようなツリーを組んだ場合を考えます。



Add Pointで 原点に発生させたポイントに Create Strands コンパウンドを使ってStrandを発生させます。それをソースにクローンポイントを作ります。
複製されたポイントを例えば別の位置に持っていきたいとかする場合は、複製された直後、Clone PointノードのOn Creationポートで複製されたポイントの各属性をオーバーライドしておきます。
んで、とりあえず、複製されたポイントの位置を、複製元のポイントのStrandPositionのうちの一点に指定しています（3番目の要素の値を指定）。

さて、こうした時、複製されたポイントも当然Strandを持っているわけですが、そいつのStrandPositionはどんな値を持っているでしょうか。



数値を表示していますけど、この数値は複製されたポイントの持つStrandPositionです。複製元のStrandPositionと全く同じ値を示しています。しかして、PointPositionは複製元のStrandPositionの3番目の要素で、この場合、（0, 3, 0）の位置になります。つまり、複製されたポイントのStrandは、(0, 3, 0）から引かれはじめ、いったん（0, 1, 0）まで下って（0, 2, 0）, (0, 3, 0) ..と上っていくような線が引かれることになります。

要するに何を言いたいかといいますと、Strandを使って枝分かれしたような構造を作成する際、Clone PointでStrand付きのポイントを複製して作ろうとするなら、StrandPositionの値をオーバーライドしてやらないと、多くの場合，上手くつくれないわけですよ。とても面倒くさい。面倒くさいけど、この辺の面度を見てやることで、何となく樹っぽい構造をつくってみております。



何となくそれっぽくなってきたけど、まだまだいろいろケアしてやらないといけない要素がありそうですな。

限定的な話だけど、単純にオブジェクトの高さ方向でグラデーションをつけたいんだよって時。普通はXYで投影したUVを作成して、グラディエントのシェーダをあててやればいいですがね。



この図の左側にはTexture Supportが存在し、そいつをガイドにUVが作成され、



こーいうシンプルなマテリアル設定で行けるわけです。
んじゃ、UVをつくらない場合どうしようかとなると、この場合、単純にオブジェクトのY方向でいいので、Processing→Mixars→Gradientなシェーダを利用して、例えばこんな風に書けます。



ただし、mentalray単体でオブジェクトのバウンディングボックスを取得する方法を僕は知らないので、ICEでオブジェクトのバウンディングボックスのYの最大値と最小値をカスタムアトリビュートに持たせて、それを取得しています（Scalar Change Rangeノードに繋がっている二つの箱がそう）。ICE Treeはこんな感じ。



もっとも、この方法だと、オブジェクトが回転していたりすると都合が悪いわけです。下図は、オブジェクトをX軸で-60度回転した物。




本当は左側と同じになってほしい右側なのだけど、模様もきっちり回ってしまっています。
というわけで、この回転をrendertree内でキャンセルする方法が分からないので、ICEでトランスフォームの値をカスタムアトリビュートに保持します。



でもって、それを元にRendertree内で座標変換してたぶん完成。



非常に面倒くさいです。



と思ったけど、これでも問題があって、バウンディングボックスの最大値と最小値の値がローカルのYの値を拾ってきてしまっているため、これをグローバル値からのものにしておく必用があります。



今度は大丈夫だろと思うんだけど、どうなんだろ…(^^;

Softimage 2014 の俺的に非常に価値あるアップデートを確認できました。
Unfold に、既存のテクスチャプロジェクションにたいしてパックする機能が追加されています。



こんな感じでワンメッシュでUVがかぶりまくっている場合です。そうした時、テクスチャエディタのツールメニューから Unfold/Pack を選びます。



そうすると、UnfoldのPPGが開くわけですが、ここでパックを実行すると、



素晴らしい。並べ直されました。
個人的なワークフローとして、このようにどんな形でもいいからとにかくきれいに並べてほしいって時に、modoにオブジェクトを持ち込んで同様の処理を行っていたのですけど、Softimage内でこの処理は完結できるかもしれません。
地味～な内容の変化しか行われていませんけど、地味～に作業効率にいい影響があるアップデート内容は、他にも何かありますかねー。
（バグが少なくなってより安定して動く、ってものぐらいかもしれないけどねー）

この図のような物をポリゴンごとにポリゴンの法線方向に押し出して、押し出しつつスケーリングしたい時。ICEには Extrude Polygon Island ってノードが存在します。
押し出したいポリゴンのインデックスを与えるわけですけど、問題は、押し出し量の指定する値が、トランスフォームであることなんすね。



こんな感じで、行列で指定することになります。だから、SRT to Matrix ノードを使って、移動とスケールを行列に変換して指定してやる事を思いつくわけですが、事はそう簡単ではありません。



このツリーは単純にスケールと移動をインデックス0のポリゴンに対し指定した物ですけど、結果はこんな↓風になります。



まぁ、意図した形じゃないのはすぐに分かると思います。移動はともかく、スケールが問題なんです。スケールの値を指定したとして、そのスケールのセンターはどこって話でしてね。
ってことで、こんな手順で指定してやりました、というやり方です。これであってんのかねぇ？

まずは位置をゼロにしてやります。その上で、

スケールしてやります。あ、図のノードが繋がってない。要するに行列のかけ算をしているわけっすね。
そしたら、位置を元に戻してやります。

んで、押し出したい方向の移動をしてやればよろしい。

いわゆる「変換」の考え方としてはあんまり間違っていないとは思うんですけど、ICE的にこのの考え方はあっているのかな？

よく出来たフェイクかもしれないけどねー。

2014ってバージョン12にあたるんですね。

New Features ですよ。インストール時の項目選択でマッチムーブやコンポジットのインストールオプションがドロップダウンリストの中に含まれるようになったとか、それは機能か？
32bit OSが切られました。これは特に問題ありません。Windows 7と8とFedora 14だそうですけど、ほぉ、Fedroaは14ですか。Linux版でスタンドアロンライセンスを選べるようになったそうです。これまで選べなかったのですね。日本でLinux版が正式に販売されていなかった理由はこの辺でしょうか？

というわけで、新機能と呼ぶにやぶさかではない内容が以下に続いています。
でもまぁ地味ですね。地味な機能強化に終始しているように見えます。
地味ながら有用なアップデート内容っぽいものがありますね。シーンやモデルファイルのサイズの制限が外されたみたいです。これまでその制限にあたった事が無かったので実感ありませんが。Windowsなら4GB以上、Linuxなら2GB以上のファイルの保存が可能になったそうで。

他のプラットホームのプラグインとして動作するSoftimageですから、FBXの強化の当然行われています。基本的なコンストレイントがサポートされるよう尾になったり、Nullをモデルとして読み込んだり？FBX 2014.0.1 も当然サポートされてきています。これでmayaとの連携もばっちりだね。

ICEはCrowd周りの強化が少し行われている印象。より簡易に使えるようになりました的なものとか機能強化もちょっとって感じかな。
Syflexも入力ポートがちょっと増えたみたいですね。制御の幅が若干広がるでしょう。
Bullet Rigid BodiesではCUDAがサポートされたみたいですよ。BulletってどちらかというとAMDよりな気がしていたんですけどね。OpenCL利用とかは来ませんか？（FireGL対応とかさ。いや、利用予定は全くないけど）。

個人的に一番大きそうに思うのはテクスチャリングの新機能でしょうか。Unfoldのパッキングが既存のUV テクスチャプロジェクションに対して利用できるようになった、ように見えます。これが考えている通りの機能だとしたら、相当作業効率があがりますよ。

レンダリング関係ではHigh Quality Viewportが強化されているようで、これは常用できるぐらいの内容になったんでしょうかね。たぶんあんまり使わないと思うけど。
OpenEXRでは圧縮モードを選べるようになったようです。でも、FxTreeを介した時だけみたいですね。レイヤーのサポートはまだですか？
mentalrayは3.11にあがり、その新機能なんですかね？、AOをGPUで計算するモードがアクティブになるそうですよ。CUDA 4.2以上でサポートされるそうです。

ここに書いた内容以外にもいくつか書かれていますけど、まぁ、こまごまとしていますね。ワークフローを一変するような、あるいは新たな表現を簡易に実現するようなブレイクスルーを期待するものは特に含まれていない印象です。

mayaやmaxはどれぐらい強化されるんでしょうね？

こんなICE Treeでカーブからストランドを作成してみたり。

この場合、Strandの属性でStrandDeformがTrueにすると、ストランドにそってParticleのShapeが変形し連続した形状にしてくれるみたいです。
ただ、不自然にねじれる事があります。



このねじれをどうにか出来ないかと考えるとき、StrandUpVectorって属性とかStrandOrientationって属性に目がいきます。
StrandOrientationはストランドのタンジェントにそって回転させる事が出来るので、これを使ってもねじれ解消が出来そうなんですけど、どのみち、UpVector的な考え方は必要になりそうです。
しかし、StrandUpVectorが動いてくれないんですよね。

何で？って思ったのですけど、試してみた感じだと、どうも、まずはPointUpVectorを設定してやらないといけないみたいです。

んで、この場合、Nullの位置を入れてやったのですけど、こんな形状の場合はこれだけでねじれが解消されそうです。



また、これを設定する事で、StrandUpVectorへの値の入力も反映されてくるみたいなので、さらに細かく制御をしたい時には、StrandOrientationとStrandUpVectorの値をいじりまくれば良さそうですね。具体的にどう実装するかはともかく、そんな事を思いました。