2010年05月07日
独自UI
バイナリをダウンロード(Windows/Macosx10.6)
さて、GWの中盤の成果は独自UIの実装だ。ここまで賞味３日間の成果。
描画系はOpenGLでマルチプラットフォームだ。
よくソフトウェアシンセサイザなどのソフトは独自UIなものが多いが、
それ以外の一般ソフトではあまり独自UIはみかけない。
一番の理由は、他のソフトと見た目が違うためにとっつきやすさがなくなる
という理由で敬遠される・・というのがよく言われるだが、
よくできた独自UIはカッコイイし、そのアプリに特化して、使いやすければ
むしろ違うことが正しいのである。
まぁプログラマが上記のような理由を述べるときはたいてい「めんどうだから」である。
かくいう私も面倒で今までやってこなかった。
そんな私が重い腰をあげ実装に至った理由は３つ。
１つめ
数年前から次期システムはモジュラー型のプログラミングシステムが
欲しいなと思い、次期skFrameworkのシステムの中核にすえることを考えていたが、
このモジュラーのようなUIをもったUIライブラリに出会えなかった。
なのでこのモジュラー部分に関しては作らざるを得ないと考えていた。
参考になるのはMacOSXのQuartz Composerとかまぁそんなの。
２つめ。
次期デモ開発システムのskFrameworkの仕様として、
マルチプラットフォーム対応があるのだが、マルチプラットフォームになると
とたんに使えるライブラリ減る。
ちょっとしたアプリにさっとつかえるUIがなかったのだ。*注1
今回は利便性も考え、ヘッダをインクルードするだけで使えるようにした。
３つめ。
以前仕事でFlashをつかって独自UIを作ったことがあったのだが、
C/C++プログラマとしてFlashなら簡単に独自UIが作れるだろうと思っていた。
しかし、実際の作業はほとんどコーディング作業で、Flashのいいところは
UIのコンポーネントの図形や画像をマウスで作成できるところにある。
細かい動作の部分はActionScriptで制御する必要があった。
これならC/C++で実装してもかわらないんじゃないか・・？
と思い、Flashで図形を書いていた部分をGLの命令におきかえればいいんじゃね？
という非常に短絡的な思考で開発を始めるに至った。
実装した結論としては
やってよかったと思う。むしろFlashのActionScriptのような軟体言語よりは
はるかにC++のほうが実装しやすかったように感じる。
UIのコンポーネントもデザインをシンプルなものに絞っていたので、
まぁマウスで描くように簡単に・・・とはいかないまでもまぁいい感じだろう。
テキストサービスはまだ使えるようなレベルではないが、まぁこれからかな・・。
あとは念願のモジュラーUIを獲得したので、しばらくこれで遊べるといいなぁ。
ちゃんとマルチプラットフォーム対応だし。
思ったより作業量は少ない。
最初からすべての機能を実装する必要はない。
ボタン上でホイールとかシフト押しながらどうとかなど、
ほとんど使わないような機能は実装する必要がない。
これで半分くらい描画系にさいているが、全部で1500行くらいだ。
ぜひ独自UIをつくるか作らないか思い悩んでるひとはやってみるのがいいだろう。
それほどの開発工数を必要とせずに実装することができるだろう。
例としては国内で有名なのはMTFrameworkとかかな。
やっぱり独自ＵＩだとオリジナルの世界観があっていいよね・・・。
と思うのはオタクプログラマだけかねｗ
注1について
今回のUIを実装するに至っては、フリーのライブラリもいくつか検討した。
仕事でも使ったことがあるのはwxWidget。まぁ悪くないけどライブラリがでかいし、
ちょっとしたものをつくるのも面倒だし、なによりダサい・・。
OSネイティブUIを重視しているために細かいところの融通が利かない。
CG系でははやりのQtは商用利用は有料だがLGPLのフリー版がある。
社内の内製ツールなどには自由につかえるとのことだ。
最近ではMaya2011がQtに対応したらしい。
Qtは最近は非常に開発が活発でNOKIAがかなり力をいれているようだ。
最新版の4.7ではFlash的なUIのトランジションアニメーションをつくけるような
仕組みも備えている。が、このライブラリは非常にでかく
WebKitのBrowser機能まで含んでおり、ライブラリのビルドに４時間以上かかったorz
OpenGLともうまくやれる仕組みはあるのだが、ソースコードがかなりQtべったり
な感じになるのがいまいちな感じ。このへんはまだwxのほうがマシか。
あとはオープンソースなプロジェクトでClutterというものがある。
なんか結構当たらしめなプロジェクトのようでまだver1.0である。
だが、まだちゃんと使えるようにはなっていないようで、とりあえず動きます。
だしましたっ。って感じ。スクリーンショットとかもないし・・・。
しかもこいつは大量のライブラリに依存してるときた・・・。あぁ微妙。
まぁそんなこんなで、結局欲しい機能がない＆いまいちダサいという理由で
上記のものは却下。まぁもっと汎用UIでいいよというものであれば、
wxかQtを利用するだろう。
まぁ今回つくったライブラリは既存ＵＩライブラリとも共存可能なので
まぁそのあたりはうまくやっていこうかと思う。
投稿者 kioku : 04:02
2010年05月04日
D3D11はじめました。
みなさんGWはいかがお過ごしでしょうか。
私は普段なかなか時間がとれなくてできないことを
ここぞとばかりにこなしでおります。
とりあえず、マジで重かったWindow Vistaをぶっとばして
Windows7のインストールを果たしました。
本当に重くて、Webブラウザするのがやっとみたいな・・・
最後のほうはFlashビデオをみるのすら重かった・・・。
プログラムの開発すらイライラするくらいです。
なんで重くなるのかよくわかりませんが・・。
（インストールした当初はもっと軽かったような・・・。）
最初はAeroすげーとか思ってプラシーボだったんですかね。
見慣れてくるとレスポンスのほうが気になってきます。
Win7にして劇重だったのがちょい重になりました。
うーん、やっぱり描画周りが重いのはグラボのせいですかね
8800GTなんですが、そろそろGTX460あたりに変えたいところです。
CPUメータのガジェットをいれたんですが、なんかつねにCPUがなんかやってます。
5%-10%くらいでなにかを・・・しかも4coreつかってるし・・。うーん。
（タスクバーみても何か目立つものは動いてないんですがね・・・なんかのサービス？）
あ、とりあえずraid0(ストライピング)にしました。
ベンチとったところRead/Writeのパフォーマンスは倍くらいになってるのでまぁいいかな。
バックアップは先日NASを導入しそっちをraid1にしてるので、まぁ大丈夫でしょう。
さて、Win7にして快適に開発できるようになったし
というわけで、時代はD3D11です。
D3D10は触ってなかったので、D3D9 -> D3D11です。
うわさではだいぶ変わってしまったらしいですが・・。
フレッシュな気持ちでがんばりたいですねぇ
で、
D3D11検索してみたんですが、あんまり日本語サイトが引っかかりません。
えー みんなまだあんまりやってないのかよ・・。
というわけで、いっつもROMなのもあれなので
今回は情報を発信することにしました。
D3D9使い浦島太郎のD3D11入門
D3D9使いの人がD3D11を学ぶに必要な知識を中心に書いていきます。
不定期更新だし、もしかしたら途中で・・・。
なんてこともあるかもしれませんが、まぁそれはそれで(^-^;)
実は３日くらいやって気がついたんですが、
D3D11はまだ正式リリースではないのですね・・。どうりで解説サイトが少ないわけだ・・。
しかしまぁ現在公開されている最新版SDK DirectX SDK Feb 2010 の時点で
D3D11 RTM なので、まぁまぁ本番仕様だと思います。
しかし、まだEffectまわりが確定していないようで、標準では組み込まれていません。
一応ソースコードが同梱されているので、自分でコンパイルして試すことが可能ですが、
いろいろ試してましたが、まだちゃんと使えない模様。
ネットでのD3D11のデモとか公開されてるからすでに完成してるのかと思ってましたが
どうやら、シェーダをじかにたたいて動かしてるようですね。ようやる。
というわけで、エフェクトが正式に動くまですこし放置です。
（できるところまでのサンプル解説はやる予定）
もう次のDirectX June 2010がでるらしいし、それはきっと正式版D3D11だよねっ
投稿者 kioku : 02:28
2009年08月30日
OpenCL AO Bench
9/11 update - add animation version.
9/6 update - optimized.
8/28発売のMacOSX 10.6 Snow leopardをさっそくインストールして
OpenCLのプログラムをかいてみたぜっ！
I installed MacOSX 10.6 Snow leopard and coded the OpenCL program.
いつものごとくAO Benchです。
Source code and Binaries(MacOSX 10.6 Only) (280KB)
CPU or GPUで動いています。CPU版は
AO BenchサイトにあるC言語版のパフォーマンスとくらべると
特に最適化はしてませんが、そこそこのパフォーマンスはでてるのかと思います。
GPU版はもう少し早いと予想していたのでややガッカリです。
一度メインメモリにリードバックしてるので、遅いのはそのせいかもしれません。
そのうち時間があれば、メインメモリにリードバックせずにやってみたいと思います。
今回は、OpenGLを表示用につかってるんですが（画像転送するだけ）
OpenCLより先にOpenGLの初期化をしていると、なぜかOpenCLのデバイスの初期化で
こけることがあります。（gccの最適化しなければ動くけど、最適化すると動かないみたいな・・）
もしかしたら、gccの最適化がアホなのかもしれませんが・・。詳細不明です。
とりあえず、先にOpenCLの初期化をしておきましょう。
現在のところCPU(Intel Core2uo)で動かそうとするとOpenCLのワークグループの数が1でないと
動かないようです。GPUの場合は最大512。(GeForce9400M)
アクティビティモニタでは２コア動いているようなのでいいのかな・・・。
ちなみにintelのCLコンパイラは
cvmsErrorCompilerFailure: LLVM compiler has failed to compile a function.
というようなエラーをはいてきました。どうやらLLVMで動いているようですね。
しかし、今回はこのコンパイラのエラーに悩まされました。
関数の関数からグローバル変数にアクセスすると、このエラーでおこられるので
一度ローカル変数に代入してやるとちゃんと動くという・・・なぜ・・？
全体的にGPUとCPUでコンパチのOpenCLプログラムを書くのにやたら時間がかかりました。
まぁこの辺りはゆくゆくは良くなっていくのかなぁ
つっこみ募集中〜♪
---
9/6 追記です。
このエントリをあげたら、早速メールでのフィードバックをいただきました。
おたより紹介です。
メールの差出人は・・・なっ！ AppleのMunshiさんです！？
中の人キター！！
内容ですが、呼び出す関数を高速版に書き換えたぜって内容でした。
normalize -> fast_normalize
sin, cos -> native_sin, native_cos
これにより、CPU版が10%程度、GPU版が20%程度早くなるようです。
native_xxxはOpenCL仕様書には実装依存と書いてありましたが、
MacOSXにおいて,Intel CPUとNVIDIA GeForceにおいては実装されてるようですね。
というわけで、精度を要求されない計算においては、高速版の関数を使うことをお勧めします。
ソースとバイナリを更新しておきます。
I updated the source code and binaries.
Source code and Binaries(MacOSX 10.6 Only) (280KB)
ちょっとOpenCLのデモをしたい人のためにアニメーションバージョンを作成。
球がおいてある周りを視点が回ります。
This is Animation demo version.
2009年05月23日
4KB Intro "Elevated" was disassembled.
2chBBSのメガデモスレにいきなり 驚愕4KB Introの逆アセンブルされC言語化された
Elevated のソースコードがあがっていました。 ちょｗｗｗｗｗ
とりあえず、保守の意味も含め、
まことに勝手ながら、転載させていただきます。
日本のアプロダにあがっていたことを考えると
日本人のしわざ・・・。
こんなことできる人は限られてるはず・・・。166さんのヨカン・・？
とにかく、逆アセしたひと GJです。
ソースみてたら、超よさげなソースの予感なので解説です。
ソースコード内容：
個人的にアートの内容を解析して、仕組みを解説するのは気が引けますが、
まぁ手法についてはelevated のreadmeにも簡単に書いてあるので良しとしますか。
これがElevated の全貌だっ！！
- D3DXCreatePolygonで４面のポリゴンを生成
- D3DXTessellateNPatchesで４面ポリゴンを細分割した、ポリゴンメッシュ生成
- ノイズテーブル作成
[ 0パス目レンダリング(シェーダで計算) ]
- CPUでつくったノイズテーブルを使い、４角ポリゴンにピクセルシェーダを使いながら、
パーリンノイズを生成。これが地形データとなるが、外から与えられる係数によって
地形にそって動いたり、sinとcosによる曲線をうごくような視点位置を生成。
2x1のバッファにレンダリングしておく。
- レンダリングしたバッファをリードバックして視点位置を取得
- スクリプトシステムによる視点アニメーションパスからViewMatrixなどを生成し、
シェーダパラメータにセット
[ 1パス目レンダリング ]
- パーリンノイズを参照しながら、再分割された、ポリゴンメッシュをディスプレイスメントマッピングする
このとき高さや奥行きの座標情報をカラーとして出力する。
[ 2パス目レンダリング ]
- １パス目でレンダリングした画像テクスチャとして、４角ポリゴンを描画。
- 1パス目でレンダリングした位置情報２Dの画像と、現在の視点位置をもとに
視点位置から視点方向にレイトレースして交差するときの深さが計算できる。
- 情報のテクスチャの近隣ピクセルの偏微分をとり、法線を生成。
- 法線、深さのパラメータ、スクリプトからのパラメータをあわせて、雪とか岩肌とか緑とかfogとかの
色を作成。一定値以下は海となる。同様にシェーダで海の色を作成。
[ 3パス目レンダリング ]
- バックバッファにレンダリング。1パス目のデプスの情報と2パス目のシェーディング情報をつかって
進行方向を中心に16回平均のモーションブラー処理を行う。いわゆる、2.5Dモーションブラー。
- 白フェードとか黒フェードの処理、画面全体にかかるノイズの付加処理。
-- 0パス目レンダリングにもどり繰り返し --
以上たぶんこんなかんじ。間違ってたら、誰か教えてください。
かなり短いシェーダのコードでも多くのテクニックが詰め込まれてますね。
パーリンノイズの関数がかなり使いまわされまくってますｗ
シェーダのコード的には4KB似なれてない人がみたら面くらうかもしれませんが、
私が見る限り意外にきれいだと思います。圧縮されやすいようなチューンに２週間かかったと
書いてありましたが、アニメーションやシーンのための定数などは切り詰めた感じではなく、
あくまでクオリティをたもったままの最適化までにとどまっている気がします。
大体なんとなく処理フローの予想はついてましたが、いざコードをみるといろいろ面白いところが
みえてきました。逆アセしてくださった方いい物をありがとうございました。
2009年05月19日
4KBプロシージャルGFX講座完成
やっと講座が完成しました。
最後はおまけで4KB Introの発展までやってます。
(リアルタイムアンビエントオクルージョン 4KBサンプル付)
これで次の2chPartyは参加人数が増えるはず！！！！？
次の講座のリクエストがあればなんかください。
いちおう参考にしますよ〜。
（次はいつになるかわかんないけど・・・）
投稿者 kioku : 02:46
2009年05月11日
4KBプロシージャルGFX講座
おそくなりましたが、GWネタ第2弾です。
最近ちまたで熱い4KBプロシージャルグラフィックスの講座をかきました
（いや、実はまだ完成してないんですが・・・）
のこりの分も今週の早いうちにはしあげますよ〜
とりあえず、これからはじめようという人には取っ掛かりにはなると思います。
4KBプロシージャルGFXのはじめ方からEXEの仕方までの解説です。
内容的には4KBプロシージャルに限らず、4KB Introも作れるような内容にしているつもりです。
というわけで、最近メガデモに興味があって、はじめてみようかなと思っている
人はぜひご一読ください。
4K Procedural Gfx Monitor ダウンロード と 4K Procedural Gfx 講座
2009年05月05日
Flash10 Ambient Occlusion (Pixel Bender)
さて前回のエントリで、Pixel BenderでAmbient Occlusionを実装した。
そもそも、これをやり始めた理由は「Flash10でGPU Ambient Occlusionをやってみたかったから」だが
Pixel Benderで実装するところで作業は80%終わったものだと思ってた。
よーし、あとはActionScript(Flex3) でこのフィルタをくわして、やればおわりじゃーん
とかおもってたら、ここから2日かかったｗｗｗ
ActionScriptに食わせるまえに、Pixel Benderでバイトコードにエクスポートするんだけど、
ここでエラー発生。
えーと、なになに、「お前のコードはFlashではサポートされない機能をつかってます」（意訳）
んー、まぁそういうこともあるわなー。
えーっと、
描画領域定義の関数と、初期化的な関数がサポートされてないのねー。はいはい。
まぁこの部分はあらかじめ、チュートリアルリファレンス読んでたので知ってましたよーと。
えーと後のエラーは・・・。ガッ・・・！！
かっ 関数の呼び出しがサポートされないだとぉぉぉおおおお！
いくらもともとカスタムフィルタ用だからといって、関数呼び出しできないのに
言語とか名乗っていっていいんですかっ！ 俺はそんなの認めねぇぇぇえ！
くっ しかたない関数展開決定。orz
関数呼べないってレイトレ系はつらいね。当たり判定とか。
再帰呼び出し不可はGLSLとかでも同じだけど。
まぁでもなんとか再帰関数を避ける方法はあるじゃん。
さすがに普通に関数くらいよばせて・・・。
この展開に半日作業。
えーっとあとのエラーは・・・。 ゴッ・・・！！
ふぉ、For文がサポートされないだとぉぉお なめてんのかーーー！！！
ぐっ。For文が使えないなんて聞いてねぇぞ。しかも今回移植しようとしてんのはAmbient Occlision
For文使えない・・・オワタ orz
しかし、ここまできて引き返すわけには・・・。
結局気合で展開（半日強）
はぁはぁ・・ へへっ ついにエクスポートできたぜ・・・
これでFlash10 でリアルタイムAOが・・・・
(ActionScriptに読み込ませる書き方で半日はまる)
ええい。いろいろあったが、ついに表示が・・・。
あれっ？ なんか遅くね・・・？
ほんとにGPU使ってる？
とりあえず、サンプリング数をさげるか・・・。
（マウスオーバーで動かせます）
Flash10 AmbientOcclusion (2 samplings)
Flash10 AmbientOcclusion (4 samplings)
要Flash10
んー。
なんかPixel Benderのときのプレビューにくらべて明らかに遅い気がします。
64samplingsとかやると遅すぎて話になりません。（全部ActionScriptで書いたほうが早い）
これってもしかしてGPUつかってないんすかね？
しかも2samplings -> 4samplingsのときに倍以上遅くなってる気がする・・。
理由を探してたら・・・
どうやらFlash10ではまだGPU機能が有効になってない模様
まーじでーーー 俺の作業意味ねーーーー！
ないわーorz
（いちおうマルチスレッドには対応してるようだが・・・)
とりあえず
ソースを置いておきます。
まぁそのうちちゃんと使える時代がきたら試してみてねー
もしくは、そのうちFlashPlayerが対応してて、爆即で動くようになるかも？
まぁ最初は、もしかしたらこれからはFlashの時代かっ！
なんておもったけど、関数使えないとかループ使えないとか無いわー
せめて、Pixel Benderと同等の機能がFlashでつかえないと・・・
やっぱ、時代はHLSL or GLSLですねー。
投稿者 kioku : 02:12
2009年05月04日
Pixel Bender toolkit
さてGWですが皆さんいかがお過ごしでしょうか。
私は家でドイツに行ってるうちににたまったアニメを消化しながらコーディングです。
さてちょっと遅くなりましたが、GW期間ネタ第1弾Pixel Bender toolkitです。
（！！注意！！ Pixel Blender ではない。 Bender。 でもBlenderのほうが言いやすいような・・・。）
なんとなくインターネットしてたらAdobe Pixel Benderというのをみつけた。
Flash10 からGPUの機能がつかえるというのはこのことらしい。
これでつくったフィルタはFlash10でも利用できるらしい。こんなかんじ
Flashとかいじってるひとにとっては、いまさらなネタだけど、今までスルーしてたｗ
さっそくダウンロード。
おっ なんかフィルターのコードがかけるのね・・・ふんふん
てかなんかこれ、こないだつくった4kGfxMonitorにそっくりだな・・・
んー、独自言語だけど、最終的にはGLSLにコンバートされる模様。
おーしそれなら、Flash10でGPUレイトレとかできんじゃねー？ っておもったのが運のつき・・・。
ここからが長かった・・・。
なにわともあれ、4kGfxMonからAmbient Occlusionのコードの移植だ。
これはすぐにできた。しかもPixel Benderではparameterとした変数から
自動的にスライダーのUIを生成する機能があるので、いろいろ試せる。これは便利だ。
macbook(2008late) で13fps@512x512 くらいか。 まぁまぁかな。
ファイルをおいておくので、みなさんためしてみてね。
pixel bender AOソース(テキスト形式)
Adobe Pixel Bender(Win/Mac)
次回につづく。
あ、あと、迷惑スパムコメントが多かったのでしばらくコメントをつけられない状態にしてましたが、
このたびコメント機能を復活させました！。コメントしたかった方は是非ｗ
投稿者 kioku : 06:18
2009年02月01日
4k Procedual Gfx Monitor
というわけで公開です。
特設ページ: 4k Procedual Gfx Monitor
まぁ遊んでみてください。
何か作品をつくったらぜひ公開してみてください。
投稿者 kioku : 18:37
2009年01月26日
GPUAO(GLSL)
追記更新 01/28
追記更新 01/27
追記更新 03/28
こないだからやってる4k procedual gfx用のツールだけど、だいたいできた。
サンプルとテストついでにsyoyoさんのとこでやってるアンビエントオクルージョンを移植
AOのサンプル数は64サンプルですが、一瞬すぎて速度が計測できません ;)
サンプル数を増やしてたりしてたらきちんと計測できてないことが判明。
glClear()とSwapBuffers()の間で計測してたのですが、シェーダはSwapBuffers()完了の
タイミングでは計算終了はしてないということなのか・・・？
10回まわして平均値をとるようにしたら23msでした。1024x768くらいなら10msくらいのようです。
GLSLにはrandom関数がないので、頂点情報と数学関数でごまかしてます
まぁまじめにやるならnoiseテクスチャですかね。
ツールでは4KB用のC++のソースが出力できますが、
コメントやタブ、改行、多重スペースの除去なんかもやります。
ツールから出力されたものをビルドしたものをおいておきます。
あんまり最適化してませんが、crinklerしたら1.7KBでした。（こんなもんか
バイナリファイルをダウンロード
上のファイルででウイルス検知ソフトに引っかかる方はこちら。（非圧縮版）
バイナリファイルをダウンロード
現在のバージョンではRadeonではエラーのようですね。近日中に直します。
たぶんradeon対応しました。GLSLに対応するGeforce/Radeonなら動くはず。
解像度とサンプル数のバリエーション増やしました。
ツールはもう少しサンプルをつくったら一緒に公開します。もう少しまてぃ〜
来週くらいか？
投稿者 kioku : 01:57
2009年01月07日
あけましておめでとうございます
あけおめです。今年もよろしくです。
年越しにこんなんやってました。
4k Procedual GraphicsでのGLSLでのProcedual専用モニタリング環境
vertex shaderとかfragment shaderとかを監視してて、メモ帳で更新して保存すると
即座に変更内容がモニター画面に反映されます。
GLSLのコンパイル時間のみでの作業が可能になります。
まだやってないけど、ソースエクスポータまで乗る予定。
これで仕上げまでやって、後はソースエクスポートしてcrinklerでチンすれば
あっという間に4k Gfxの出来上がりだぁ。
ほしい人はほしいけど、ニッチすぎて誰もつくろうとしないよなぁｗ
アプリは完成したら公開予定。
最近iqがprocedual gfx系の記事をよく書いているので、そのへんもあわせて
和訳したいなぁと考えてます。
そうすると、即席だけど4kgfxの道がかなり明るくなるじゃないかなぁと考えてます。
投稿者 kioku : 02:53
2008年12月06日
CUDA Raytrace
やっとできたよCUDA Raytrace
まぁ途中でいろいろあったので、ぬけてる期間もあるけど
大体週末だけで１ヶ月半くらいか。
まぁ半分くらいパフォーマンスチューニングと
CUDAの謎仕様に振り回されてただけだけどｗｗｗ
肝心の速度だけど、68kポリゴンのウサギで24fpsくらい。(8800GT) たいしてはやくないね（爆
これは前につくったQBVHのCPU版のCUDA移植だけど、
Core2Quad 2.4GHzの1coreでは4-5fpsくらいなので、Core2Quad並くらいしかでてないことになる。
8800GTの理論性能だとだいたいCore2 16coreくらいなので
まだあと4倍くらいはやくなりそうだ。
次のOoOではこのネタを話します。
まぁとりあえず、このネタはこのへんでいったん区切り。
次のデモをこのレイトレネタでやろうかと思ったが、デモで実用的に使うにはもう少し先になりそうだ。
というわけで、そろそろ次のデモとか例のプロジェクトとかもすすめないとね。
投稿者 kioku : 21:33
2008年10月19日
CUDAプログラミングの愚痴
というわけで，CUDAをはじめたわけだが，
わかりにくいねぇコレwww
たしかに，mallocして，memcpyしてcuda処理してってくらいなら
簡単だけど，グラフィックスプログラムとからめようとすると
考えること増えてるし，いわゆるGPGPUのプログラムから楽になることは一つもない
しかも，いろいろ気をつけてかかないと，パフォーマンスでないから
なかなか思うようにかけない．
まず，計算ユニットはベクター型風（nVidiaはスカラ型といってる）なのに
CUDAの最小処理単位はスカラ型で書くようになっている
そのくせ，メモリアクセスはベクター風にアクセスしないとパフォーマンスが
でないからややこしい．（コアレスアクセス）
しかも，スカラだけで考えた計算もできるしSIMDのような計算もできる(同期命令を用いて)
たとえば，1pixelあたり16スレッドの協調動作のプログラムもかけるし，
16pixelそれぞれにスレッドを割り当てた動作もかけるというわけ．
どっちがはやいのかわかんねぇ
メモリアクセスもコアレスアクセスしないとだめだよとかいいながら
CUDAZoneのサンプルとかみるとみんな軒並みテクスチャキャッシュつかってね？
結局なんだかんだいって，キャッシュ頼みじゃねーねかw
しかもCUDAでテクスチャつくるのけっこうめんどいし・・・
デバッグとかもまじやりづらい．テクスチャ経由でごにょごにょするなら
いわゆるGPGPU的なプログラムでやったほうが楽な気がしてきた．
GPGPU的な方法ならどういう風にスレッドを割り当てるかどうかはドライバとかが
やってくれるので特に考える必要がない（きっとnVidiaが一番いい値を設定してるにちがいない
とくにスキャッタ的な操作がないのであれば，グラフィックスプログラマは
普通にGPGPUのプログラムを書いた方が楽かもしれない．
あとCUDAコミュニティの日本語サイトができてるんだけど
先週まで投稿者ほぼゼロだったのに人間が増え始めてるなw
CUDAフォーラム
投稿者 kioku : 21:57
2008年06月24日
ompf
レンダラ野郎のあつまるサイトompfのフォーラムにいってきた。
日本版ompf のOoOOには参加してるので、存在は知っていたのだが
英語だったので読むのがめんどくさがってスルーしてたが、今日読んで
いままで見てなかったのをしまったとおもった。有益すぐるｗｗｗ
ここが世界のレンダラ野郎たちのあつまるところですか・・・
ん・・・なんかどっかでみたことある名前が・・・toxie..?
こいつはpouetにもいたような・・・
てゆーか、iqの4kのプロシージャルレイトレ紹介したりしてるし・・・
メガデモ野郎とレンダラ野郎は紙一重ですか・・・世間せまっっ
いくつか、オープンソースなレンダラへのリンクがあったけど
みんな512x512か640x480で20,30FPSでてますねー
って、デモみてて
なんか2.0 inst/p とかでてるけどこれって１ピクセルあたり２回の交差判定ってことかな
10-20 Mray/secとかでてるから、これで512x512で１ピクセルあたり2回のTriangleIntersectで
20-40fps あー たしかにそれくらいでてますね・・。
じゃぁ１ピクセルあたりは２回の交差判定でいいのか・・・・
自分のプログラムで1frameのピクセルあたりの平均TriangleIntersect回数をしらべたら
1.29回だった（ブッダなのでレイがあたらない箇所が半分くらいある。）
そんなに多いわけではないかなぁ・・・まぁところどころ回数が多いところがあるのでそれは直すとして・・・。
・・・。
レイの交差判定のところをみたら、どうやらwhile(1)なループで交差判定がかかれている
のこるはこの辺があやしいな。俺のコードは再帰コードになってるよ。
まぁたしかにバシバシ関数よばれるけどさ・・・いちおうfastcallにしてるけど・・・だめか・・・ｗ
というかもうこのへんくらいしか残ってない。
まぁ早くは成るだろうからやってみるか・・・。
投稿者 kioku : 01:21
2008年06月23日
続・レイトレ
前回ＳＳＥにしたら２０％しか速くならなかったと書いたが、
移植中にレイの方向による条件分岐がぬけていた。
それを復活させたら倍くらいになったｗｗｗ。やっぱり結構ちがうもんだね。
まぁそれでも、あと倍くらい速くならないと、論文とかの数値とあわない。
今のところブッダ10kTriで2fps@1024x1024くらいで
論文でもsyoyoさんのはなしでも4,5fps@1024x1024くらいなので後倍くらいでるようだ。
まぁ一番遅いところはレイと三角形の交差判定で、計算上
1024x1024で4,5fps出そうとおもうと、１ピクセルあたりの平均交差判定が
0.5回くらいになってないとだめなきがする。
俺の平均交差判定回数は・・・・・・1.2回くらい・・・うーむ、出直してきますｗｗｗ
ブッダだと画面の半分くらいのピクセルで交差判定する必要があるから
そこもだいたい１ピクセルあたり１回くらいで判定する必要があるわけだが、
今の俺のルーチンだと６，７，８回とかやってたりする。ちょっ
あと、平行してやってるPetite Light Render2だが、サムネの通り大体できた感じ。
これをやってて、わかったのが、今の俺のルーチンだと重なってる面があると判定が激重になる
なんかロジックと関係してるきがするなぁ。
Petite Light Renderはそのうちこっそり公開しますｗ
投稿者 kioku : 01:13
2008年06月17日
SSE化
BVHレイトレをSSE化してみた。
２０％くらいしかはやくなんねーorz
やっぱ分割アルゴリズムのほうが問題か
FPUのコードだと早々に条件分岐して、判定コードからぬけるんだけど、SSEのコードだと
_mm_max_psとか_mm_min_psとかで最大最小とってるから最後まで条件分岐がない。
しかも途中で分岐すると、余計に遅くなるし・・・。
経験上、FPUだと分岐予測がどうとかよりは、計算しないような分岐をいれてるほうが
最終的に早くなることも多々あるが、SSEのときは分岐しないほうが早いことが多いのかね。
（ある程度SSEロード命令のオーバーヘッドもあるのか）
とくに_mm_max_psとか_mm_min_psはかなり高速に動作するらしく、
intelのSSE導入のマニュアルにも条件分岐コードの代わりに使うことを推奨している。
インテル日本語技術資料のページ
なんかもう最近はmacもintelになったからintel一辺倒でいいんじゃないかと・・・ｗ
投稿者 kioku : 08:00
2008年06月01日
BVHでレイトレ
Petite Light Render用のレイトレエンジンを作成中
とりあえずひととおり終わった。まだ最適化はしてない。
Q6600シングルスレッドで2FPSくらいで動く。
こんなもんかなぁー？
NVSceneのデモは今日付けで動き出しました。
はやくツールをつくらねばっ。
投稿者 kioku : 08:40
2008年01月04日
DSD変換 ここまでのまとめ
去年からやってたネタだけど
WAVEからSACDなどに採用されてるDSDフォーマットへの変換。
いままでいろいろ試行錯誤してきたけど、どうしてもノイズがのる
まじめに��Σ変換をすると無音部分は1010101...となるはずだが
VAIOではきだしたDSDバイナリをみると
無音部分では1001100101011....みたいになっててなんかの処理が加えられてるようだ。
DSD変換チップなどをしらべると、10101...だと不安定なので
無音信号とかいうので10011001とかいうのがあるようだ。
これがでるように10101010 -> 10011001では駄目。
そのあと量子化器ノイズシェーピングではノイズを加えて一定のゆらぎをだすことで
ノイズを拡散させるということで、適当にノイズを加えてみたが、むしろノイジーになった。orz
さらにその後、どうやら��シグマは多段でくわせないとノイズシェーピングの効果が薄いということで
多段にくんでみるも・・・なんかかわったけど、むしろノイジーな部分は変わらず・・・。
１段のほうがノイズ少ないよ・・・。
というわけで、普通にデルタシグマする時点でなんか間違ってる気がする。
WAVEを2.82MHzにオーバーサンプルする時点で線形補完じゃだめなのか
まぁでもこれは無音のDSDが1010101..になってないこととは関係がなさそうだし。
というわけで、このネタはしばらく寝かせとく。
だれか詳しい人がいたら教えてください。
（S○NYのDSDのとこにメールしたらおせーてくれるんかな・・・。）
投稿者 kioku : 05:33
2007年10月31日
シグマデルタ変換
前回のエントリーにかいたが
CD(PCM/WAVE)の音をDSD(SACDと同じ方式)に変換するプログラムを書いているが、
とりあえず、DSDのフォーマットファイルであるDSFファイルは生成することができた。
音はなるが、ノイズがのりまくりだ・・・。
俺は単純にPCMの音を補完してデルタシグマ変換してやればいいと思っていたが、
どうやらさすがに安直過ぎた。１次のデルタシグマ変換ではサンプリングレートは上がるが
ノイズがふえる。そこで、高次のデルタシグマをしてやる必要がああるが、WEBになかなか
資料がない・・・。やっとのことでトラ技の２００３年７月号にDSD信号に関する特集があるとわかる。
んで、NOｚ経由でゲットできることに・・・。
むむむ・・・ 奥が深そうだ・・・。
というわけで WAVE2DSD はもう少しかかります。
あ、先行してPS3を買いました（爆
つぎはピュア系のアンプとSPがほすぃと思ってる今日この頃
投稿者 kioku : 00:55
2007年07月22日
VSTi
さて、シーケンサのUIがうまくつくれないという理由で放置されていたKSynth3だが、
sinclがCUBASEを購入したことから、VSTiにすればシーケンサUIはつくらなくてもいいという
結論に達した。
というわけで、VST作成ガイドをしらべたところ、そんなに難しくないようだ。
というか、KSynth3開発当初に私が考えていた処理構造と非常に良く似ており、すんなり理解できた。
SDKのサンプルはすこしごちゃごちゃしていたり、必要な部分がなかったりで
改造したものをあげておく。
まぁこれからVSTプラグインをつくりたい方はどぞー
VSTiテスト
さてあとは、すでにできてるKS3エンジンをのせるかな・・・と。
投稿者 kioku : 06:55
2007年05月23日
.NETプログラミング
とりあえずKS3の開発は継続中なわけだが、
現在はとりあえず、
シンセの周波数とかのツマミは独自の.NETコントロールを作成した。
とりあえずキーボードで音がぴろぴろなるってのはできたわけだが
次に作成しなければならないのはシーケンス入力部分。
KS2ではテキストコントロール→グリッドコントロールとしてきたが
今回はちゃんと独自のコントロールにしたいところ。
.NETコントロールでテキストコントロール系の拡張のしかたが
よくわからなかったので、Google先生におしえてもらうことに・・。
.NETの情報ってあんまりみつからないねー。
なんか質問板でもこのテキストコントロールどやってつかうのとか
そんなんばっかり・・・。
独自コントロールは存在するけどいっつも商用販売のみ（しかも意外にたけぇ
検索ワードがわるいのか"C#"とかひっかかんねぇし
".NET"も違う意味のかぶってる名称多すぎるし・・・。
どうすっぺーーー
一部スクショ
道で拾った
なんとなく役に立ちそうなサイト
おぼえがき
http://homepage1.nifty.com/herumi/adv/adv43.html
なんかいつのまにかSynth1のノウハウ解説ページができてた
よさげ。
http://www.geocities.jp/daichi1969/synthprog/index.html
いっつも検索->"Synth1"でSynth1のページにいくからだから誰も気づかないよな。
きっと５年後のグラフィックスプログラミング環境はこんなん
http://www.mentalimages.com/2_4_1_mentalmill_ae/と妄想してみる。FxComposerにはいるらしい。
投稿者 kioku : 00:53
2007年05月05日
LoderLock
ひさしぶりの連休なのでオーディオケーブルをつくったり
やりかけ放置プレイのソフトシンセのコードをかいている。
ひさびさにコードを書こうと思ったら実行すると
VSのデバッガがLoaderLockとかいうエラーをだすようになってた・・・（なぜ
キー入力をしてるだけなんだが・・・
ヘルプによるとどっかでDLLでマネージコードを呼び出してるのが
原因らしい。てかそんなことしてないはずなんだが・・・
・・・
1時間くらいコード見てなやんだあげく
Google先生でしらべてたら・・・
どうやらiTunesが原因らしい。
ぅぉ たしかに俺iTunes立ち上げてる。→ iTunes終了 → エラーでなくなる
マジですか!?
てか関係ないアプリのエラー拾うってどんなグローバルなデバッガですか>.NET
まぁスタンドアローンで実行するとぜんぜんエラーおきないから問題ないぽいが
iTunesたちあげてると使えいないのもびもう
他の解決策として
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
で
文字列値追加
キー：MDA
値 ：0
ってやるとMDAというデバッガが黙るので回避可能らしい
きちんと.NETに対応してないDLLなどをつかった開発のデバッグには有効な手か・・・
投稿者 kioku : 05:20
2007年02月28日
KS3進捗
とりあえず仮UIつくってパラメータをエンジンにあたえて
音色がかわるところまでこぎつけた。
とりあえず、まだシンセのアルゴリズムをどーするかもきめてない
てか、そのまえにUIつかいにくい(orz
EGでVCOの周波数いじれるような仕組みにしたのはいいが
これはこれでつかいにくい。てか、おもうように
うごいてくれないしー
もちっとコントロールをかんがえるかー
投稿者 kioku : 00:52
2007年02月18日
.NETあれこれ
目下のところKSynth3を開発中なわけだが
UI部分を.NETコントロールを用いたシステムにすることは前にかいた。
シンセプログラムには欠かせないボリュームコントロールなどの
独自コントロールを作ることが比較的容易に行えるからだ。
しかしこの.NETフレームワークがおもわぬ問題に・・・。
問題1：コントロールのバグがすべてを巻き込む！？
独自コントロールを作れるのは良いが、独自コントロールがバグってると
そのあおりをくって、独自コントロールをホストしているフォームもバグる。
（VSのUIデザイナでホストしているフォームが編集負荷になる。）
これはVSの痛い仕様だ。しかたなく、VSが生成したコードレベルでの編集を余儀なくされる。
しかも、独自コントロールがみためにバグっていればなんのことはないが
よくわからないコントロールの初期化のところで死んでいるのでお手上げである。
（なんとなく私が読み込ませている画像リソースがあやしいが・・・）
結局この問題は、そこまで作っていたコントロールを捨てて
新しいコントロールを再度作成することで解決した。
問題2：共通言語ランタイム遅いよ！
.NETフレームワークは共通言語ランタイムといわれるものに対応していて
いわゆるマネージドなコードである必要がある。
しかし、マネージドなコードだといままでのネイティブ（アンマネージド）な
ライブラリとの互換性が無いので、ネイティブで動作するアプリのUI部分だけを
.NETフレームワークで作るには問題がある。そこでVS2005からアンマネージドな
コードを許可するというコンパイラオプションが追加された。(/clrである)
とりあえず、このオプションを有効にしていれば.NETフレームワークを使っていようが
Win32APIもなんでもよべてしまう。
この方法で.NETのUI部分のプログラムでKSynth3を操作するコードをかいてたら
なぜかやたらwaveレンダリングが重い。というか処理落ちしてる。
UI作成前にレンダリングしてたときはそれほど重くなかったのに。
まさかとは思い、プロジェクトをわけてスタティックLIBでエンジン部分のコードを
吐き出してみた。/clrしているUIプログラム側でリンク。
するとまったく処理オチしないじゃないか！！
まさか中間言語で走ってるから遅いのか？どっかで最適化されてるとか聞いた気が
するのは幻想だったのか・・・。
ちゃんと理由をしらべてないが、/clrでアンマネージドコードがかけるからって
いままでネイティブで高速に動作していたやつを一緒にコンパイルしてはならない。
というわけで、
KSynth3の開発がなかなか進行しねー
投稿者 kioku : 07:20
2006年10月21日
.NETで独自コントロール
前回のマネージ、アンマネージの悩みはなんとなく解決した。
つーわけで、Hello,worldじゃないけど、サンプルをつくってみた。
なんかいろいろ使えそうな印象をうける。.NETいいかも・・・。
いままで放置プレイだったのが少しもったいないと感じたくらいだ。
サンプルの内容は
- 独自コントロールのサンプル(マウスイベントによって変化するボタン)
- Win32APIをWindowsフォームアプリからよぶ方法について
である。
※もちろんだが.NETフレームワーク2.0がインストールされていることが
サンプル実行のために必要である。
これでやっとC++Builderなみにつかえるようになったかなと感じた。
むしろポテンシャルは.NETのほうが感じる。
投稿者 kioku : 05:14
2006年10月19日
GUIプログラミング
新しいシンセのGUI部分をどれで実装するかいろいろ悩んでいた。
今まではMFCとかじゃ微妙だし、VS.NET2002のころは".NET"なんて代物は
でたばっかでなんか資料も少なかったし、なんか行き先不安だったので（ｗ
C++Builderで作ってきた。
しかし、今の現状はC++Builderはdiscon(現在はTurbo C++として進化？)で
現状行く先は定かではない・・・
ってことで新しいGUIプログラミング環境を探しているわけだ。
案1: MSの.NETフレームワーク
案2: フリーな環境のGUIライブラリを使う(gtkとかwxWidgetsｔなど)
案3: 自前でGUI描画ライブラリをつくる
まぁ案1はかつて新しいからってことで保留したもの。最近はぼちぼちフリーソフトで
.NETフレームワークを利用したアプリがでてきた。RAD環境なので
VS.NET環境でGUI <-> コード間の移行がスムーズ
（あやしげな（？）マネージドコードで書く必要あり）
案2はいくつかの有名なソフトは利用しているようだ。GUI作成周りはおせじにも
便利だとは思えない。Glideとかいうソフトでソースをはけたりする。
クロスプラットフォームが前提なら結構いいかも。
(本場のメガデモチームもつかってるところもあるようだ。)
案3はぶっちゃけ案2を自前実装ということになるが、自前コードなので拡張は
しやすいかもしれない。たとえば、最近のD3D SDKにはいっているD3D用UIなんか
のような感じでアクセラレーションがきいてる画面の上にオーバーレイできるのは
かなりのアドバンテージかも？
(conspiracyのa.d.d.i.c.t.はOpenGLを利用してGUIをかいてるようだ)
さて、どれもそれぞれメリットはあるが
私が今回チョイスしたいなと今のところ思うのは
案1の.NETフレームワーク
である。
まぁマネージドコードでかかないといけなかったりと
いくつか制約はあるが、もともとVS.NET自体C++Builder,Delphiをデザインしていた
人と同じ人がデザインしてるらしく、かつてC++Builderをつかったことがあるひとなら
いろんなことが直感でわかるデザインになっている。
今回決め手になったのはVS.NET2005からフォームコンポーネントの作成から利用
までの流れが非常に簡単になっていることが重要な点である。
たとえば、今まで独自のコントロールを利用することを考えると
ActiveXのDLLなどを作成し、登録し・・・って結構めんどくさかった。
しかし、VS.NET2005から
同じソリューションにフォームアプリケーションと独自コンポーネントのプロジェクトを作り、
ビルドすると、フォームアプリケーションのほうでフォームのデザインをするときに
独自コンポーネントがツールボックスに追加されていることに気づく
ActiveXのわずらわしい登録などはVSが勝手にやってくれているのか
コントロールの変更があってもリビルドするだけでフォームアプリケーションに追加されている
コントロールは勝手に更新される。
しかもさらにすごいところは、自前描画（オーナードロー）をもつコントロールも
フォームデザイン時点で反映できているということだ。
（この機能はいままでのどのRADツールにもない！！）
この機能は今の私にとっては非常に魅力的である。
GUIをつくるときにおいてまず最低限の機能を迅速に作れるということは
前提として大事だが、やっぱりデモツールをつくるならみてくれも大事にしたいと思うからである。
（ヨーロッパの人たちのツールもcoolだからねー）
つーわけで今回はスクショはないが、まぁぼちぼちいじってみることにする。
とりあえず、ちょいと悩みの種としては
マネージドコードにアンマネージドなネイティブのWin32APIがかけないこと
まぁいちおう
[System.Runtime.InteropServices.DllImport("winmm.DLL", EntryPoint = "PlaySound", SetLastError = true)]
private static extern bool PlaySound(string szSound, System.IntPtr hMod, PlaySoundFlags flags);
てな感じのコードをフォームとかに追加すると、PlaySoundとか使えるようにはなるわけだが・・・
いちいち書くのはめんどうだなぁ
なんか良い方法ないかな・・・
2006年03月03日
OpenAL
あたらしいIntelmacのmac miniが発表されて
いよいよMacOSXが身近になってきたようなきがせんでもない今日この頃
そろそろMacOSXがあたらしいデモターゲットか・・・
ってことでそろそろデモもマルチプラットフォームに対応したい今日この頃。
まぁSystem Kのグラフィックコード大部分はOpenGLで書いてるから
特には問題ないが、サウンドがWin依存だ・・・。
ってことでOpenALで書き直してみた。
OpenALはMacは標準サポートされてるし、
LinuxもLGPLでオープンになってる。
WinはCreativeが意欲的に配ってるみたいで、
SBはいれるとドライバと一緒にはいってるし
かの3Dmark06もOpenALつかってるようなので
そろそろ業界標準かなと・・・
つーわけで、実装したものDownload file
内容はsincl作のHalfExの曲とkioku作のテスト曲の
EXE−Musicがはいってます。
Win,MacOSX,linux版バイナリいれときました。
まぁソースはKSynth2XTのコアコードがはいってるんで
もうすこし非公開ですねぇ(^ ^;
付属のバイナリが手持ちのlinuxで動かない場合はあきらめてください（ｗ
なんかwin,macではちゃんと動くコードがlinuxでは
ちゃんと音がならなかったり・・・ちょっとなやんだ。
linuxは思いのほか制約があったりしますねぇ。
投稿者 kioku : 16:39
2006年02月24日
denormalize問題
Intel系のIA-32のCPU(Pentium4とか)で起こる問題で、
ソフトシンセとか書いてると遭遇する。
ディレイとかのフィードバック系のフィルターをつかってると突然CPUの処理が重くなる。
こいつはdenormalize問題というらしく、浮動少数(float, doubleとか)をつかってると起こる
CPUが浮動少数をあらわすのにnormalizeとdenormalizeという2つの方法を使っている。
normalize は exp と 1.XXX..ってなかんじで指数表示
denormalizeは 0.XXXXX(2) ってなかんじで２進数表示
となっているらしい。
浮動少数が0に近くなるとnormalizeではうまくいかなくなるのでdenormalizeの方に切り替える。
この処理が頻繁にはいると、CPUをくわれて突然倍くらいの負荷がかかる。
（ディレイの処理とかでフィードバックの倍率を0.3とかにしたら、どんどん0に近くなるからね）
KSynthが長い間P4で遅かった問題は、この問題のためだった。
調べたところ、この問題の解決法は
#define DENORMALIZE(fv) (((*(unsigned int*)&(fv))&0x7f800000)<0x08000000)?0.0f:(fv)
ってマクロをかいて
flt = DENORMALIZE(flt);
ってなかんじでコードを、フィードバックされてるところに追加してやれば解決する。
とりあえず、KSynthに関しては70 - 80%くっていた使用率が、30%程度になった。
とまぁpouet.netの掲示板で教えてもらいましたが、
検索したら結構引っかかったし、ソフトシンセの分野では結構ポピュラーな問題のようだ。
さらに詳しく知りたい人はIA-32 Intel Architecture Software Developer’s Manual
の88ページあたりを参照するとよい。
投稿者 kioku : 01:58
2006年01月13日
ライトマップ
さて、かねてから作っていた
レンダリングした結果をテクスチャに落とし込んで
ポリゴンに貼り付けることによって
リアルタイムで動かせるようにするという方法ですが
まぁつまりはいわゆるライトマップを作成して利用する手法ですが
3D Studio MAXとかにはついてるみたいなかんじのことが
どこかにかいてあったんと思ったんですが
他のフリーのレンダリングソフトにはないと踏んでつくっていたら・・・
一足早く,GPUレンダラーのParthenonが対応しちゃいました・・・orz
なんかこのタイミングだとほとんど同時に作っていたようですね・・・
しかしまぁ向こうはGPUによるレンダリングでこっちはCPUによるレンダリング・・・
速度では勝負にﾅﾗﾈ・・・
しかしまぁせっかくなんで
同じ物体で比較してみました
(それぞれの結果をテクスチャとして貼り付け、メタセコイアでプレビューしてみました)
左が自前の結果 右がParthenonによる結果
cronellbox
TBLのOcean MachineにでてくるらしきBox(w
それぞれは光のパラメータが違うので同じには見えないですね・・
それに私の方はトーンマッピングとかしてないんで、なんか明るすぎるところも多々
下のTBLのBoxにいたってはテクスチャの継ぎ目がみえちゃってます・・・
（一応テクスチャに対して水平・垂直な場合は継ぎ目をなくす処理は書いたんですが
斜めの場合はうまく処理できてませんでした。Parthenonはうまいこと処理されてますねぇ)
Beeさんｽｺﾞｽです・・・。
とりあえず、見たい人用のために
上のメタセコイアファイルを用意しときました。Download file
(Parthenonは出力できるテクスチャがメタセコイアの第一マテリアルだけのようで
複数のマテリアルがあると、それぞれレンダリングしてやらないといけないようだ・・・)
遅ればせながら、トーンマップに対応しました。
というか、この手のレンダリングはトーンマップに対応しないと
話になりませんね・・・（結果がぜんぜんちが・・・
けっこう本物らしくなったのでよし！
上のファイルの中も更新しておきました。Download file
投稿者 kioku : 06:17
2005年10月29日
OpenGLサイト
OpenGLのお勉強サイトは数多くあるが
なかなか日本語サイトでデモで使えるレベルまで
詳しく書いてあるサイトはなかなか少ない。
まぁOpenGL入門者なら一度は見たことがあるであろう
GLUTによる「手抜き」OpenGL入門 は有名であるが、
この著者である床井先生の別サイト
床井研究室が最近熱い。
ちょっと前まではtexture関係だけだったけど
最近はGLSLについての記事が連載されてて
GLでシェーダをやるには非常に役に立つだろう。
というわけでメモメモ
投稿者 kioku : 02:31
2005年09月15日
OpenGL赤本
最近の私の書いてる64KB/4KBのコードはOpenGLをつかって
かいてるわけですが、今までずっと、いわゆるOpenGLの赤本(Ver1.1)
をよんでいたわけですが、
先日とある事情でOpenGLの赤本[英語版](Ver2)を手に入れたんですが
中身変わりすぎ！！
つーか、日本語版の情報古すぎます。
まぁべつに下位互換性があるOpenGLですから使えないわけではないですが、
それにしても、マルチテクスチャとか結構使いそうなところがないのが痛いですね
全体で200ページ弱増えてますから、結構な量だと思いますが・・・。
あと、微妙にいろんな挿絵がパワーアップしてます（w
日本語版の改訂版が出ないのは
赤本はいろいろ出版社が変わったりしてるんで、その辺の問題なんですかねぇ
まぁべつに日本語じゃないとよめないわけじゃないけど、
やっぱり日本語で読みたいですねぇ
GLSL（オレンジ）本はがんばって日本語訳してもらいたいですねぇ。
投稿者 kioku : 15:55