Youngest Prof. nyaxt recieves “incredible creator” title

[En] Prof. nyaxt is honored as “incredible creator” by Exploratory Software Project sponsored by IPA [1], with his physically-based and unified renerer “nytr”, http://nyaxtstep.com/projects/nytr In Exploratory Software Project, very few people is titled as valuable “incredible creator” for their extraordinary talent. And more surprisingly, nyaxt is the youngest “incredible creater” ever since Exploratory Software ProjectContinue reading “Youngest Prof. nyaxt recieves “incredible creator” title”

I’m now Tumblelogging

[En] I just started my Tumblr at http://lucillerender.tumblr.com/ Scraps, small infos, quotes and more on small thing about developing my lucille renderer is now found there, not at this blog. [Ja] ただでさえ内容の品質が低いこの開発日記ですが、 最近は数行でリンクを紹介するだけの情報創造 [1] にほとんど貢献しない しょーもないエントリも増えてしまい、もっと品質を落としてしまっています。 読んでいただいている方に申し訳なく思います。 とはいえ、自分の備忘録も兼ねて、いくらかは記録をとっておきたい。 日記の品質を落とさず必要そうなネタはとっておきたい。 どうしたらよいかと思っていたら、ちょうど Tumblr(たんぶらー) という良さげなツールを見つけました。 使い方は [2, 3] などを参照。 というわけで、これからは小さなネタ、ニュースとか web スクラップとかは Tumblr のほうに tumblelogging して、それをかもした(?)ものをこちらの日記に書いていきたいと思います。 [1] 貨幣の信用創造の情報版Continue reading “I’m now Tumblelogging”

統計科学のすすめ[その2]

統計科学のすすめ[その2] http://www.nippyo.co.jp/maga_susemi/ss0711.htm [En] “Math seminer” is a math magazine published in Japan. In the issue of this month, the manazine features cutting edge statistical science, which is much valuable for thinking MCMC based rendering for the next of MLT. [Ja] たまたま本屋で見かけて、統計科学について特集していたのでおぉっと思いつつ手に取ってみると、 予想通り? 伊庭先生がトップで解説していたので早速購入。 (「その1」 は残念ながら知らなかった。バックナンバーを図書館で探してみよう) 「これからは統計学も個性を重視しなければいけない」 うーむ、なるほど。基本的にはグローバルなパラメータでモデリングするんじゃなくて、 ローカルなパラメータでモデリングできるようにしよう、でもあまりローカルすぎるのも だめだよ、と私は理解してみました。 spherical harmonics は global support だけど、waveletContinue reading “統計科学のすすめ[その2]”

独りで始める Concrete and Specific Programming(CSP)

独りで始める Concrete and Specific Programming(CSP) http://madscientist.jp/~ikegami/diary/20070822.html#p01 このエントリでは、開発側の夢を実現するためのプログラミング技術 Concrete and Specific Programming を提唱します。 Concrete and Specific Programming では、最初に「夢」を書くことを提唱します。次に、設計書を書き、次に、仕様に基づいたテストスイーツを書き、最後に実装します。 Haskell の QuickCheck 関連でヒットしたページ。 私は今現状の lucille を gappa や coq, SPIN などの Formal verification や model verification を使って 一から書き直したい要求にかられているのですが、 この CSP の考え方がとても共感できます。 CSP のやり方と formal verification の考えが似ている気がするので、 少しテストについて考えてみたいと思います。 テストについて いままではコードに対するテストでいいかなぁとか思っていたのですが、 gappa を知ってから考えが変わりました。 レンダラにおいては、アルゴリズムの検証が非常に重要になると。 そして、コードは仕様やアルゴリズムの実態であると考え、 SCP のように仕様に対するテストを書く、アルゴリズムに対するテスト(証明)を書く、 というものが必要である、と。 たとえば、Continue reading “独りで始める Concrete and Specific Programming(CSP)”

floating point computation, part 0: 数値計算と誤差の話

渡部 善隆: 数値計算と誤差の話〜浮動小数点演算はどれくらい信用できるか〜, 九州大学大型計算機センター広報, Vol.27, No.5 (1994), pp.556-580. http://yebisu.cc.kyushu-u.ac.jp/~watanabe/RESERCH/MANUSCRIPT/KOHO/FLOATING/intro.html 最近浮動小数点計算の資料を読みあさっていて、一番印象に残った文がこれ。 数値計算の品質保証に関する研究は、 ヨーロッパ、特にドイツで精力的に行なわれて います。 もし、読者のどなたかがヨーロッパの学会で、 例えばある非線形方程式の数値計算などの研究発表をされる場合、 精度保証付のソフトウェアを使って誤差をきちんと評価した結果を出してないと、 ましてや単精度の計算などだったら ブイブイ突っ込みが来る可能性のある分科会もあるので、 特にドイツに行かれる方はご注意下さい。 なんと胸を突き刺すようなお言葉… この文で言われているように、浮動小数点計算の文献を多く当たって感じるのは、 単純に計算が早ければよいわけではないということ。 そして、単精度ではかなり注意しなければ精度に不安がありそうだということ。 グラフィックス、とくにレンダリング、の研究発表において、 数値計算の誤差について気に留めるやつなんて見たことが無い気がする。 (ジオメトリやシミュレーション系ではあるかと思いますが) たとえば GPGPU で、 「GPU で CPU の浮動小数点計算が n 倍早くなりました!」というたぐいのもので、 ただし GPU の実装では誤差が x ulp になります、それに対して CPU では y ulp ですみたいな解析はやっているんでしょうかね。 (実行してみたら誤差が 1.0e-4 ですとかそんなのは当たり前として) CPU は倍精度で計算していて、GPU は単精度だった、なんてことも無きにしもあらずな世界ですからね。 とはいえ、最近ではしっかりしたヤツも現れているようで、 [3] 見たいにContinue reading “floating point computation, part 0: 数値計算と誤差の話”

luxrender, a GPL unbiased renderer

http://www.luxrender2.org/ LuxRender is a new, open-source, free software rendering system for physically correct, unbiased image synthesis. Rendering with LuxRender means simulating light according to physical equations, this produces realistic photographic quality images. It’s an authorized fork of the PBRT project, focusing on production rendering and artistic efficiency. PBRT based unbiased renderer. Cross platform, multithreading, MLT,Continue reading “luxrender, a GPL unbiased renderer”

Work in progress: Initial Haskell version of MUDA

[En] Finally, I’ve finished initial Haskell reimplementation of MUDA language[1,2, 3] compiler. http://lucille.svn.sourceforge.net/viewvc/lucille/angelina/haskellmuda/ Here is an example. // input.mu // Input MUDA code vec add_func(vec a, vec b) { return a + b; } From this input, MUDA compiler(with x86 SSE CodeGen) generates the following SIMD code. $ mudah input.mu // // The following codeContinue reading “Work in progress: Initial Haskell version of MUDA”

MINILIGHT, a minimal global illumination renderer

MINILIGHT, a minimal global illumination renderer http://www.hxa7241.org/minilight/minilight.html C++ (950 lines) OCaml (462 lines) Ruby (499 lines) Lua (566 lines) Adobe Flex/ActionScript3 (642 equivalent lines (862 including extra UI)) AS でパストレかよ!というのもありますが、 もうひとつ注目したのは各言語のコード行数。 関数型言語である OCaml が一番コード行数が少ないですね。 そして実行速度は C++ > OCaml > スクリプト言語の順番とのこと。 手続き型に比べて関数型はコード量が少なくて済んで、かつ速度もそこそこ、 という利点が示されたよい例だと思います。 もっとグラフィックス野郎にも関数型言語が普及してもよいのではないかと思います。 もちろん、関数型言語でも得手不得手はありますから、 「関数型が適していそうな場所なのに、C/C++ が使われている場所があるなら、 そこは関数型に置き換えるのもいいんじゃない?」という意味です。 関数型言語の特徴は、「OCaml のすすめ」[1] に集約されています。 Ocaml, Haskell と関数型言語を一通り触ってみて、ここに書いてあることは まったくもって当てはまるなぁと感じます。 [1]Continue reading “MINILIGHT, a minimal global illumination renderer”

RE: Real Time Ray-Tracing: The End of Rasterization?

http://ompf.org/forum/viewtopic.php?t=617 れしぇとふがコメントしてますね。記事にバイアスがかかっていた理由が納得。 一つの企業なのに情報の交換がなかったり(外に向けての)意見が違っているのは、大企業病らしくていいですね。 とはいえ、Intel の blog は良い意味で煽っているということでレイトレが発展することに期待。 # 本当は横目に見ているんじゃなくて、自分でも道を切り開いていくべきなのですが、 # ompf のホントにすげー奴らを見ていると、 # まだまだ自分は精進すべき段階だなぁと思います。 # だって世界中のグラフィックス研究者(主にレイトレ野郎だけど)が参加してしていて、 # フォーラムでフランクに発言しているんですよ! 世の中変わったなぁ