はてなブックマーク

• あとで読む

  lucille development blog » Blog Archive » Processing で学ぶレンダラ… の始めをちょっとだけ.

  3 users

  lucille.atso-net.jp

  Proce55ing で学ぶレンダラプログラミング, 通称 GI 本ですが, 導入はこんな感じでやっていこうかなぁと思います. 初めての Processing 本書では、大域照明レンダラを書くためのプログラミング環境として Processing を利用します. Processing は元々インタラクティブアートのために設計されたプログラミング環境ですが、 クロスプラットフォームのグラフィックスプログラミング環境として利用することもできます. 「GI レンダラを書くのに必要なものは何かッ!?」 … なんと、OpenGL とか DirectX とか SDL とかそんな 3D API やグラフィックス API はじつはまったく必要ありません. ピクセル単位で色を設定する方法があれば何でもいいのです. そして Proce55ing にはそのような機能が備わっており、しかもかんたんに利用で

  • 暮らし
  • 2009/06/03 00:11

  • graphics
• あとで読む

  lucille development blog » Blog Archive » Visualizing Haskell

  5 users

  lucille.atso-net.jp

  おぉッ！すげー！ Haskell 使うとこんなゲームも書けるのか！ すげー！内部データ構造を視覚化! 3D も容易に! マウスいらずの最先端タイルベースウィンドウマネージャも Haskell で書かれています. うぉー！ まとめ こうして視覚化してみると、Haskell すげー！

  • 暮らし
  • 2009/05/09 09:05

  • haskell
  • visualization
  • game
• あとで読む

  lucille development blog » Blog Archive » レンダリスト面接時の技術的な質問事項(レンダラ財団版)

  6 users

  lucille.atso-net.jp

  (via philo 式) philo 式で取り上げられていた プログラマー面接時の技術的な質問事項(アプレッソ版)をレンダラ野郎向けにもじってみました. ■ 開発実績編 まず、Maya を知っている•RenderMan を知っているなどよりも、どんなものを作れるか、どんなことができるか、という質問。 - hair のレイトレを高速化したいんだけど、良いアイデア無い? - レイトレでモーションブラー早くしたいんだけどさ、もっといいモーションブラー高速化のためのデータ構造ない？ ここで強烈な回答が来る人は、まあ即採用ですよね. ■ 光輸送方程式導出編 次に、言語に依存しない光輸送方程式導出の基本の部分で、分かっていないとクリティカルなバグが混入する可能性があるような内容についての確認。 - LS+DS+E 経路の解法における潜在的な困難点は? (実際、これが原因でパフォーマンスが数

  • 学び
  • 2009/03/03 06:55

  • cg
  • ネタ
  • あとで読む
• あとで読む

  lucille development blog » Blog Archive » Appcelerator’s Titanium = Cross platform beautiful GUI framework?

  8 users

  lucille.atso-net.jp

  Appcelerator’s Titanium = Cross platform beautiful GUI framework? 長年のクロスプラットフォーム GUI ツール探しの旅が、ようやく一つの終わりになりそうだ. fltk, wx, gtk, etc いろいろ試してきたが、 クロスプラットフォームで open source で, beautiful でカスタマイズ可能なルックも実現できる GUI ツールキットには なかなか出会えませんでした(かといって自作するのはまたそれですごい労力) Qt4.5 が LGPL になるということで、おお、これは Qt かな、と思っていましたが、 ここに来て超期待の新人が現れました. その名も Titanium http://titaniumapp.com/ まあまずはデモビデオを見てほしい. Titanium Developer: Ge

  • 暮らし
  • 2009/02/27 03:29

  • gui
  • framework
  • development
• あとで読む

  AO bench

  16 users

  lucille.atso-net.jp

  Introduction AO bench is a small ambient occlusion renderer for benchmarking realworld floating point perforance in various languages. AO bench is originally coded in Proce55ing. AO bench consists just about 400 lines of code and requires only standard math functions, therefore it is easy to understand and port AO bench for your favorite language. Languages and performances Here’s list of language

  • 暮らし
  • 2009/02/11 15:05

  • benchmark
  • rendering
  • aobench
  • programming
  • プログラム
  • dev
  • ActionScript
  • language
  • C++
• あとで読む

  lucille development blog » Blog Archive » Scrap your boilerplate

  3 users

  lucille.atso-net.jp

  Scrap your boilerplate http://www.cs.vu.nl/boilerplate/ “Scrap your boilerplate” と呼ばれる、Haskell 向けのジェネリックプログラミングライブラリを知りました. Haskell におけるデザインパターンとも言えるでしょうか. Haskell で RSL(RenderMan Shading Language) コンパイラを書いていると、AST(抽象構文木) などのツリー構造なデータ型の一部にだけ作用させたいコードが必要なときがよくあるのですが、この scrap your boilerplate がまさにそれを解決してくれることが分かりました. たとえば、以下ような例を考えます. replaceConst 関数は Expr の Const ノードを Var ノードに置き換えます. Expr や Stmt は

  • 学び
  • 2009/01/19 11:07

  • haskell
  • library
  • programming
• あとで読む

  lucille development blog » Blog Archive » Etymology of “normal”

  3 users

  lucille.atso-net.jp

  (image from Wikipedia) 「法線ベクトルとは、面に垂直な方向を指すベクトルである」 よくある 3D CG の教科書に見られる、法線(normal)に間する説明の記述ですね. でも、「法線」の「法」ってナニ？ normal って「普通」という意味なんだから、「普通のベクトル」じゃないの？なぜ CG だとこれが「法線」というという意味になるの？ CG を習い初めたひとにとっては, こんな疑問をいだきつつも、「まあこのギョーカイではそんなことになっているんだな」と妙に理解したことにしてしまって今に至るひとが多いのではないでしょうか？ 私自身もまだ右も左も分からぬレンダラ一年生だったとき, なぜ normal が面に垂直なベクトルを意味し、そしてそれが法線と訳されるのか疑問でした. そこで、ちょうど GI 本を執筆するに当たっていろいろ資料や語彙の由来などについて調査していた

  • 学び
  • 2009/01/12 19:12

  • mathematics
  • 3dcg
• あとで読む

  lucille development blog » Blog Archive » Approximating Dynamic Global Illumination in Image Space

  4 users

  lucille.atso-net.jp

  (image from “Approximating Dynamic Global Illumination in Image Space”) Approximating Dynamic Global Illumination in Image Space Tobias Ritschel, Thorsten Grosch, Hans-Peter Seidel Proceedings ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games (I3D) 2009 http://www.uni-koblenz.de/~ritschel/ うぉっ！　これはすげー! - スクリーンスペースなのでジオメトリの複雑さと無縁 - 動的ジオメトリ可 - 前計算なし - GPU に容易に実装可能 で近似的に GI (1 回の ind

  • 学び
  • 2009/01/07 13:45

  • prog
  • *programming
  • 3D
  • tech
• あとで読む

  lucille development blog » Blog Archive » Suicidator City Engine

  6 users

  lucille.atso-net.jp

  (The city model is generated by Suicidator City Engine. Rendered by lucille) Suicidator City Engine http://blenderartists.org/forum/showthread.php?t=140415 [Ja] Blender スクリプト(python)で実現した都市ジェネレータ. SIGGRAPH 論文で発表された cityengine のようなものを実装したものといえば分かるひとは分かるでしょうか. デフォルトの設定で generate するだけでも, ポリゴンに落とすと大体 100 万ポリゴンになります. ちょっとしたレンダリングパフォーマンステストにいいかも. (細かい窓の間隔などは、アンチエイリアシングのテストにも適していると思います)

  • 世の中
  • 2008/12/24 09:31

  • 3D
  • プログラミング
  • graphics
• あとで読む

  lucille development blog » Blog Archive » Ambient Occlusion demo for NativeClient

  3 users

  lucille.atso-net.jp

  NativeClient (NaCl) と呼ばれる x86 バイナリをほぼそのままブラウザで実行できるフレームワークが出たので、AO bench を NaCl に移植してみました. http://lucille.atso-net.jp/nacl/ao.html (NativeClient プラグインがインストールされている x86 マシンである必要があります. 処理速度が早いので、せっかくですからマウスでいじれるようにインタラクティブにしてみました) source http://lucille.svn.sourceforge.net/viewvc/lucille/angelina/nacl/ao/ 速度ですが、処理時間をブラウザに戻す仕組みがよくわからなかったので目視レベルで確認しました. ブラウザで動かしても速度がネイティブとちがうということはないです. 速度低下がほとんど無

  • 暮らし
  • 2008/12/11 08:05

  • programming
• あとで読む

  lucille development blog » Blog Archive » Alchemy too slow…?

  3 users

  lucille.atso-net.jp

  LLVM を使って C のプログラムを Flash で動かせるようにした Alchemy がリリースされ、Alchemy はパフォーマンスが必要なプログラムに向くということで、 AO ベンチマークを取ってみました. ベンチマークに使ったのは AmbientOcclusion レンダラの C 版. http://lucille.svn.sourceforge.net/viewvc/lucille/angelina/proce55ing/c_reference/ C(gcc4.4 -O3) : 2.6 secs Alchemy : 480 secs(8 分) (参考: 前回のパフォーマンス比較) う、遅すぎ… さらに、AS3 版 AO の 8 倍も遅い… Alchemy 版は、以下の手順でコンパイルして速度を計りました. $ alc-on $ gcc -O3 ao.c $ time ./a.

  • 世の中
  • 2008/11/23 22:22

  • alchemy
  • as3
• あとで読む

  lucille development blog » Blog Archive » CPU performance of Amazon EC2 instances.

  4 users

  lucille.atso-net.jp

  ちょっとそろそろ lucille を使ってクラウドレンダリング(cloud rendering)　を やってみようかと考えているので、まずは Amazon EC2 のインスタンスの CPU パワーはいかほどか、調べてみました. 測定をした CPU インスタンスは, Standard instances から small, それから High-CPU instances から medium と xlarge です. http://aws.amazon.com/ec2/instance-types/ ベンチマークプログラムは himeno bench, コンパイラは gcc 4.2.3, コンパイルオプションは -mfpmath=sse -msse2 -mtune=native -O3 -DSMALL として、SSE 命令を明示的に使うようにしています(No more x87!).

  • 世の中
  • 2008/11/14 13:01

  • cloud
  • EC2
• あとで読む

  lucille development blog � Blog Archive � iRender : Global Illumination with iPhone.

  7 users

  lucille.atso-net.jp

  I’ve ported ambient occlusion renderer to iPhone as a OpenGL ES application. http://lucille.svn.sourceforge.net/svnroot/lucille/angelina/irender irender.tar.gz (project files) The renderer core itself is simple and I already ported it to many platforms. - Proce55ing - Flash10 - JavaScript - Performance comparison Unfortunately I haven’t real iPhone, so I just tested that the renderer runs corr

  • 学び
  • 2008/11/09 03:50

  • iPhone
• あとで読む

  lucille development blog » Blog Archive » Introduction to type inference

  8 users

  lucille.atso-net.jp

  JS 実装をしようかな、と思い立ち、 まずは型推論の知識をしっかり取得するところから初めようと考えています. そもそも、型推論とはなんぞや、というところからおさらいしてみます. 私が型推論について知りたいことの一番の目的は、 「型推論を行うことで動的言語の事前コンパイルを可能にしプログラムの実行を早くすることができるのではないか」, ということになりますので、それに特化した内容になっています. もちろん型推論には、プログラムを早くするという以外の目的もありますが、 ここではそれらは取り上げないことにします. 型推論(type inference)とは、簡単に言うと、 var muda = 7 というコードがあったら、 「変数 muda って Int 型(整数型)じゃね？」 とコンパイラがよろしく変数の型を決定してくれる(推測してくれる)機能になります. 静的な関数型言語(Ocam

  • 学び
  • 2008/11/03 03:59

  • 型推論
  • Ruby
  • JavaScript
• あとで読む

  lucille development blog » Blog Archive » JavaScript 実装、始め…るかも…

  7 users

  lucille.atso-net.jp

  JavaScript の実装をしようかな… と思っています. 理由 現状 Maya などの 3D CG のパッケージなどでは拡張用のスクリプト環境として Python が使われるようになっています. 将来を見据えると 3D CG パッケージもどんどん web 化していき、拡張用スクリプティング環境は JS などの web 言語と統一していくことが見込まれます.それに使う言語が統一されていればユーザにとっても学ぶことが少なくていいでしょうし. (将来のグラフィックス言語は関数型、とは別に、もう少し現実的にあり得る方向性として) また、3C CG 向けに限らずとも、拡張用スクリプト言語は動的言語(or 動的型付けな DSL)というのが主流になっていくと思っている. そのとき、JS もしくは動的言語の実装系が非力では困る(すでに Python でも CG 系の演算処理を行うには非力である).

  • 世の中
  • 2008/10/14 03:54

  • javascript
  • later
  • cg
  • language
• あとで読む

  lucille development blog » Blog Archive » Rendering with Proce55ing.

  9 users

  lucille.atso-net.jp

  Ambient Occlusion rendering (Java applet. Java is launched) [En] I’ve been planning to write a good introduction to theory and practice of global illumination rendering with literate programming style and seek for good language to implement, teach and learn global illumination algorithm. And now, I finally found Proce55ing is a good candidate for the language. Although Proce55ing is primary design

  • 世の中
  • 2008/10/11 23:24

  • Rendering
  • Programming
  • 3dcg
• あとで読む

  lucille development blog » Blog Archive » Playing with pyparsing

  6 users

  lucille.atso-net.jp

  そろそろ yacc/lex でパーザを書くことに限界(コンフリクトやメンテナンス性)を感じているので、パーザコンビネータなどでコンフリクトがなく、またメンテナンスしやすいパーザプログラミング手法に注目しています. Haskell の Parsec や、 Packrat パーザがそのようなコンフリクトがなくて、かつメンテナンスしやすいパーザ記述手法になるようです. 最近はかなり Python っ子なので、同様なものが Python でないか探したところ、pyparsing という同様なことができるライブラリを見つけました. http://pyparsing.wikispaces.com/ Packrat なパーザも制限がありますがサポートされています. pyparsing を使って簡単な四則演算パーザを作ってみました. それぞれの項 or 式で AST(Abstract Syntax Tr

  • 学び
  • 2008/10/05 20:11

  • python
• あとで読む

  lucille development blog » Blog Archive » Language.C : A C99 library for Haskell

  4 users

  lucille.atso-net.jp

  (via reddit.com) http://www.sivity.net/projects/language.c/wiki/ Language.C is a C99 library for Haskell, and recent report says that Language.C can parse 18 million lines of pre-processed source without a hitch. Parsing the Linux kernel with Haskell: experience with Language.C [Ja] Haskell の Language.C という C99 パーサ•解析モジュールが結構使えそう. Linux カーネルのソースを、(プリプロセス後のソースに対して)問題なくパースできるほどの機能を持っている. パーシングの速度は

  • 世の中
  • 2008/09/23 11:26

  • Haskell
  • lib
  • c
• あとで読む

  lucille development blog » Blog Archive » Curious x86 call instruction.

  3 users

  lucille.atso-net.jp

  (更新: 解決しました) Compile this test program, with gcc -O2 -c which results in following x86 assembly. I got curious call instruction(call 0×9). What does this call stands for? It seems that this call insn is used to align stack or PC(program counter). [Ja] x86toLLVM を作ろうとしていて x86 アセンブラと戯れていたら、 不思議な x86 アセンブラに遭遇しました. 上記の 5 行目の call 命令です. 特段関数を呼ぶためでもなくて、単純に 4 バイト目から 9 バイト目に飛んでいるだけ. このテストプログラム以外にも、結構い

  • 学び
  • 2008/09/12 02:43

  • x86
  • Intel
  • CPU
  • Programming
• あとで読む

  lucille development blog » Blog Archive » x86toLLVM?

  5 users

  lucille.atso-net.jp

  V8 の吐くアセンブラは最適化されていないと書いたが(link)、ここで、第一回 LLVM 勉強会のときにもすこし話題に上がったけれども、x86 命令を LLVM IR に変換するディスアセンブラとかあるとおもしろいかもしれない. それがあると、たとえば V8 に対して、 JS -> (V8 x86 backend) -> x86(unoptimized) -> (x86 to LLVM backend) -> LLVMIR -> (optimize & LLVM x86 backend) -> x86(optimized) という、最適化されていない x86 命令があら不思議、最適化された x86 命令に変換されてさらに V8 が高速化されました、ということができる. ただ LLVM はでかいしメモリを食うので、このような変換は組み込みデバイスでやるのは難しくて、デスクトップでの用

  • 暮らし
  • 2008/09/07 09:42

  • LLVM
  • Programming
• あとで読む

  lucille development blog » Blog Archive » V8 benchmarked

  28 users

  lucille.atso-net.jp

  最近はシェーダ JIT の可能性をいろいろ探索するためにコンパイラ技術を調べています. 論文を読んでいると、JIT 技術の研究コミュニティが目指しているひとつの行き先は動的言語の高速実行であることが分かる. ちょうど Google Chrome の JavaScript エンジン V8 がなんか早いらしいということで、 すこし中身をしらべ、BlackScholes 計算でベンチマークを取ってみました. V8 V8 の実行性能については、 John Resig 氏のサイトに比較がいろいろあるので参照してほしい. http://ejohn.org/blog/javascript-performance-rundown/ ベンチの内容にもよるのだが、Chrome ベンチを除けば、 Tracing JIT による TraceMonkey と大体同程度のパフォーマンスを実現している. V8

  • 暮らし
  • 2008/09/05 03:28

  • v8
  • jit
  • javascript
  • programming
  • VM
  • benchmark
  • プログラミング
  • performance
• あとで読む

  lucille development blog » Blog Archive » Larrabee paper review

  5 users

  lucille.atso-net.jp

  http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf 読みました. 結論. 性能は微妙. レイトレアクセラレータロジックはなしのよう. 開発は楽なのが唯一の救いか. Larrabee 構成概要 なんとも普通. そりゃ CPU メニーコアなので普通になりますね. gather/scatter VPU のインストラクションは L1 のアドレスをソースオペランドに取ることができる. 非連続アドレスからのロード(gather)と非連続アドレスへのストア(scatter)をサポートしている。 ただしキャッシュの速度に制限されるので、たとえばすべての要素が異なる場所を示していれば(データが L1 にキャッシュされているとして)最悪 16 サイクルはかかることになる。 ただし実際はそれなりにコヒー

  • 学び
  • 2008/08/06 01:02

  • Larrabee
  • CPU
  • CG
  • プログラミング
  • Programming
• あとで読む

  lucille development blog » Blog Archive » Are you still parallelizing your code by hand?

  3 users

  lucille.atso-net.jp

  Are you still parallelizing your code by hand? If so, look at this. This is a promising research which makes your sequential program into multi-threaded program automatically. Matthew J. Bridges, Neil Vachharajani, Yun Zhang, Thomas Jablin, David I. August. “Revisiting the Sequential Programming Model for Multi-Core”. Proceedings of the 40th IEEE/ACM International Symposium on Microarchitecture

  • 世の中
  • 2008/07/28 18:58

  • Algorithm
  • Programming
• あとで読む

  lucille development blog » Blog Archive » LLVM 勉強会第一回開催通知 8/23(土)

  4 users

  lucille.atso-net.jp

  LLVM は実務的かつ新進的なコンパイラインフラです. いずれ gcc を駆逐し(?)、LLVM 帝国が建国されるのは時間の問題と言われていいます。 そんな機運の中、LLVM の 勉強会第一回の日程を設定しました. 8/23(土)、恵比寿にて開きます. 詳細はこちら. http://groups.google.co.jp/group/llvm_study/ web/%E7%AC%AC%E4%B8%80%E5%9B%9E+llvm+%E5%8B%89%E5%BC%B7%E4%BC%9A - LLVM に興味があるけどどんなのかしっかり知りたい - オレ様の LLVM 利用例をぜひ発表したい - LLVM で○○やりたいけどどーすればいいかわからん。行ってやるから教えろ。 などなど、LLVM 野郎、LLVM 野郎になりたい！と思う方はぜひともご参加ください. —- グラフィックス野

  • 世の中
  • 2008/07/26 14:29
• あとで読む

  lucille development blog » Blog Archive » LLVM および自動最適化の勉強会を開きたいなと考えています

  10 users

  lucille.atso-net.jp

  (追記: LLVM 勉強会,やります) LLVM の勉強会、また自動最適化の勉強会みたいなのを開こうかなぁと考えています. LLVM 勉強会 LLVM については、まずはなんだかみんなまだよく知らないようだしちょっと誤解しているみたいなので, これを機会にしっかりと知るといいんじゃないかな、というのがある。 (ただ、私は LLVM コミッタとかではなくて、外野にいる一ユーザです) 加えて、私としては自動最適化ともからんでくるけど実行時最適化(JIT, partial evaluation)を 自分のプログラムに取り入れたいときに LLVM コンパイラインフラがすでにある物としては practical で十分な feature を持っているので使っていこうかなと思っていて、 そのためにそこらへんをもう少しよく知って共有したいから. 次に自動最適化の勉強会. もう手作業で最適化の時代

  • 学び
  • 2008/07/14 01:43

  • LLVM
  • programming
  • 勉強会
  • language
  • event
  • software
• あとで読む

  lucille development blog » Blog Archive » code_swarm & CodeCity

  3 users

  lucille.atso-net.jp

  code_swarm http://vis.cs.ucdavis.edu/~ogawa/codeswarm/ code_swarm - Python from Michael Ogawa on Vimeo. code_swarm はソースコードコミットの履歴を視覚化してくれる。 プログラムは proce55ing で作られている. python は、最後(最新)のほうはもうカオスやね(アクティビティがすごい)、もうなにがなんだかだかよくわかりません CodeCity http://www.inf.unisi.ch/phd/wettel/codecity.html こちらはソフトウェアソースコードのメトリックを OpenGL で視覚化してくれるツール. パッケージ、メソッドの個数などで都市の出来かたが変わる。 モジュールやメソッドの構成に偏りが無いかなどのチェックに使えるかも. Yo

  • 暮らし
  • 2008/07/02 06:13

  • visualization
  • programming
• あとで読む

  lucille development blog » Blog Archive » Falling in love with Python

  6 users

  lucille.atso-net.jp

  DSL(Domain Specific Language) というやり方を取り入れていこうと考えたあたりから、 Load to MUDA. SIMD code generation, domain specific language, automatic optimization, functional programming, etc. いろいろなコード自動生成や、テスト環境、かんたんなコンパイラ/トランスレータなどを作っていく 上で、Python をかなり使うようになってきました。 使いこなすにつれ、Python はいい言語だなぁと感じるようになりました。 C に比べてとても生産性が高いです。コンパイル時間もかからないし。 パフォーマンスさえ問題でなければ、もうぜんぶ Python でいいんじゃねと最近は思います。 (関数型言語はまた別腹ね) 私が Python を始めた理由は

  • 世の中
  • 2008/05/20 01:43

  • python
• あとで読む

  lucille development blog » Blog Archive » Playing with Pure

  4 users

  lucille.atso-net.jp

  http://pure-lang.sourceforge.net/ コンパイルが通ったのでちょっと遊んでみました. Pure 言語とはなんぞや Pure とは、和○○○○主演のドラマで,,, と 信頼関係のコントのネタに出てきそうですが、 そうではなくて、 項書換え(term rewriting)ベースの関数型言語です。 Pure 言語の開発者は、同じような特徴の言語として、 Q 言語をすでに開発していますが、 Pure 言語はそれの後継を目論んでいるようです. Pure 言語が Q 言語と異なるところは、 先進的な言語的特徴を取り入れているところと、 LLVM バックエンドの採用で高速に実行できるところです. (どんだけ高速に実行できるのかは不明) また LLVM バックエンドを採用していることで、 C 言語との親和性も高いです. とりあえず使ってみる pure 言

  • 世の中
  • 2008/05/05 18:39

  • llvm
  • programming
  • math
  • dev

次のページ