Syoyo Fujita's Blog

raytracing monte carlo

Month: October, 2009

no divdi3 in x64 libgcc?

Win64 環境(mingw x64)で LLVM 2.6 をビルドしようとして、
libgcc の奇妙な?構成に気がつきました.

libgcc には、除算器がないハードでも、除算をソフトウェア実現するコードなどがあります.
そこには、たとえば __divdi3 というものがあるのですが、
これがなぜか 64bit libgcc では, object 名は divdi3 なのに、実装の関数は divti3 と、名前が変わっています.

nm で libgcc を調べると、以下のようになります.


_divdi3.o:
...
0000000000000000 T ___divti3

はてなんででしょう?
ちなみに divdi3 は 64bit integer の除算、divti3 は 128bit integer の除算という役割になっています(なっているはず).
なので、divti3 は、object 名も divti3.o にして、divdi3.o には divdi3 の関数を実装するべきだとおもうのですが…

gcc ML にでも聞いてみますかね.

Advertisements

AMD OpenCL beta4 doesn’t run on PC with non-ATI GPU.

ATI StreamSDK 2.0 beta4 がリリースされ、OpenCL が GPU 対応したのですが、
残念なことに今回から OpenCL カーネルを CPU で動かす場合でも ATI のドライバが必要になるらしく、
ATI の GPU が載っていない PC では、CPU 版の OpenCL カーネルを動かすことができなくなりました.
(Vista64 で確認)

OpenCL 対応アプリはビルドできるのですが、実行時に aticalcl.dll という、
ATI のドライバに由来している感じの DLL が無いというエラーが出てしまうようになります.

Note PC のように、GPU を交換できない、でも CPU でとりあえず走らせたいという状況では、ちょっとこれは致命的ですね.
まあ「AMD の」OpenCL ドライバなので、実行環境は AMD 縛りという強制が入ってもいいのですが、
以前の beta ではフツーに CPU モードで動いたので、ちょっと残念です.

py3dsmax

3DS Max には、残念ながら現時点(2010)では python が使えません.
なんとか python で 3DS Max オペレーションの生産性を向上できないかと探したところ,
blur が 3ds max 上に python 環境をのせるための Python プラグイン拡張 py3dsmax を見つけました.

http://code.google.com/p/blur-dev/

オープンソースプロジェクトらしいですが、ここにはコンパイル済みバイナリしかありません.

が、この blur-dev の python プラグインをインストールしてみたのですが、残念ながら max10(x64) では動きません.
どうも mscvp80.dll が見つからないのが原因のようです.

mscvp80.dll(VS2005 のランタイム) は、配布が制限されている dll で、入手するには 「VS2005SP1 再分布モジュール」 をインストールすることなのですが、なんと vista64 環境では VS2005SP1 再分布モジュールはインストーラがうまく動かないのでインストール不可というシロモノ.

-> というわけで、とりあえず msvcp80.dll 依存なくせと blur-dev の issue に登録しておきました.

また、chiyama さんから、blurbeta というサイトを教えてもらいました.

http://www.blur.com/blurbeta.html

この offsite tools installer を使うと、上記 blur-dev のバイナリの元になっているであろうソースが入手でき、 c:\blur に展開されます.
が、こちらはコードが VS2005 + max9 + python25 用らしいので、これもまた max10 + python26 環境ではうまくコンパイルできない.

というわけで、Vista64 + Max10(x64) で動く Py3dsmax は実質無いという状況です.

… ちょっくら blur にでも最新のソース公開してくれませんか、と問い合わせてみますかね.

Investigation of the integration of Maya HyperShade and RenderMan SL

Maya HyperShade と RSL(RenderMan Shading Language) の連携(変換)について模索しています.

結論からいうと、HyperShade と RSL(1.0) の組み合わせは最悪なので、
目標としては lucille shader GUI plugin for Maya + LLL(lucille light transport language)を実現したい.

理由

まず、HyperShade がグラフベースのシェーダ(グラフ指向は、シェーダシステムとしてはよい方向性のデザインだと思う)、
それに対して RSL が手続き型の言語なので、RSL でシェーダグラフを表現するのが非常にめんどくさい.
RSL2.0 を使う手もあるが、RSL2.0 もいろんな意味でアレなので、いっそ RSL2.0 に対応するなら  LLL に対応した方がいい.

また、HyperShade 自体が Maya に限定された機能であること.
Max/Maya/SI にすべてが mental ray が搭載されている今、
次は Max/Maya/SI の シェーダ GUI も mental mill(MetaSL)で統一してきそーな雰囲気がある.
そうなったときのことを考えると、 HyperShade 対応の作業は無駄に終わりそうという懸念がある.

あとは, 3d package soft に依存しない shader GUI が lucille にも欲しい.

現実

とはいえ、「今」を考えると、HyperShade -> RSL 変換は結構自分でもあるとうれしいし、需要もありそうである.

というわけですこし HyperShade I まわり, Maya の shader SDK あたりを調べてみました.

shader SDK

Maya には SDK に 3 種類のシェーダ SDK があるようです.

1. plug-ins

Maya プラグイン全体の SDK. この中でいくつか lambert とか phong とかのシェーダコードサンプルがあります. ただこれは maya plugin 神によれば maya でデフォルトで HyperShade に表示されているものと対応するものではないらしい.

あと、ここにある SDK は HyperShade 上にカスタムシェーダノードを表示させるのにも使われるようです.
MRenderUtil とかの OpenMaya API を使っています(Maya SW render API も使っているのかな?)

2. adskShaderSDK

なんか新しめ? のシェーダ SDK.
内部で mental ray を使うことを想定しています.
(1) に比べると、コードは簡潔かつモダンな感じです.

3. mentalray shader source

maya に標準で付いてくる mental ray shader に対応している感じです(mi base shader とか).
シェーダが、ソース付きであります.

HyperShade 評価

基本的には, python スクリプトで HyperShade のノード情報を自由に取得できるので、
パフォーマンスを気にしなければ python で HyperShade をスキャンしてシェーダグラフ構造作って,
そこから RSL コードを吐く、というステップを踏めば変換完了です.

が、maya plugin 神と一緒にいろいろ調査して、そうウマくはいかないことが分かりました.

– アトリビュートがアニメーションしていたらどうするか?(たとえば lambert.color アトリビュートがキーフレームアニメーションしているなど)

アニメーション値をベイクして, フレーム分の RSL を作る
-> RSL がいっぱいできてしまう. あと複雑な依存があるときにはうまくいかない気がする.

RSL は一つで、アニメーション値はフレームごとに RIB でパラメータで設定する
-> exporter と shader codegen のプログラムの分離ができない(RIB を吐くときに毎フレーム hypershade を評価しなければならなくなるので, export 処理の速度低下がおきてしまう)

– face 単位でテクスチャが貼られていたり、切り替わっているときにどうするか?

– expression がアトリビュートに割り当たっていたらどうするか?

んー、なかなか考えることはいろいろありそうです.

BSON as a next-gen scene file format.

BSON is the binary form of JSON-like document from mongoDB team.

http://www.mongodb.org/display/DOCS/BSON

BSON and JSON are simple and easy to use and modify through Python, C++, etc, thus I think BSON/JSON is a good candidate for a next-gen scene description format.

If you need to handle huge data, you could use C++ BSON binding for speed and storage.

Here’s example python script interacting scene data with BSON and JSON.

Sounds nice?…

If I found BSON(and mongoDB combination) is really nice after more investigations, I might adopt it as a lucille’s scene file format.

PyQt4 in Maya2010(x64 windows) requires 64bit version of PyQt4.

maya_pyqt_integration_thumb.JPG

I can successfully use custom PyQt4 in Maya2010(x64 windows).
Unfortunatelly, PyQt4.6 binary provided by Riverbank’s URL

http://www.riverbankcomputing.co.uk/software/pyqt/download

Doesn’t work in my environment(Maya2010 x64 on Vista64).
Thus I’ve rebuild x64 version of Qt4.5 and PyQt4.6 from source with procedures described in the following blog entry.


http://eoyilmaz.blogspot.com/2009/09/how-to-compile-pyqt4-for-windows-x64.html

[Ja]

PyQt4 を Maya2010(x64 Vista64) で使おうとして、Riverbank のサイトにある PyQt4.6 バイナリを Maya の Python にインストールしたのですが、

「 ‘utf8’ codec can’t decode …」

とエラーで出てうまくいきませんでした.
そこで maya plugin 神の協力のもと、
Qt4.5 と PyQt4.6 をソースからビルドして明示的に x64 版をビルドしたところ、
うまく Maya2010(x64) で動くようになりました.

Maya2010(x64) だと, Python は 2.6 かつ 64bit 版が使われているので、Qt や PyQt も 64bit 版を使わないとうまくうごかないらしいようです.
しかし Qt の Windows 上でのコンパイルはめんどくさかったです.

そんなわけで, コンパイルを省略したい方は, 上記 blog エントリで紹介されている 64bit 版 PyQt4 binary

http://code.google.com/p/pyqt4-win64-binaries/

が, うまく設定を行えば使えるかもしれません. 未確認ですが.

[Paper] Ptex: Per-Face Texture Mapping for Production Rendering

http://www.disneyanimation.com/library/ptex/

遅ればせながら、Ptex を読んでみました.
SDS(サブディビジョンサーフェス)のフェースごとにテクスチャ座標をパラメータ座標で割り当て([faceid, u, v] で識別する)ることで、
UV 割り当ての必要が無くなり、また隣接するフェースの情報も保持することでフェース間でシームのない高品質なテクスチャマッピングを実現する手法です.

利点

– セットアップフリー(UV 割り当ての必要がない)
– フェースごとにテクスチャの解像度を操作できる.
– シームレス(正確にシームレスではなく、シームレスに近い状態にまでできる)

欠点

– モデラ側で Ptex をサポートする必要がある.
– パイプラインが変わる(disney ではうまくいった… なんて言っていますが、他のスタジオでも同様になるか不明?)
– SDS にしかつかえない.

個人的な感想としては、(もしやるなら) Ptex はレンダラ側でサポートするのはそれほど大変ではないけど(さほど複雑な処理をしているわけでないので)、
やはりモデラ側で Ptex の対応をどうするかが大きな問題になるかなぁ、というところです.
(現在某モデリングソフトに Ptex 対応をお願いしているらしいですが)

あとは、フェースごとにテクスチャを割り当てることで、テクスチャファイルの最適化ができるのはよいですね.
普通のポリゴンモデル + テクスチャマップというケースでも、単に UV 全体で mipmap を作るのではなく、
特定の UV 領域で miplevel の調整とかできるようなテクスチャフォーマットを考案するのもいいかもしれないと思いました.
(これはこれで、ペイントソフト側の対応が必要になりますが)

[Cont] 3D composite software

3D(立体視) コンポジットソフトの続き.

NUKE + Ocula

Ocula は基礎的な 3D 編集しかできないらしい.
そのため、
実写 + CG が重なるようなケースでデプスベースの合成とか、
立体視でのレタッチとかが、十分できないらしい.

CEATEC 2009 にて、3D に力を入れた発表をしていた某大手家電の 3D の技術担当と話をしたのですが、
「立体視での実写 + CG の合成はどうしてますか?」
と聞いたら、「んー、人海戦術ですねー。いやー(実写 + CG の立体視デモ作るの)大変でしたよー」なんて答えが返ってきました。
たぶん 1 frame ずつ手作業をしたんじゃないでしょうか…
やはりまだ十分まともな立体視用の 3D コンポジットソフトは無いようです.

Quantel Pablo

立体視コンポジット野郎に聞いたところ、Quantel の Pablo という編集(スタジオ)も、
ある程度立体視編集に対応しているそうです.
ただこれはスタジオになるので使うとなるとハードルが高いですね.
あと、やはり立体視の合成が十分できる機能もないそうです.

NUKE その他

まー、そんなわけで、やっぱり立体視の合成は NUKE + (オレ様プラグイン)しかね?
な結果となったので、ちょっとNUKE の SDK を見てみました.
それなりにきちんとしている感じで、NUKE プラグインは書きやすそう.

あと、NUKER(?) から聞いたのですが、なんか NUKE は遅いらしいとのこと.
Shake と比べて速度が 1/10 とか.
そのためかどうか知りませんが、某スタジオの計算サーバ(数千ノード)の半分は NUKE 用のレンダーサーバに割り当てられているとか…

あと、なんか NUKE 結構バギーです. Windows 版を PLE で遊んでいますが、結構落ちます…

What will happen if realtime raytracing runs on 1P flops computer?

ねんがんの 1P flops コンピュータを てにいれたぞ

ひょんなことから? 1P(ペタ) flops 級の計算機環境を使わせていただけることになりました.
ありがたいことです.

1P flops でリアルタイムレイトレ、リアルタイム G.I. をやったら、どれくらいすごい映像が作れるだろう?
1P flops で lucille のレンダリングをやったら、どれくらい高速にレンダリングできるだろう?

いろいろ妄想は膨らみます…
が、やるなら「こんなレイトレ、はじめて…」みたいな成果を出すことが期待されるので、プレッシャーも同時に感じます.
# 今回も思いましたが、そろそろ本気で、今後の爆発的な(リアルタイム)レイトレ技術者の需要を
# どう解決していくかというのを考えないと感じています.
# レイトレ教育を行い、レイトレ雇用を生み出し、レイトレ報酬を支払い、レイトレ経済圏をどう確立していくか…. 難しい問題ですね.

Realtime raytracing goes mainstrem in the very near future.

日経エレクトロニクス 10 月 5 日号で、リアルタイムレイトレの記事が特集されます.

http://techon.nikkeibp.co.jp/article/HONSHI/20090925/175633/

ゲームや映像制作などのグラフィックス野郎ではない、より一般的なところでもリアルタイムレイトレが注目されようとしています.

最近では NV もレイトレを重要なアプリのひとつにしようとしていますね.
http://www.4gamer.net/games/099/G009929/20091001065/screenshot.html?num=009

(ところで、写真の Physics のところ、fumeFX だよね… もしかして fumeFX の会社を買収したのか?!)

大手が動き始め、一般人も注目してきて… だんだんと(リアルタイム)レイトレの波がやってきているという感じでしょうか.

とはいえ、Intel や NV がバカスカとレイトレにお金を突っ込んだとして、うまくいくかというのはまた別の話.
個人的にはどっちも Winner’s curse(勝者の呪い)に陥るんじゃないかと思います.

リアルタイムレイトレは新しい技術と新しいマーケットですから、ビジネスとして考えたときには、
小さい開発会社や個人でも十分これら大企業と戦える戦場になるだろうと思っています.

まー、とりあえず直近の問題は、とはいえ見た目で判断すると、FPS に見られるようなグラフィックスにはレイトレはまだまだかなわないということ.

一方で、FPS などに見られるグラフィックス表現も半導体性能の向上やラスタライザ表現力が頭打ちなわけで、将来性に疑問が残ります.
実際、NV の PC 向けハイエンド GPU のマーケットはここ数半期赤字で(SEC form 10-K 参照)、
高品位 FPS ゲーム -> ラスタライズグラフィック性能向上というサイクルに陰りが見えています.

Intel や NV は結局は rasterizer グラフィックスの置き換えを狙っているような感じがしますが、
それじゃうまくいかないだろーなー、と思っています.

さて、そうなったときにレイトレが進む道はどこか?

ここはレイトレでしかできない、新しいレイトレグラフィックスマーケットを新しく考えるのがよいと思います.
よく経営的なところでブルーオーシャンとか破壊的イノベーションとか言われているやつですね.

具体的なネタはまあ明かせませんが(competitor が増えると困りますからね 😉 )、
我々レイトレでしかできない、新しいレイトレグラフィックス市場を開拓すべく、いろいろ動き始めています.