amd64 dual core 対応

これからの CPU のマルチコア化、64bit 化の流れを見据え、 lucille の開発環境に AMD のデュアルコア CPU を追加しました。 特に外部 GPU を利用する必要もないので、 今回は内臓グラフィックスを持つ、キューブベアボーンである ST20G5 に、 最近のお気に入りである debian(64bit の amd64 版)をインストールしました。 http://www.debian.org/ports/amd64/index.ja.html 現在リリースされているインストーラでは、ネットワークをうまく認識してくれなかったので、 daily のインストーラを利用しました。 http://cdimage.debian.org/pub/cdimage-testing/daily/amd64/current/ それでも、ACPI 関連ではカーネルパニックに、フレームバッファ関連では ウィンドウの表示に失敗したので、起動オプションに以下を指定して回避させました。 # install acpi=off debian-installer/framebuffer=false   現在の linux では、kernel 2.6.12 以上でないと、AMD のデュアルコア CPU を、 CPU が二つあると認識してくれないようです。 (cat /proc/cpuinfo で processor が 2 個出てくると認識されていることになる) 64bit バイナリとして luculle をコンパイルしてみましたが、今のところ 64bit-izeContinue reading “amd64 dual core 対応”

trac : Integrated SCM and Project Management

Subversion 実践入門http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06613-4 を見ていたら、trac という SCM ツールがあることを知りました。 http://www.edgewall.com/trac/ wiki と subversion とバグトラッキングが一緒になっているのが特徴のようです。 インストールして試してみましたが、デザインもすっきりしていて、 なかなかよさそうでした。 subversion のコード表示では、リビジョン間での差分なども視覚的に表示できるので、 どこが変わったとかも web 上でみることができます。 自分でも lucille のコードを書いていて、どこがどう変わったのかも 覚えなくなっているときがあるので、もう少し使ってみて、使えそうならこの trac で lucille のサイトからコードまでを一元管理できればと考えています。

グリッドハッシュ

lucille では主にレイトレの空間データ構造には一様グリッドを用いており、 一度にガバっと三次元ボクセル(たとえば voxel[128][128][128])という形でメモリを確保しています。 これだと、もっとも単純なのですが、物体の無いカラのボクセルでもメモリを 確保してしまうため、メモリを無駄に消費してしまうという欠点があります。 ひとつの解として、ハッシュを用いてカラのボクセルはメモリ確保しないという 方法があります。 グリッドハッシュは少し調べて試してみたことがあったのですが、 Arnold も空間データ構造にグリッドハッシュを利用していると聞き、 lucille でも、本格的に lucille に組み込んでデフォルトの空間データ構造に しようかと考えています。 ボクセルハッシュ 視覚的な解説は、 http://www-evasion.imag.fr/Publications/2005/ZTKHRF05/spatial_subdivision.pdf が参考になります。 通常のハッシュアルゴリズムとほとんど同じです。 まず、構築時では、物体をボクセルに登録します。 物体位置 (x, y, z) からハッシュ値を計算します。 hashval = hash(x, y, z) % HASH_TABLESIZE この値でハッシュテーブルをルックアップします。 voxel = hashtable[hashval] この voxel の場所にポリゴンを追加します。 しかし、ハッシュテーブルの数は有限で通常ボクセル分割数よりも少ないので、 異なる (x, y, z) でも同じハッシュ値と衝突してしまう可能性があります。 この場合はリンクリスト(チェイン)を作成します。 ボクセルには自身が対応する (x, y, z) の情報も保持しておきます。 found = false;Continue reading “グリッドハッシュ”

wavelet noise and modified noise 2

http://lucille.atso-net.jp/blog/archives/2005/08/wavelet_noise_a.html からの続きで、ここで実際に Perlin noise と wavelet noise を FFT 変換してみようと思う。 FFT 変換は、octave や mathematica などの数値計算ソフトでサポートされているが、 ここでは自分で作成したノイズプログラムを FFT への入力としたいから、 C 言語のライブラリであるほうが都合がよい。 今回は FFT 変換を行うライブラリとして有名な fftw を利用した。 (ちなみに octave では内部で fftw が使われている) http://www.fftw.org/ クロスプラットフォームであるのも魅力で、cygwin のパッケージなどにも含まれている。 最新版はバージョン 3 で、バージョン 2 からは API 周りなども違っているので注意が必要である。 ここではバージョン 3 を用いた。 フーリエ像の生成は、 フーリエ変換したい元の 2D 画像を作成 -> 離散フーリエ変換(FFT) という手順で FFT を行うことで得られる。 もちろん入力を離散画像とすることにより、 ナイキスト限界である 2Continue reading “wavelet noise and modified noise 2”

64bit 環境とコンパイラ, Intel or AMD?

64bit環境で試すコンパイラ – アセンブルコードに見るその実力 最近は 64bit CPU も出てきましたし、デュアルコア CPU も出てきたので、 そろそろ lucille も 64bit + デュアルコアという環境で開発を行っていきたいと 思っています。 そんなわけで、上記のページはとても参考になります。 かいつまんでみると、 – 64bit 化で 32bit に比べて 10% 程度の向上(コンパイラの最適化有効で) – デュアルコアは理論どおり 2 倍くらいのパフォーマンスアップ – SSE2(とあるけど、実際には float x 4 の SSE 演算なのかな?) を使う以外は、 だいたい Intel よりも AMD のほうが性能がよい AMD は、SSE 演算は遅いがそれ以外は Intel よりも演算性能がよい、 というのを聞いたことがありますが、だいたいその通りのようですね。 ILM などの多くのプロダクションでは、レンダーファームには AMD のプロセッサが 使われているようです。レンダリングの計算性能がよいからなのでしょうか。 私はいままで AMD のContinue reading “64bit 環境とコンパイラ, Intel or AMD?”

MQOtoRIB

前回 MQOtoRIB はもう公開されていないようだ、、、と書きましたが、 作成していただいた作者である Soichi.H. 先生から パワーアップされて再公開されているとのご連絡をいただきました。 http://homepage.mac.com/soichi_h/renderer/ の PolyConv です。 これらエクスポータを最大限活用していただくためにも、 lucille の RIB 読み込み部分やパーサなどもしっかり作りこんでいかなければなりません。 (いまのところパースエラー処理もまともにできないダメダメなので)

Security-Enhanced Versions of CRT Functions

Visual C++ 2005 Express(beta)  で lucille のコンパイルテストをしていると、 warning C4996: ‘fopen’ が古い形式として宣言されました。 c:\program files\microsoft visual studio 8\vc\include\stdio.h(235) : ‘fopen’ の宣言を確認してください。 というような警告が出ていました。 ついに VC では標準 C ライブラリ関数すらサポートしなくなるのか?… と思いながら華麗にスルーしていたのですが、そろそろいい加減原因を調べてみるかという気分となり、 よくよく C4996 のエラーコードで MSDN を検索すると、以下のようなお返事が。 http://whidbey.msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vccomp/html/926c7cc2-921d-43ed-ae75-634f560dd317.asp つまりは、いくつかの関数については、セキュリティを高めた標準 C ライブラリ関数の 拡張版があるのでそっちを使ってくれ、という意味での警告ということでした。 セキュリティを高めた標準 C ライブラリ関数の代替関数のリストは、以下の MSDN にあります。 http://whidbey.msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vccrt/html/f87e5a01-4cb2-4379-9e8f-d4693828c55a.asp たとえば、fopen() の場合ですと、fopen_s() を替わりに使うことが推奨されています。 http://whidbey.msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vccrt/html/c534857e-39ee-4a3f-bd26-dfe551ac96c3.asp セキュリティを高めたバージョンの標準 C ライブラリ関数の拡張版は、VC 固有のものでしょうか? というわけで、これからは、VC 2005 向けには、 ワーニングを抑制するために、コンパイラオプションで _CRT_SECURE_NO_DEPRECATE を定義するか、Continue reading “Security-Enhanced Versions of CRT Functions”

Spiral バケットレンダリング

lucille では、Z 字順、ヒルベルト曲線順でバケットをレンダリングするコードを書いてみたのですが、 http://lucille.sourceforge.net/blog/archives/000356.html (ヒルベルト曲線順) http://lucille.sourceforge.net/blog/archives/000116.html (なぜバケットレンダリング順序が大切か?) vray などの商用レンダラのように Spiral 順(真ん中から渦を巻くように外側に) にレンダリングするようにしたいなーと思っていたら、 Production Rendering : Design and Implementation http://www.amazon.co.jp/exec/obidos/ASIN/1852338210 http://bookweb.kinokuniya.co.jp/guest/cgi-bin/booksea.cgi?ISBN=1852338210 に、ビンゴなコードがあったので実装してみました。 http://lucille.atso-net.jp/svn/lucille/src/spiral.c うーん、結構良いですね。実装も簡単ですし。 非正方形な画面サイズでも対応できるので、ヒルベルトや z 曲線順のように (一時的に)バケットが画面からはみ出ることなく、 バケットを画像面上で連続してスイープさせることができます。

SBR 2005 観覧会のお知らせ

長らくお待たせしていましたが、 SBR 2005(SIGGRAPH 2005 論文実装レース) の観覧会の日程 が決まりましたので告知させていただきます。 期日: 9/23(金曜祝日) 場所: 東京都目黒区駒場あたりを予定 内容: SIGGRAPH 2005 論文解説および実装者による実装解説 今年(セカンド・ステージ)は、なんと SIGGRAPH 2005 論文採択者 自らの論文実装解説などがご聴講いただける予定です。 発表者の内容および観覧会の詳細は、SBR 2005 にて後日お知らせいたします。 (数日中に専用ページを作成します) SIGGRAPH の論文や最新グラフィックス技術にご興味のあるかたは、 ぜひともご観覧にいらしてください。 とりいそぎ告知まで。