OpenGLのフィードバックに続いて、今回はOpenGLのレコーディング、つまり、OpenGLの描画を記録してムービー・ファイルにする方法です。実は、3月に映像作品の上映が予定されていて、これがなんと初体験のDVD納品（＝ノン・インタラクティブ）なものだがら、いろいろと研究しているところです。フツーの映像作家や音楽家にとっては簡単なことが、インタラクティブ系の人には面倒だったりしますが、これはその典型ですね。

というわけで、学生クエストならぬ自分クエストであるOpenGLのレコーディングとして、4つの方法を考えました（他にもあったら教えてね）。

(1) 自力でパッチを作成する。
(2) 他人様のパッチを利用する。
(3) スクリーン・キャプチャを使う。
(4) スキャン・コンバータを使う。

(1)の自力作成に関しては、要はOpenGLが描画した画像をマトリックスにすれば、jit.qt.recordでムービー化できるわけですね。具体的なパッチは次のようになります。ダウンロードはこれopengl-recordingpat.zipです。

このパッチのように、jit.gl.sketchにglreadpixelsメッセージを送っておけば、アーギュメントで指定した名前のjit.matrixからマトリックスを取り出すことができます。ただし、OpenGLとマトリックスはY軸の方向が逆なので、jit.resampなどを使って画像を上下反転する必要があります。

あとはjit.qt.recordでムービーに書き出すだけですけど、qmetroの時間間隔やリアルタイム録画の可否、そしてwriteメッセージでのフレーム・レートを適切に設定する必要があります。変な設定だと、妙に動きが速いムービーになったり、必要以上にファイル・サイズが大きなムービーになっちゃいますよ。このあたりのことは2061:Maxオデッセイ（p.781）参照ね。

ちなみに、jit.qt.videooutでDVテープに記録してもいいですね（同書p.789）。それから、jit.gl.textureにtomatrixメッセージを送って、テクスチャーをマトリックス化できるハズなのですが、私の環境ではうまくいきません。なんでかな？　あと、OpenGLフィードバックにも書いたように、ソフトウェア・レンダリング（同書p.839）は処理速度の面で不利な場合が多いと思います。さらに、jit.desktopという反則スレスレ技もありますけど、これも処理速度が遅いのが難点です（同書p.851）。

(2)の他人様のパッチというのは、Randy Jones氏（C74の開発スタッフの一人）が作成したrender_nodeのことです（他にもあるかな？）。

このパッチの特徴は、ノン・リアルタイム処理として、OpenGLの描画を1フレームずつ描きながら、ムービー・ファイルに保存してくれることです。なので、HD画像であろうが、オブジェクトが100万個あろうが、コマ落ちすることなく完璧なムービーを作ってくれます（ホント？）。さらには、動画を自然に見せるモーション・ブラーをかける機能があり、オーディオとの完全な同期が可能です（ということになっている）。

ただし、このパッチが定める方法やドローイング・コンテクストに従ってOpenGLの描画を行う必要があります。これは、それほど難しくはないものの、ちょっと面倒かもしれません。また、レコーディング速度は結構遅いです。これはOpenGLの問題ではなくって、ノン・リアルタイム処理におけるオーディオのディスク書き出しの問題だそうです。あと、当然のことながら、リアルタイムに操作しながら映像を変化させることはできないので、このパッチが用途に合わない場合もあるでしょうね。

【追記】ノン・リアルタムでのオーディオのディスク処理は、Signal Vector Sizeを大きくすると良いみたいです。

(3)のスクリーン・キャプチャは、動画として画面の一部または全体をムービーにしてくれる機能を持ったユーティリティ・ソフトウェアで、Snapz Pro X 2 Movie Capture（US$69）などがありますね。フリーウェアでもあるかな？？　command+shift+3を1秒間に30回叩くってのは、多分無理でしょう（笑）。

(4)のスキャン・コンバータは、ビデオカードのVGA出力またはDVI出力をビデオ信号に変換する外部デバイスで、CPUにもGPUにも負担をかけないのが二重丸。以前のPowerBookなどのようにビデオ信号出力があれば、そのままでOK。いずれの場合も、ビデオ信号になればビデオ・デッキなどで録画したり、コンピュータでキャプチャしたりできるわけです。

ただし、比較的安価なSDコンポジット変換だと画質がイマイチだし、Matrox MXOあたりだとHDおよびSDのSDI出力が可能ですけど、SDIを受けるデバイスも必要となり、結構な金額になっちゃいます。モノが増えたりケーブルを繋いだりするのもイヤなので、ま、最後の手段ということで。

今日の学生クエストは、OpenGLの描画結果を加工したい、あるいは、フィードバックさせたい、でございました。例えば、以下はトーラス（＋補助軸）が1個存在しているだけですが、描画結果に回転歪みをかけながらフィードバックさせているので、複雑な画像になっています。

2061:Maxオデッセイでは、p.839にマトリックスへレンダリングする方法を紹介しています。マトリックスになれば画像処理もフィードバックも簡単ですね。しかし、この場合はCPUによるソフトウェア・レンダリングになり、処理速度が落ちてしまいます。そこで、GPUによるハードウェア・レンダリングのまま処理を行いたいわけです。

解決策：jit.gl.renderへto_textureメッセージ、jit.gl.textureから描画結果を得る。

うむ〜なんのことやら分かりませんね。取り敢えず、パッチは以下の通りで、ダウンロードはこれopengl-feedbackpat.zipです。

ポイントはjit.gl.renderにbangを送ってレンダリングした画像を、to_textureメッセージでテクスチャーに転送していることです（bangbangの1番目）。どのテクスチャーかはusetextureで指定し、ここではtexという名前でloadmessを使って自動設定しています。

このテクスチャーは、texをnameアトリビュートで指定したjiit.gl.textureから出力され、jit.gl.imageunitで加工した後、jit.gl.videoplaneに貼付けて表示します（bangbangの3番目）。この画像は1フレーム前の画像として描画され、その上にjit.gl.gridshapeによって新しいトーラスを描きます（bangbangの2番目）。

ここでのテクチャーはJitter 1.6から新たに加わったもので、OpenGL（GPU）上の画像データと考えれば良いでしょう。テクチャーが流れるパッチコードは水色になります。

以上を繰り返すことによって、OpenGLでレンダリングされた画像を加工しつつ、フィードバックさせているのが、このパッチでの処理です。テクスチャーとして処理しているので、GPU上でデータの遣り取りが行われており、CPUへの負荷はほとんどかかっていないハズです。

ちなみに、jit.gl.imageunitを省略すれば、単純なフィードバックになります。また、jit.gl.videoplaneの位置、大きさ、回転、透明度などを変えることで、フィードバックの起こり方が変わります。また、jit.gl.videoplane自体も3次元物体なので、トーラスを交わらせるとトーラスの一部が切り取られます。これがイヤなら、jit.gl.videoplaneを十分遠くに置いて、ウィンドウに合うように大きくすれば良いと思います。あるいは、他の物体を十分手前に置くことでもいいです。

またまた学生クエストから、MaxからAppleScriptを実行するにはどうしたらいいんでしょう？という質問（記事ネタが増えて嬉しい）。tap.applescriptオブジェクトってのが手っ取り早いですが、それが含まれるTap.Toolsは有料なので、できればフリーで実現したいところ。

解決策：aka.shellオブジェクトでosascriptコマンド

aka.shellはShellスクリプト（Unixコマンド）を呼び出すMaxオブジェクトで、osascriptはAppleScript（またはOSAスクリプト）を呼び出すUnixコマンドです。オーバヘッドがどのくらいなのかは試していませんが、超高速な呼び出しが必要でなければ実用になるハズ。

osascript [-l language] [-e command] [-s flags] [programfile] [argument …]

詳しくは、ターミナルでmanしてください。

ちなみに、aka.shellと同等の機能を持つshellオブジェクトもあります。aka.applescriptがあってもいいんですが、自分が必要とするまでは作らないです（笑）。

それから、AppleScriptからShellスクリプトを呼び出すには、do shell scriptというAppleScriptコマンドでOK。となると、MaxからShellスクリプトを呼び出して、その中からAppleScriptを実行して、その中から別のShellスクリプトを立ち上げて…と訳の分からないこともできます。もちろん、無限ループに陥ることもできるハズです。