angelina, 検証用レンダラ

by syoyo

さて、 lucille の本来の目的は、各種レンダリング技術の実装をためしつつも、
RenderMan インターフェイスをサポートした、クロスプラットフォームで
それなりにつかるレンダラを製作することであるのだが、
しかし、SSE による最適化やらメモリ最適やらぽこぽこ追加していくに従って、
新しい試したい機能やらアーキティクチャが変わるような機能を追加することは
困難になってきているのを感じている。

結局今のところ、lucille 十分にコアとなるアーキティクチャ構成も決まらずに、
すでにしてリファクタリングをするのもおっくうなほどソースコードが
ごちゃごちゃになっている。

また、レンダラを 1 本しか書かないで新しい機能をテストするとなると、
果たしてそれが正しい結果なのだろうかと検証するのが困難であることを
常に感じてきていました。

そこで、もうひとつ、簡単な検証用のレンダラを作ったほうが、
トータルでみると効率的ではないかという結論に達した。

この検証用レンダラは、基本的に最小限の機能しか持たず、
ほとんどのパラメータは決め打ちで、浮動小数点計算に double を使うようにする
など、特に最適化も行わない。
クロスプラットフォーム性も特に意識せずに、自分の環境でビルドできれば十分とする。

もちろんこのようにするのは、必要な機能のラピッドタイプに集中するためです。
というか、そもそも最初からこのようにすべきであった気がする。

ラピッドタイピング

ラピッドタイプに集中するためには、どのような言語にしたらよいかを考えてみた。
最終的に lucille は C 言語であることには変わりはないが、検証用レンダラは
不明なバグに悩まされることなく、機能のプログラミングに集中できるものがよい。

まず思いつくのは python などのスクリプト言語である。
しかし、レンダラにおいては数値演算をはじめとして、
全体的なパフォーマンスを引き出せるものが必須となるので、
スクリプト言語はやはりあきらめざるを得ないであろう。

そうなると、C 言語ベースの言語しかしらない私としては、
C, C++, C#, java のいずれかになる。

C#, java については、中間言語方式であるけれども、C/C++ と同程度の
数値演算速度が出せるとのことであるから、パフォーマンスには問題がないだろう。

java でレンダラというのはすでに多くあるであろうから、
ここは建築家なレンダラに対抗して C# というのもおもしろそうだ。

C# は、 mono 使えば、Mac OS X, Linux でも C# のコンパイル・実行環境
は手に入る。もちろん Windows 以外だとウィンドウシステムの
フレームワークを使うことが難しいのでコマンドラインのみとなるであろう。

とはいえ、結局のところは、std::vector や std::map くらいをちょこっと
使う程度の、限りなく C に近いC++ + fltk となりそう。

angelina

新しい検証用レンダラの名前は、angelina である。これは angelina が
lucille の子供であるという古い神話?に基づいている。

angelina はひとつのレンダラではなく、一機能一レンダラとなる予定である。

もし次何かあるとしたら、angelina の子供である e○○○○○○○に
なるのかなぁ…

Advertisements