gl.processing途中経過 (愚痴っぽい。長文であまり価値がない。たぶん)

scheme opengl

前書き

今の作業の延長線上に開発のゴールが見えないような気がした。今までprocessingと対応づけるように機能を充実させてきたけれど、実装が進むにつれて、基盤としているopenglとprocessingとの際による挙動のズレが大きくなってきた。そのズレは強引に修正することができないわけじゃないけれど、それでは劇的にパフォーマンスが低下することが予想されそう。堆積している問題の切り分けも今のところができていない。そんなわけで、少し途中経過のようなものを書いて頭の中を整理しようと思う。

以下のような内容を書く予定

  • gl.processingが目指していたもの
  • 現在のgl.processingでできること
  • gl.processingの利用方法
  • 現在のgl.processingが抱える問題
  • 今後の作業の方向性

gl.processingが目指していたもの


gl.processingが目指していたものは、「自分のイメージを手軽に表現するためのツール」だった。この種のツールはproce55ingをはじめとして色々あるけれど、それぞれ実装された言語も利用する際の記述方法も微妙に異なる。そして、個人的な意識として「人によって自分の脳内イメージとそれぞれの言語との距離感が異なる」と思っている。脳内のイメージとの距離が近い言語の方がアイデアをそのまま形にしやすい。例えば、pythonとrubyはよく似たものとして扱われるけれど、それを書いている時の頭の中の状態というのは、かなり違っているような感覚がある(もちろん、学校の講義でjavaなどのコードを書いている時などでも)。そんな中で、自分にとって一番しっくりとくる言語がschemeだった。そんな自分にあったツールを自分で作りたいと思った。
e
また、ビジュアルアート的なもの、いわゆる「表現」というものに憧れていたりもした。けれど、スクリプト言語にスポイルされてしまった頭では、openGLを直接書き下すというのは避けたい事柄だった。何というか面倒くさい*1。「丁寧に正しい記述を書いた。その結果想定した通りの絵が現れた」というようなものではなく、「こうやってみたらどうだろう？あーやってみたら？…というような形で、思いもよらなかった絵」を手にすることのできる環境が欲しいと思った。proce55ingは便利ではあるのだけれど、何だか左利きなのに右手で文字を書かせられているような感覚になった。

一方で事前の準備や特定の用途のためのツールというものの存在から逃げていたかった。ActionScriptとかadobe関連のツールなどは、始めようにもどこから手をつけて良いのか分からないし、自分自身がツールを使っているのか、それともツールの指示どおりに単に自分自身が動いているだけなのか良く分からなくなりそうだった。うまく言語化できないけれど、自分自身の興味は表現活動自体ではなく、表現を作成する際に行われる自分自身のワークフローを見直すことで、それ自体を自分なりにアレンジしたいのだけれど、正当な使い方というものをツール側に要求されてしまっているような不安感*2を持ってしまい、それから逃げていたかった。

javascriptを使った作業というのもおもしろいとは思うけれど、実行時の階層構造が複雑過ぎて(依存するレイヤが多すぎて)、問題が発生した時にjavascript側の問題なのか、webの仕様側(html,css .etc)の問題なのか、それとも現在書いているコードのロジック側の問題なのかよく分からなくなりそうだった。そしてweb関連の情報は膨大過ぎて、とてもじゃないけれど、片手間に趣味としてやっていける量じゃない。複雑な階層構造の中でどの箇所にエラーが発生しているのか判断すること自体は楽しい作業かもしれないけれど、その行為だけで自分の時間が占領されてしまうような感じがする。(仕事として割り当てられたら嬉々として取りかかるのかもしれない)

現在のgl.processingでできること


現在のgl.processingでできることは以下の事柄。openGLを使っているがしばらく3Dに対応させる気はない。

  • draw$/draw-once$を利用したアニメーション／絵の生成。
  • 実行結果を画像として保存(アニメーションを保存する方法はない)
  • jpg,png,bmp..などの形式の画像ファイルを読み込み、テクスチャとして利用
  • 日本語フォントも含めた文字の表示(後述する座標系との関連で問題あり)
  • 座標系の手軽な変換(gl:(0,0)が左下隅, processing:(0,0)が左上隅、 math:(0,0)が中央)
  • processingに合わせた機能
    • マウスの入力をprocessingと同様の形式で取得可能(現在位置のx座標を*mouse-x*でなど)
    • rect,triangle,ellipseなどの簡単な図形描画関数
    • 図形描画の際には、縁をstroke,内部の色をfillで変更できる。

ただ、色々問題も抱えている。

gl.processingの利用方法

開発はubuntu(10.4)上で行っている。今のところは、ubuntu以外の環境では動かないかもしれない。

依存しているものは以下。

  • gauche(0.9以上)
  • openGL,imlib2,quesoglc
  • その他bingings
    • gauche-gl(openGLを利用するため)
    • gauche-imlib2(画像の読み込み／保存)
    • gauche-quesoglc(日本語フォントの表示)


gauche-imlib2とgauche-quesoglcは、gl.processingのために自分で作成した拡張ライブラリなので、gl.processingと同様にあまりできがよくない。

インストール方法

まっさらなubuntuからgl.processingが利用可能な状態にするには以下を実行すれば良い。これ自体は、virtualbox上で新たにubuntuを入れ直して、調べてみたので漏れはないと思う。

### install gauche and git
sudo aptitude update
sudo apt-get build-dep gauche gauche-gl
sudo apt-get install wget gauche git-core
mkdir box && cd box

wget http://prdownloads.sourceforge.net/gauche/Gauche-0.9.tgz
tar zxvf Gauche-0.9.tgz
cd Gauche-0.9
gauche-config --reconfigure | sh
make && sudo make install
cd ../

### install gauche-gl
sudo apt-get install freeglut3-dev libglew1.5-dev
sudo apt-get install libxmu-dev libxi-dev
wget http://prdownloads.sourceforge.net/gauche/Gauche-gl-0.4.4.tgz
gauche-package install --install-as=root Gauche-gl-0.4.4.tgz

### install gauche-gl-processing
sudo aptitude install libimlib2 libimlib2-dev libglc-dev libglc0 
git clone git://github.com/podhmo/gauche-imlib2.git
cd gauche-imlib2 && ./configure && sudo make install && cd ../
git clone git://github.com/podhmo/gauche-quesoglc.git
cd gauche-quesoglc && ./configure && sudo make install && cd ../
git clone git://github.com/podhmo/gauche-gl-processing.git
cd gauche-gl-processing && sudo make install
実行結果


一部分異なっているところがあるかもしれないけれど、過去の日記を見ればどのようなことができるかは分かる。

現在のgl.processingが抱える問題

あとでくわしく書く。

  • processingの座標系でフォントが上下反転してしまう。
    • ビットマップ形式では適切な表示が行われる。
    • 他のテクスチャと同様にGL_TEXTUREの行列をいじる方法で対応すると、消えてしまって表示されない。
  • テクスチャを取りあつかうインターフェイスが良くない。
  • transparency(透明)の取扱い
    • 背景(background)にアルファ値を設定することができない
    • フォントが対応していない(processingの座標系で,テクスチャをりようできないので)
    • テクスチャを細かな方法でblendすることができない。
  • set!とグローバル変数による状態管理が見にくい。
    • 内部のコードの記述のこと。一応利用者には見えないようになっているけれど。
  • 全体的に名前に統一性がない。
    • textureを貼り付けた四角形を表示する関数がdraw-shape
    • fill,rectは破壊的操作なのに!がない。(rect-mode!,no-fill!などには!が存在)
    • オプションを*-modeはsymbolで渡すのに対し、一部のものはkeywordで渡している

今後の作業の方向性

あとでくわしく書く。

思ったこと

プロジェクト管理はやっぱり大切なのかもしれない。
documentationはやっぱり重要なのかもしれない。
issue tracking systemはやっぱり必要なのかもしれない。

*1:openGLでいきなり作ろうとする際の気持ちとしては、「まだ正解が何か分かっていないのに、どうして清書しなくてはいけないの？」というような感覚。

*2:不快感というよりも、自分は本当にこのツールを正しく使っているのだろうかというような不安感