<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>little things of mine &#187; 開発</title>
	<atom:link href="http://www.ousam.com/blog/category/%e9%96%8b%e7%99%ba/feed" rel="self" type="application/rss+xml" />
	<link>http://www.ousam.com/blog</link>
	<description>from los angeles, california</description>
	<lastBuildDate>Sun, 01 Jan 2012 10:13:07 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>PyOpenGLでHDRピクセル</title>
		<link>http://www.ousam.com/blog/2011/04/03/711</link>
		<comments>http://www.ousam.com/blog/2011/04/03/711#comments</comments>
		<pubDate>Mon, 04 Apr 2011 03:36:14 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=711</guid>
		<description><![CDATA[久々に開発ネタです． 最近仕事で必要になり，10年ぶりくらいにOpenGLを触っています．PythonからPyOpenGL経由です．GPU出現以降のmodern OpenGLは真面目に書いたことがなかったので，勉強すること盛り沢山． PyOpenGL &#8212; The Python OpenGL Binding PyOpenGLでHDRIを扱う時にちょっと引っかかった問題があったので，忘備録を兼ねてここにまとめます．数年前からリアルタイムでもHDRレンダリングが流行っていたので，知っている人には今更な話題ですが．．． 解決にあたって@K240さんに多大なる助言を戴きました．有難うございます． さて，今時のVFXたるもの，ピクセル値はHDRがディフォルトです．[0, 1.0]ということはまずない．ライティングや反射マップにはほぼ必ずHDRIが使われるので，ハイライト部分は1.0を超えます．OpenGLでも普通に1.0を超える値は使えますし，GLSLシェーダでもfloating pointで計算ができます． ところが，一度ディスプレイバッファに値が書き込まれてしまうと，どうやらピクセル値は[0, 1.0]にclampされてしまうようなのです．具体的には，glReadPixels()を使って得られる値がclampされています．glCopyTexImage2D()なんかも同じ．これは困る． さらに調べを進めると，どうやらmodern OpenGLにはframe buffer object（FBO）という物があり，オフスクリーンの描画用バッファとして使え，更にデータタイプとして32-bit floating pointが指定できます．つまり，一度このFBOに描画することでシェーダを実行し，そこから値をコピーすることで生の計算結果を取得できます．ただしこのFBOはオフスクリーンなので，結果を画面に表示するには再度ディスプレイバッファに描画してやる必要があります． 計算結果をコピーするにはglGetTexImage()という関数を使うのですが，C言語ではこの関数は値を返さず，結果の書込み先としてポインタを渡すことになっています．しかしPythonにはポインタがありませんから，関数が値を返します．つまり次のように書きます．glGet*()やglGen*()系の関数は大抵こういう仕様になっています． result = glGetTexImagef(GL_TEXTURE_2D, 0, GL_RGBA) そして，ここでハマったのですが，上記で得たresultは三次元配列で，そのレイアウトは[y][x][c]（cはチャンネル）となっています．てっきり[x][y][c]だと思い込んでいたので，場所が一致せずに悩んでしまいました．．． 以下にサンプルコードを置いておきます．これは@K240さんがC++で書いて下さったコードをPythonに移植したものです．実行して表示される画面を左クリックすると，その場所の生ピクセル値がコンソールに出力されます． hdr_pixels.py 今回，GPUで色の計算（カラースペース変換とか）をやってみたのですが，さすがに速いですね．大きな画像だと普通にやるよりマジで何十倍も速いです．Pythonだと何百倍じゃないでしょうか．昔から3Dをリアルタイムでやる事にあまり興味はないのですが，2Dの画像処理を高速化するためにGPUを使うのは楽しそうだと思っています．コンプ作業が楽しくなりそう． 最近だとOpenCLとか使うんでしょうね？もう少し重たい計算もやってみたくなりました． [2011/4/6 追記] どうやらPyOpenGLのglGetTexImage()にはバグがあるようで，テクスチャが正方形でない時に関数が返す配列がおかしいです．ご注意下さい．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2011/04/03/711/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>オープンソースなCG関係ライブラリ</title>
		<link>http://www.ousam.com/blog/2010/10/16/639</link>
		<comments>http://www.ousam.com/blog/2010/10/16/639#comments</comments>
		<pubDate>Sat, 16 Oct 2010 10:33:42 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=639</guid>
		<description><![CDATA[思いついたので集めてみました． オープンソースと言うと幅が広いですが，自分が今まで見た事のあるVFX/CG系の会社やツールなどで実際に使用実績があり，プロジェクトの種類が（広い意味で）CG関係の物です．boostやQtなどのように一般に広く使われている物，CgやCUDA，FBXのようなフリーでもオープンソースではない物は除いてあります． * 画像・テクスチャ関係 OpenEXR OpenImageIO Ptex OpenFX OpenCV * シーングラフ OpenSceneGraph COLLADA * ジオメトリフォーマット Houdini GPD library GTO HDF5 Alembic * シミュレーションエンジン Bullet Physics Library ODE SOFA * 幾何学関係 Sony Vector Math Library Sony SIMD Math Library CGAL ANN こんなもんでしょうか．結構ありますね．最近は各スタジオが色々公開してますから，普及したらもっと増えるかな．あとはオーディオ関係もいくつかありましたが，良く知らないので除外しました． あ，「どれがどこ（なに）で使われているの？」系の質問は無しの方向でお願いします（笑）．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/10/16/639/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Alembic</title>
		<link>http://www.ousam.com/blog/2010/07/27/627</link>
		<comments>http://www.ousam.com/blog/2010/07/27/627#comments</comments>
		<pubDate>Wed, 28 Jul 2010 03:19:43 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=627</guid>
		<description><![CDATA[SIGGRAPH2010開催中のホットニュース． Alembic こちらでtaikomatsuさんが和訳されています． Alembic &#8211; memlog AlembicはILMとSPIが共同で開発及び公開した，アニメーションをシーケンシャルジオメトリにbakeするためのC++ライブラリです．&#8221;alembic&#8221;という単語には浄化器，蒸留器という意味があるそうで，必要な物だけを抽出する，というようなニュアンスですね． ライティングやエフェクトはアニメーションされたシーンを元にして作業するのが普通なのですが，アニメーターがアニメートしたままの状態だと，リグやその他たくさんのアニメーション以外には必要のないデータも含んでいるし，何しろリグを毎回プロセスするのは色んな作業の邪魔になります．エフェクトなんかはそうでなくても重い作業が多いですからね．シーンも不安定になります．そもそもツールが別でリグが渡らない事も多い．そのため，ある程度の規模のスタジオでは，内部で特定のデータフォーマットを使ってbakeしたアニメーションをやり取りする事が多いのですが，Alembicはそのデータフォーマットとして使う事ができます． シーケンシャルジオメトリのデータフォーマットは，今までこれといった決めてがなくて各スタジオがそれぞれ試行錯誤していると思います．GTOもかなり良さそうに思っていたのですが，AlembicはILMが絡んでいる事からして，GTOを更に改良した物（GTOは元々ILMで使われていた）と考えていいのかも？だとするとこれは良い候補になりそう． ただ，こう言ったプロセスは，ある程度のパイプラインがあって，開発サポートが期待でき，大きなシーンやショット数をこなす必要がある場合に必要になる事だと思うので，規模の小さな場合は逆に手間になってしまう可能性もあると思います．あと，日本の某社の方に教えられたのですが，小さい所ではストレージとネットワークがネックになってしまうとも言っておられました． 今の所，ライブラリの使用例としてMayaのimporter/exporterプラグイン，PRManのprocedural primitive DSO，GTOからのコマンドラインコンバータ，その他ユーティリティがライブラリと一緒に公開されているようです．Pythonバインディングも一応あるようですが，これはまだまだこれからという雰囲気． Houdiniのプラグインもないが，これは自前でやれという事か．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/07/27/627/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Open Shading Language</title>
		<link>http://www.ousam.com/blog/2010/01/14/595</link>
		<comments>http://www.ousam.com/blog/2010/01/14/595#comments</comments>
		<pubDate>Fri, 15 Jan 2010 04:16:27 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=595</guid>
		<description><![CDATA[OSLのソースと詳細がアップされたようです． fxguide quick takes » Sony Releases Open Source Shading Language openshadinglanguage &#8211; Project Hosting on Google Code ドキュメントのみサラッと読んでみましたが，RSLとは見た目こそ似ているものの，設計は随分違いますねえ．このままPRManが今のまま同じ仕様をサポートするのは難しいでしょう．まあ，逆に言えば古いしがらみに捕らわれていない分，新しい事ができる土台になると思います．シェーダがclosureであるとか，light samplingはレンダラ側でやるとか，色々と興味深い． ソースコードにはコンパイル済みシェーダの実行環境もライブラリとして含まれています．これを使って自分のレンダラにOSLを組み込む事ができますし，relightingツールなんかも作れそうですね． 今後の成長が楽しみであります．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2010/01/14/595/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OpenImageIO</title>
		<link>http://www.ousam.com/blog/2009/09/01/567</link>
		<comments>http://www.ousam.com/blog/2009/09/01/567#comments</comments>
		<pubDate>Wed, 02 Sep 2009 04:04:40 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/?p=567</guid>
		<description><![CDATA[同僚から，非常に興味深いライブラリを教えてもらいました． OpenImageIO Wiki いわゆる画像ファイルの入出力ライブラリで，OpenEXRやTIFF等，CG作業で良く使われるフォーマットに対応しています．各フォーマットのサポートは対応する外部ライブラリをプラグインする形で実現されますが，このAPIを通す事ですべてのフォーマットを一元的に扱う事ができます． と，これだけなら良くあるマルチフォーマット対応の画像ライブラリと同じで，特筆するような物ではないのですが，実はこのライブラリ，画像ファイルの部分読み，image cachingに加えてfiltered mipmap lookupまでサポートしているのです！ なんとマニアックな機能&#8230; と思ったのですが，それもそのはず，オリジナルの著者はLarry Gritzでした．恐らくは先日いくつかのオープンソースプロジェクトを公開した，某スタジオの某レンダラで使われているんだろうと推測されます． ざっと眺めた所，まだ改善の余地はたくさんありそうですし，実装されていない機能もあるようですが，賢いimage cachingを書くのはとても大変ですから，レンダラや自前の画像ビューアを書く時にはかなりの作業量を減らす事ができると思います． 画像の入出力って意外と面倒なんですよね．ずっと「コレ」っていうライブラリを探していたんですが，今のところ開発もアクティブみたいだし，どうやらこれが決定版になりそう． ライセンスはmodified BSD，商用利用もOKだそうです．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2009/09/01/567/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Imageworks Released Opensource Projects</title>
		<link>http://www.ousam.com/blog/2009/07/30/557</link>
		<comments>http://www.ousam.com/blog/2009/07/30/557#comments</comments>
		<pubDate>Thu, 30 Jul 2009 22:53:57 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/2009/07/30/557</guid>
		<description><![CDATA[いつの間に！ Sony Pictures Imageworks &#8211; Open Source どれもこれも面白そうな物ばかり．OSL(Open Shading Language)とかFIELD3D(Voxel data storage library)とか，出所が想像できるのでかなり期待できます． OSLはまだ中身がないみたいなので想像しかできませんけど，投稿者がLarry Glitzなので変な物は出てこないでしょう．これ，業界標準になりませんかねー．PRManとかmentalrayとかでサポートしてくれるようになると最高なんだけどなー． しかし，権利にうるさいImageworksがまさかこんな事をするとは．ちょっと前に上層部がゴタゴタしていたようだし，身売りの話もあったので穏やかじゃないなと思っていたんですが，方向転換したのかな． ただ，ページでコメントを載せているCTOのRob Bredowという人は，元々VFX Supervisorだった人で，かなり現場寄りかつテクニカルな人でした．最近CTOに昇格したというニュースを読んだのですが，この人の影響も少なからずありそうです． Imageworks，いい方向に変わってる感じがします．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2009/07/30/557/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Apollo</title>
		<link>http://www.ousam.com/blog/2007/03/26/471</link>
		<comments>http://www.ousam.com/blog/2007/03/26/471#comments</comments>
		<pubDate>Tue, 27 Mar 2007 04:39:19 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/2007/03/26/471</guid>
		<description><![CDATA[これまた興味深いモノが出てきましたね． Adobe Labs &#8211; Apollo ここ数日，ニュースサイトにも情報が溢れていますので，ご存知の方も多いと思いますが，ApolloはRich Internet Application(RIA)をスタンドアロンで動作させるためのランタイムだそうです．どうやら一般的なブラウザの機能＋Flashを丸ごと包含している感じ．さらにクロスプラットフォーム． 通常，GMailのようなWebアプリケーションの場合，ネットの繋がらない場所では当然ながら使用できない訳ですが，Apolloで動作するアプリケーションなら，サーバからデータが取得できないものの，アプリケーションとしては動作させる事ができる，つまり，新着メールの取得はできないが，(ローカルにデータを持っていれば)前のメールを読み返したり，それに返事を書いたりする事ができる，という事です． これって普通のスタンドアロンで実行可能なアプリケーションであれば当然の事なんでしょうけど，Webアプリケーションと同じフレームワークで作られたものが，スタンドアロンで動かせるというのは画期的な事ではないかと思います．サンプルアプリケーションのページでは，Flashをインターフェイスに使用した，たくさんの可能性を感じさせる例を見る事ができます． Apollo:Applications:Samples &#8211; Adobe Labs 開発環境としてはFlexを使うようです．これもSDK(コマンドラインコンパイラとデバッガ)が無償公開されました．これがあればテキストベースでのApolloアプリケーションが可能です． Adobe &#8211; Adobe Flex 2: Flex 2 SDK FlashのGUIデザイナーを含むIDE，Flex Builderは有料の製品． Adobe &#8211; Flex 2 &#8211; Webアプリケーション開発ソフトウェア 自分はFlashってあんまり好きじゃなかったんですが，最近のJavascript＋DHTMLなサイトを見続けていると，Flashの方がいいかな，とさえ思ってしまいます．どうしても「無理してる」感が拭えないんですよね．インターフェイスの遷移もスマートじゃない事があるし．その点ではFlashの方が綺麗に纏まっていると思います．時々やり過ぎなFlashサイトもありますが． Apolloはまだアルファ版だそうですが，Adobe謹製の技術だけあって，今後がとても楽しみです．今まで少々とっつき難かったWebアプリケーションの敷居が低くなったら嬉しいと思います．自分のように，何かやってみたくてもそれに付随する多くの準備や知識に圧倒されてしまっていた人も多いはず．Apolloなら少なくとも自前のサーバなんかは必要なさそうですし． Flexに良く似たオープンソースなフレームワークで，OpenLaszloなんてのもあるようですが，これはJavaの動作するサーバが必要みたいです．さらにブラウザ上での動作のみ． OpenLaszlo &#124; the premier open-source platform for rich internet applications そのうち触ってみよう．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2007/03/26/471/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>マルチコアとOpenMP</title>
		<link>http://www.ousam.com/blog/2006/01/16/356</link>
		<comments>http://www.ousam.com/blog/2006/01/16/356#comments</comments>
		<pubDate>Mon, 16 Jan 2006 08:03:21 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/blog/2006/01/16/356</guid>
		<description><![CDATA[先日発表されたIntel Macは，マルチコアCPUを搭載していました． そして，IntelはMac OS X向けIntel Compilerのベータ版を配布し始めたようです． 米Intel、&#8221;Intel Mac&#8221;向け開発ツールのベータ版を公開 (MYCOM PC WEB) Development Support for Intel-based Macs* &#8211; Intel® Software Network このIntelのコンパイラはOpenMPをサポートしているとの事．Appleの純正コンパイラであるGCCも4.2からOpenMPをサポートするようですし，Objective-Cでも使えるようになるんでしょう．そして，実はVC++ 8.0もOpenMPをサポートしています． OpenMP in Visual C++ 来たるべき総マルチコア時代の並列処理はOpenMPが標準のインターフェイスになりそうですね． OpenMP &#124; OpenMP: Simple, Portable, Scalable SMP Programming 自分はPthreadは知っていますが，OpenMPは全然知りません，これから勉強しなきゃ． 楽だって聞きますけど，どんなもんでしょ．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2006/01/16/356/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Code::Block</title>
		<link>http://www.ousam.com/blog/2005/11/25/313</link>
		<comments>http://www.ousam.com/blog/2005/11/25/313#comments</comments>
		<pubDate>Fri, 25 Nov 2005 13:00:14 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/__wp/?p=313</guid>
		<description><![CDATA[こんなの見つけました． Code::Blocks Studio &#8211; Open Source, Cross-platform Free C++ IDE WindowsとLinuxで動くIDEです．Dev-C++よりも少し良い感じ．wxWidgetsを使って書かれているそうです． 以前ならWindows用のこういうツールはそこそこ需要があったと思いますが，Visual C++ 2005 Express Editionが期間限定とはいえ無料になってしまいましたからねえ&#8230; まあでも，Visual StudioやEclipseはヘビー級アプリケーションなので，軽くてシンプルなのが好きな人には良いと思います． Code::Blockがちょっとイイ点．GNU Profilerがインテグレートされていて，GUIからプロファイルが取れます．結果の表示はグラフィカルじゃないけど，気楽に使えてなかなか良いです． ところで，2005 Expressは以前仕事で愛用していたDevPartnerのフリー版が使えないみたい． そのうち対応してくれるかな？]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2005/11/25/313/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Sun Studio 11 &#8211; 2</title>
		<link>http://www.ousam.com/blog/2005/11/22/311</link>
		<comments>http://www.ousam.com/blog/2005/11/22/311#comments</comments>
		<pubDate>Tue, 22 Nov 2005 12:45:22 +0000</pubDate>
		<dc:creator>ますお</dc:creator>
				<category><![CDATA[開発]]></category>

		<guid isPermaLink="false">http://www.ousam.com/__wp/?p=311</guid>
		<description><![CDATA[我慢できなかったので使ってみました(笑)． 環境はWindows上で動くVMWare Workstaion（evaluation lisence）で，ゲストOSはCentOSです． これ，やっぱりJavaで動いてました．起動時のスプラッシュ画面に&#8221;built on NetBeans&#8221;とか書いてあるし．使えない程遅いわけじゃないけど，快適とは言い難いです． ビルドはGCCとMakefileを使って行われます．Makefileの生成は自動化されていますが，AutoconfやAutomakeには未対応． エディタは非常に原始的で，色分けこそ行われるものの，IntelliSenseの様な関数名とその仕様まで補完してくれるような機能は付いていません． 期待していたデバッガとプロファイラは必要十分です．特別優れた所は見当たりませんが，ツールの一部としてシームレスにインテグレートされているのが良い感じ． ただ，やっぱりウインドウの切り替えとかダイアログの表示なんかが結構モタつくので，これで開発は正直ちょっと辛いかなあ． うーん，期待した分だけ残念です．]]></description>
		<wfw:commentRss>http://www.ousam.com/blog/2005/11/22/311/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

