橋本 麦∿Baku Hashimoto

ビジュアル・プログラミング

Final CutもAdobeもCinema4Dも、コードを介さないビジュアルプログラミング環境とみなせば、デザイナーも映像作家もある意味でプログラマーだ。本業のプログラマーとの違いは、どこまで低レイヤーまで自分でコントロールしたいと思うか、の精神性の違いでしかない。

映像をつくるためにアセンブラから書くのは流石にしんどいので、誰かが作ったプログラムのうち、GUIとして表示された限定的なパラメーターを調整することに留めている。つまるところ、デザイナーとしてのぼくらは日常的に「低次の特徴量を弄り倒す自由度と、高次の特徴量チューニングの容易さ」との天秤で、どちらかというと後者に重きを置いている。局どの部分をカプセル化して, どの部分をデザイナーがコントロール出来るようにUIに落とすかは、ツール設計者の恣意に委ねられている。

一番怖いのは、そうとも知らずに、そうして外部化されたパラメーターだけがコントロールできる全てだと勘違いしてしまうことだ。それってのは、開発者都合で設定されている制約を、制約として意識すらしないことだ。

映像ソフトの殆どは、並列処理がし易いよう、現在のフレームを生成するために前後のフレームに依存するような処理を許さない仕様になっている。ゆえにクレイアニメのような作り方や、ビデオシンセサイザーのフィードバック回路のような仕組みをそもそも選択肢として思いつかないように習慣づけられている。UVリマップやディスプレイスメントマップについて考えてみても、大概ピクセルのオフセットがX, Y軸の直交座標値として解釈される。例えば2つのチャンネルを極座標方向の変形として処理するだけで面白い風合いのグラフィックが出来るのかもしれないのに、その可能性にも気づけない。

そういうちょっとした引っ掛かりがいちいちストレスに感じるので、AEとかCinema4Dを従順に使うのではなく、スクリプトやプラグインを書くことでほんの少しだけ低レイヤーな部分から弄ってやろう、というのが自分の制作態度だ。もちろんそれでも完璧なコントロールが出来ているというわけではなく、openFrameworksだったりThree.jsなど、例レイヤーな仕組みを分かりやすくラッピングしたシステムのごくごく高級な部分を触ってるだけに過ぎない。

「プログラムで映像作るニュージェネ」という印象を持って頂けること自体は別に否定するつもりは無いし、そもそも自分を認知して頂けるだけで有り難い。ただ自分の肌感覚として、プログラミングと映像の融合といったものを意識してるつもりは無いし、そもそも理系と文系、デザイン思考とエンジニア思考を二項対立的に捉えてしまう時点で、なんか筋が違うんだよなぁ、とふんわりと思っている。