橋本 麦∿Baku Hashimoto

ステートマシン・アニメーション

Sorry, this entry is only available in Japanese.

追記 21/05/04 Nishikiさんのご指摘で、一部のゲームエンジンではステートマシン・アニメーションという呼称があると教わったので、技法名を改題。

もちが縦横無尽に跳ねるWebサイトをつくるにあたって、グラフを使ってもち達の動き方を生成する話というを書いたのですが、実はこのもちアニメーション自体もまたグラフ状の時間軸、いわゆるステートマシン図(状態遷移)のような構造をしたタイムラインを持っています。いきなりそんな言われても…って感じですが。個人的にまだこの手法掘れるなと感じたので、Hackintoshのセットアップがてら書き残しておきます。


Web系の方はひと目見たら分かると思いますが、このもちは、もちの動き方の全パターンをタイル状に配置した動画素材(スプライトといいます)をうまい具合に切り抜き・配置・再生することで動かしています。頭の悪い方法ですが、映像畑のプリレンダ―脳にはやさしいやり方です。もちろん、個々のもちの動きはその場で生成しています 。

※補足までに、スプライトはHoudini、Redshift、After Effectsで作りました。左半分にカラー、右半分はチャンネルの Rにもちのマスク、 G = 影、B = GI(照り返し)を割り当て、シェーダでもちをタイル状に配置するのと同時にPhotoshopみたくレイヤー合成しています。

上下左右の4方向からやって来て、同じく4方向へと跳んでいくので 4 × 4 = 16 パターンを用意しました。注意したいのは、このスプライトはもち視点で「マスからマスへと動いていく」過程ではなく、マス視点で「もちがやって来て、去っていく」までの素材だということです。だからループのつなぎ目は、もちが次のマスへと動くその中間地点にあたります。マスの中央でピタリと静止したところをつなぎ目にすれば必要なパターン数も少なくできるので楽なんですが、なにせおもちは柔らかいので、向きを変えるにもモニュンとしてくれたほうが嬉しいですよね。

ここで、もちの経路に名前をつけます。

例えば、上からやって来て右へとはけていくのは U-R’ と表せます。このように、あるマスは「もちがいずれかの方向からやって来るところ」という4状態から、「いずれかの方向へと去っていくところ」という4状態への変化を繰り返しています。こんな仕組みを賢く書き表せるのがステートマシン図(状態遷移図)です。

矢印を数えるとちょうど16本です。この矢印上を今回の場合、2秒・60フレームかけて遷移していきます。つまり、このもち動画素材のタイムラインは、普通のアニメーションのように一直線のものではなく、いくつもの「状態」同士をつなぐグラフ構造をしていることになります。

ちなみに、○ から ○’ へと変化した(やって来たもちを押し出した)後は、自分の方を指し示す隣のマスを探せば次の状態がわかります。

「上にD’がいればUに」といった遷移のルール

そして、もちがぶつからず動けるパターンをここで紹介した方法で再計算し、その方向へと再びもちを押し出すということを繰り返します。だからこの仕組みはある種のセル・オートマトンとして捉えることが出来ます。面白くないですか?


こういう、タイムラインがステートマシン図のような構造をとったアニメーションを、さしあたり「ステートマシン・アニメーション」と呼んでみることにしました。ゲーム開発ツールでは実際そうした名前の機能があるようです。無意識でしたが、group_inouのフリーダウンロードシングルuri gagarnのアルバムのサイトを作ったときにもこの手法を試しています。

フリーダウンロードなので、現実には無いCDを自作してコマ撮りしました。クローズした今は輪ゴムをかけてます
紙ジャケを見せたかったのでこれもコマ撮り

ちなみにuri gagarnの方のステートマシン図はこのような感じです。

そういえば、学生時代に芸祭フィナーレでやった(今見るとクソおもんない)プロジェクションマッピングの本編までのカウントダウン映像も、友達に描いてもらった数字をステートマシン・アニメ―ションさせていました。多分この手法好きなんですね…。

図書館の壁面に薄っすいプロジェクションをしたのが懐かしい

最近、和田淳さんの「マイエクササイズ」や、セールで1200円だったので買った「フィンチ家の奇妙な屋敷でおきたこと」をプレイしていて思ったんですが、ゲームを無理やり映像作品として捉えるとならば、ステートマシン・アニメーションの一種といえます。おもちのサイトはゲームではないにせよ、せいぜい8種類の状態に16種類の遷移しか扱わなかったので全てをムービーとして予め用意する出来ました。しかしほとんどのゲームは、画面として表示され得る状態やそこからのインタラクションによる遷移は天文学的数に及ぶので、データ量の現実性からその場でレンダリングする手法をとっていると考えることもできます。(ちなみに小さい頃、ヨッシーストーリーのカートリッジには全通りのスクリーンショットが入ってると思ってました)

一方、ゲームのチェックポイントなど、ステートマシン図の一部が一本の矢印に「くびれた」箇所(= 全プレイヤーがかならず通過する遷移)ではムービーが流れたりします。プリレンダ―のものもありますよね。これが過剰になるといわゆるムービーゲーになります。ノベルゲームなんかも、そこまで状態遷移の種類が複雑ではないのでボイスが付いたりします。

Netflixの「ブラック・ミラー : バンダースナッチ」も実写版ステートマシン・アニメーションとして考えられます。こんな複雑なグラフ、よく撮ったなぁ…。

FULL BANDERSNATCH FLOWCHART  – Reddit

現状、主要な映像ソフトはステートマシン・アニメーションには対応していせん。(UI/UXプロトタイプツールには近い考え方の機能があります)この先もしそういう機能が実現されたら、映像とインタラクティブは更に溶けていくんじゃないかと、ふと思いました。Glispに実装したいなぁー。

ハミルトン閉路でおもちが動く

Sorry, this entry is only available in Japanese.

https://s.baku89.com/hamiltonian-mochi/

グラフ構造について考えているうちに思いついたアイディアでWeb作品を作ってみました。もち的な何かが上下左右に気まぐれに動きます。もちイジりは自分の手癖になりつつあるのでいい加減やめたいんですが、こういう動きを作る考え方がちょっと面白かったのでメモしておきます。


もちは格子状に配置されていて、それぞれ上下左右に1つづつ動くことができます。もちの場所を黒丸で表し、移動できる場所同士を線でつなぐとこんなグラフになります。今回のWebサイトでは上下左右がタイル状に反復しているので、両端の黒丸同士も繋がります。

トーラス状になっています

一つのもちが動くことで、移動先にあったもちが押し出され、さらに別のもちが押し出され…という連鎖がおきますが、このグラフ上では各点を一度だけ通るジグザグした矢印として図示できます。そして全てのもち同士がお互いにぶつからずに動けるということは、この矢印がループになっていて、そのループが隙間なく全部の点を埋め尽くしている状態として考えることができます。一筆書きと違い、このループは何本あっても構いません。

それぞれの黒丸が矢印の方向にうごく

こうしたループを作るのは案外簡単です。まず、もちがぶつからずに動ける「正しい」矢印パターンから始めます。全部のもちが一斉に下に動くのが一番単純でしょうか。一旦移動の向きを忘れて、もちが動く道筋だけを考えます。

このとき、下図の左のような「一組の対辺が繋がっているがもう一組は繋がっていない」格子を見つけたら、右のように繋ぎ変えるという操作をランダムに行います。

元のパターンが「正しい」限り、この変換で新しくできるパターンも正しいものとなります。こうして出来上がったループにランダムに向きつけをすれば完成です。

Webサイトでは、もちが移動する毎に少しずつこの繋ぎ変えをして動きに変化を出しています。

制作するなかで知ったのですが、これはハミルトン閉路問題にも似ています。ざっくりいうと、このような線と点からなる「グラフのすべての頂点を一度ずつ通って最初の場所へと巡る方法はあるか?」という問題だそうですが、今回の例だと何人かで手分けして巡っても構わないという少し条件の緩いバージョンになるのでしょうか。現に、この方法を考えるのにハミルトン路をランダムに生成するアルゴリズムを参考にしていたりします。

また、このやり方だと一旦向きつけを無視して道筋だけを考えますが、向きつけを維持したままループを作る方法もあります。この場合、偶数列のもち達は下に、奇数列のもち達は上に互い違いに動くパターンから始めて、「一組の対辺が逆方向の矢印で繋がった格子」を繋ぎ替える変換を繰り返せば完成です。言葉だと説明が難しいですね…。この方法は、もちが引き返す動作が無くなるのでスムーズに見えるうえに必要な素材動画が減るのでロードも軽くなって一石二鳥なのですが、むしろ気迷ったように三歩進んで二歩戻ってくれたほうが可愛いらしいので、あえて先に説明したような方法をとることにしました。


これ、僕はあんまし数学の素地が無いので作りながらほぇ〜ってなってたんですが、もっと賢い方法や、関連する概念があればぜひ教えてほしいです。

グラフ構造に対する操作として一般化して実装したので、格子に限らず色んなパターンに応用できそうです。ハニカム構造みたいな充填図形でも良いですし、シェルピンスキーのギャスケットのような再帰図形の辺上を、縦横の移動だけではなく大きさが変わりながら跳ねるのも不思議そう。あと思いつくのは、別に動画にしなくても、経路自体をTrunchet tilesのようなグラフィックに仕立てても素敵かなと思いました。だれかお願いします。


また、今回のサイトはプリレンダ―で作りこんだ動画をスプライト再生する方法をとっています。ただただ重い上にカクつくのでWeb系の方からは敬遠されるのですが、映像作家が本分なもので、趣味としては好きです。

こんな感じの動画をうまい具合に再生しているんですが、面白いのは動画全体が状態遷移図のように枝分かれしたタイムラインを持っているところです。

これぞ本当の“ノンリニア”な映像

このサイトを作るのに、ここまでに説明したように空間上の移動をグラフとして考えましたが、時間軸でもまた別のグラフ構造が登場しています。これもまた掘れそうな映像技法なので、ここに色々書いてみました

Glispの展望と悩ましいこと(誰か助けてください)

Sorry, this entry is only available in Japanese.

Glispを開発している中で、このエントリにも上げたような問題があったので言語処理系自体を、一般的なLisp評価器とは異なった、よりGUIやデザインとの親和性の高いものへとアップデートしようとしています。しかしまた色々行き詰まった所が出てきたので、言語化も兼ねて今一度悩んでいるところを書き出しておきます。

言い訳までに、僕はただの映像専攻の美大中退者でして、言語処理系に関して何の専門教育を受けたこともないので、車輪の再発明をしているような予感もありますし、以下の考察も適切ではないかもしれません。もし、この辺勉強するとスッキリするよ~とか、こういう概念があるんよ~みたいなアドバイスがあれば、断片的にでも構わないので教えてくださるととても嬉しいです。

Lispの何が問題だったか?

  • そのシンボルが指し示す値、関数の実体、そして型が、評価されるまで分からない(Lispは動的型付けなので)
    • その関数の引数や、シンボルの型に合った適切なUIを表示出来ない
  • ある式の一部が置き換えられながら、繰り返し再評価されるような用途を想定していない
    • Incremental evaluation(差分評価?)の実装の難しさ。Glispでは構文木そのものをプロジェクトファイルの階層として扱うが、ある式の一部の数値やシンボル名が更新されるたびに、プロジェクト全体を再評価するのは効率が悪い

プログラミング言語におけるシンボル

ここで考え直したのが、プログラミング言語における「シンボル」の意味です。コードは「手順」を表すこともありますが、より抽象的に捉えるとデータ同士の結合の仕方を表した有向非巡回グラフ構造でもあります。例えば以下の式

(+ 1 (+ 2 3))

は、このようなグラフを成します。

ここまでは普通の抽象構文木の説明ですが、それは文字通り「木構造」でしかないので、データの合流しか表現できません。シンボルの本質は、あるノードに「別名」を付け、その木構造の直接の親子関係ではない別のノードから何度でも参照できるようにすることによって、データ処理のグラフに「分流」を表現することにあります。

(def a (+ 2 3))
(+ a (* a 2))

ですから、評価時でシンボルが指し示すノードを解決するのではなく、前もって名前解決を済ませ、構文木にこのようなグラフ構造を仕込んでおくことで、そのシンボルの値までは分からないかもしれないにせよ、少なくともどのノードから出力されているか(どの関数の返り値か)によってその「型」は予めわかります。例2の場合、シンボル a は、足し算ノードから出力されているので数値型です。UIには、数値ボックスにa というエクスプレッションを表示しておき、そこをクリックすることで (2 + 3) の式へとジャンプさせることができます。(一度でもグラフ全体が評価されているなら、5という評価結果を表示することも可能です)最近こういうデータ構造のことをProgram Dependency Graph(PDG)と呼ぶことを教わりました。

グラフ構文

今Glispでは、そうしたシンボルの役割をより明示的に表現すべく、スコープや「順番に実行される式の列」という概念を取り去り、こうしたグラフ構造を直接記述する新しい構文を試しています。それは中かっこで囲い、シンボルと式のペアと、最後にグラフ全体が返すシンボル名を並べることで表現します。

{symbol1 expression1
 symbol2 expression2
 ...
 returned-symbol}

ツリービューが入れ子構造のS式だとすると、グラフはノードベースUIに対応します。

シンボルは「値の容れ物」ではなく、グラフの分流を表現するための別名でしかないので、以下のような再代入は不正です。

{x 10        ; let x = 0
 x (+ x 1)   ; x += 1
 x}          ; return x

先の例のconst a = (2 + 3); (a + (a * 2)) は、グラフ構文ではこうなります。

{a (+ 2 3)
 o (+ a (* a 2))
 o}

上記の式をパース、解析(名前解決)することで、このようなPDGを生成します。

破線は直接の参照関係にないが、構文木上親子関係になっていることを示す。細い矢印は、シンボルを介した参照

このグラフを、求めたいノードから上流へと辿ることで、最終的な評価後の値を得るという算段です。

シンボル a をノードとして残しているのは、PDG全体を構文木のスーパーセットにするためです。(* a 2) にはあくまで (* (+ 2 3) 3) という展開後の式ではなく a というエクスプレッションと 2 の掛け算としてGUI上に表示されていてほしいですよね。また、UI表示上の都合だけではなく、常にPDG全体が文字列のコードへと変換され得ることを保証するためにも a というシンボルは残してあります。

一度PDGが構築されれば、そこに「式の実行順」という考え方もなくなります。例えば以下のような式もvalidです。

{a (+ b 2)
 b 1
 a}

一方で循環参照は不正となります。

{a (+ b 1)
 b (+ a 1)
 a}

こうしたPDGを構築するメリットは

  1. あるノードを変更した時、その下流(親)に当たるノードだけを再計算させることで差分評価が実装できる
  2. 式全体を評価せずとも、任意のノードだけを評価することができる
  3. 構文木の各要素に「パス」を割り当てることができる

3はもう少し説明が必要です。多くのデザイン系ツールは、シンボル名を明示的に宣言せずとも、パラメータ同士を直接参照することができます。AfterEffectsでいう thisLayer.transform.position 、Houdiniでいう ch("../radius") 、TouchDesignerの `op('/project1/effect/transform1').par.tx のようなエクスプレッションです。

Glispでもグラフ構文のシンボル名や、関数のパラメータ名から成るパスを構文木に割り当てられる仕組みにする予定です。そしてそれらを相対パスや絶対パスから成る「パスシンボル」を通して、明示的にシンボル名を宣言せずとも構文木の各部分同士に直接参照関係を貼ることができるようになります。

度々例に上がるこのような式は、パスシンボル構文を使えばこのようなワンライナーで表現できます。

(+ (+ 1 2) (* @`../0` 2))
; あるいは
(+ @`./2/1` (* (+ 1 2) 2))

そしてこうした表現は、Houdiniのパラメーター編集画面やAfterEffectsのエクスプレッションなどでとられている表現にも近しいものになっています。

ここでまとめます。シンボルの考え方を再定義し、コード全体を「手続きの連なり」ではなく「グラフ」として解釈するような構文をとることとのメリットを、具体的にデザインツールにおける機能に置き換えるとこのようになります。

  1. ツリービュー、ノードベースUIの両方が使える(グラフ構文、S式)
  2. パラメーター欄にエクスプレッションが貼られていても、その型に合ったUIが親切に表示されてくれる(静的型解析)
  3. 巨大なプロジェクトでも、ほんの一部にしか影響しないパラメーターをチマチマ変更した時にはそんなに更新がモタつかない(差分評価)
  4. レイヤーやコンポジションなんかをソロ表示すると、それが元々非表示に設定されていたとしてもちゃんと正しく表示されてくれるし、しかも軽くなる(部分評価)
  5. パラメーターをパス表現を介して直接参照することが出来る(パスシンボル)

一方で悩ましい点もあります。あるノードの評価結果を知るには、その上流(子)のノードを辿って評価する必要があります。また一方で、あるノードを変更した時、その変更によってどのノードを再計算する必要が生じるかを下流へとたどりながらマークする必要があります。つまり、あるノードは上流ノード、下流ノードの両方への参照を持っている必要があるのです。

こうした双方向の参照をもったグラフ構造は、ActionScriptやPaper.js、Three.jsなどのステージオブジェクトにも見て取れます。つまり、それぞれのステージオブジェクトが children()parent() メゾットを持っているということです。このような場合、どのようにしてイミュータブルなノードの更新をやってのけるか に個人的に悩んでいます。親から子への参照しか持たない木構造の場合は、このようなことになります。

AというノードのA’への置換

しかし親から子、子から親へと両方の参照を持つ場合、そもそもグラフ全体をdeep cloneしないからには、双方向の参照の整合性を保ったままのイミュータブルなノード置換は出来ません。

Paper.jsなど場合は、そもそもミュータブルに更新していく(それぞれのノードが needsUpdate のようなフラグを持っていて、レンダリング時に走査してフラグが立っているオブジェクトを再キャッシュする)仕組みとなっているので、そもそもこの問題は起きませんが、Vue.jsやReactのような、フラグを使わずイミュータブルなデータ構造全体の置き換えを検知することでコンポーネントを更新するライブラリ上では、うまくreactivityが効いてくれないことになります。そして仮に forceUpdate() のような汚い方法を取ったところで、データが永続的ではないので undo/redo の実装が難しくなります。

バインドデータが単なる木構造の場合は、そもそも子コンポーネントがデータ更新を emit すれば済むので、子ノードが親ノードへの参照を持つ必要はありませんが、DAGの場合はあるノードの親(下流ノード)が複数になることもあるので、props – emit の枠組みではうまく扱えません。

…と、色々悩んでます。DAGをガチャガチャする夢を観るくらいに気が休まらないので、例のMV制作の方で気持ちを落ち着けつつ、少しずつ開発進めて行こうと思います…。

LispとGUIの相性

Sorry, this entry is only available in Japanese.

ここ最近、Glispの言語処理系の実装を色々と見直しています(class-based-ast)。しかし、Lispをそれ自体プログラミング言語のためのシンタックスとして維持しつつどのようにGUIに対応付けするかという試行錯誤の中で、まだまだ知っておかなきゃいけない概念がたくさんありそうに思えたので、一旦頭の整理に今突っかかっている所をメモしておきます。


Glispでは、Lispコードを文字列として編集できるほかに、GUI上からその値をGUIから編集できる機能を提供しています。プリミティブな値が単独で選択された場合はそのリテラルに従って、文字列ならテキストインプット、数値なら数値ボックス、真偽値ならチェックボックスなどと、それぞれに従ったGUIを自動で表示します。それが関数の引数として使用された場合、その関数オブジェクトのメタデータに従ってさらに適切なGUIを表示します。例えば、2つの数値を0-1で補間する関数 lerp はこんな感じ。

この第3引数は、メタデータ上ではこのようになっています。

{type: "number", ui: "slider", min: 0, max: 1}

同様に文字列の場合も、それが text 関数のように任意の文字列として使われる場合もありますが、stroke 関数の線端の形状のように、列挙型として使われるケースもあります。

Capに対応する引数のメタデータは以下の通りです。

{type: "string", ui: "dropdown", default: "round",
 values: ["butt", "round", "square"]}

同様に、stroke 関数の第一引数である線色もリテラルとしてはただの文字列ですが、セマンティクス的には色を表しています。

{type: "string", ui: "color"}

Lispコードのそれぞれの値に適切なGUIを表示させようとしたとき、そのリテラルだけでは情報として不十分なことになります。

Glispではある値が選択された時(実は現行の版ではリストやマップ以外のプリミティブな値を単独で選択することはまだできませんが)、その値がどの関数の引数として記述されているかを検知した上で、関数のメタデータに従ってさらに適切なUIを表示しようとします。しかし「どの関数」かを知るには、その式を評価する他にありません。つまり、ある式のGUIを適切に表示するには、それ以前にその式が一度は評価されている必要があるのです。これが結構悩ましいところでして。

例えば、式の途中で例外が投げられた時、それ以降の式は評価されないので、

(throw "Error")
(+ 1 2) ;; 1 + 2

(+ 1 2) を選択しても、インスペクタには適切なGUIを表示することができません。

同様に、if のような特殊式やマクロでも、式自体が一度も評価されないことがあります。

(if false (+ 1 2) nil) ;; false ? 1 + 2 : null

上記の場合、評価器はthen にあたる (+ 1 2) をすっ飛ばして、else にあたる nil のみを評価するので、(+ 1 2) に対応するGUIを表示することができません。


ここで式自体の評価とは別に、関数の名前解決を先に済ませてしまえば? という発想にもなります。つまり、関数シンボル名とその式が実行されるスコープに基づいて関数オブジェクトを前もって知っておけばいいのです。しかし以下のような場合にはこの作戦は破綻します:

;; A. 即時関数
((fn [a b] (+ 1 2)) 1 2)

;; B. 関数部分に式を含む
((if true + -) 1 2)

;; C. 同一スコープの中で宣言されたシンボルを用いて関数呼び出しをする
(def - +)
(- 1 2)

A、Bは、単にリストの1番目の式のみを評価してしまえば済むことですが、Cの場合は、結局 (def - +) の式全体を評価してあげないからには、その外側のスコープで宣言されているであろう間違った関数オブジェクト(引き算)を参照してしまうことになります。

deflet のようなスコープに関わる特殊式に関しては予め式全体を評価することにしたとしても、その中で例外が投げられれば同じことですし、def 自体がマクロの内側で呼び出されていたら判別しようがありません。


もう一つ思いついた対策は、その式が評価される際に与えられるスコープにおいて名前解決されるよう強制する構文を用意することです。具体的に言うと、Glisp(のベースになっているMake-A-Lispプロジェクト)のLisp評価器には、その式とスコープがセットで与えられます。ちょうど eval("(+ 1 2)", scope) のような形で。scope は、シンボル名と値からなるマップオブジェクトのようなものです。例えばですが、$ を特殊文字として $(+ 1 2) のような形で関数呼び出しをすると、この + は必ず scope において静的に名前解決されるというルールにしてしまえば、式全体を評価せずとも関数を知ることができます。

(let [+ -]
  $(+ 1 2))

の場合は、 +let スコープではなく、評価器に与えられたスコープにおいて名前解決されます。


とかとか、ややこいことを考えてしまっています…。別方面の対策としてはGUIに必要な情報を関数のメタデータによって補間するのではなく、その値自身のメタデータとして付与するのもアリかもしれません。その場合コードが冗長になって嫌なんですが、GUI側から一度tweakすると、コードの引数部分に勝手にメタデータがくっついて、二度目以降は評価無しに正しくGUIが表示されるっていう仕組みとか。

(lerp ^{:type "number"} 0
      ^{:type "number"} 0
      ^{:type "number" :ui "slider" :min 0 :max 1} .5)

Common Lispのように、関数オブジェクトの名前空間を分けてあげるともしかしたら何か解決するかもしれないです。あるいは第一級オブジェクト的な構文を諦めるとか…。

関数適用は、例えばノードベースUIでいう所のノードそのものになりますが、そのノードの種類はGUIに表示された時点で既に決定されています。((if true + -) 1 2) をノードUIに置き換えるならば、そのノード全体が評価(Cook)される時になって動的にノードの種類が定まるという奇妙なことになってしまいます。「同一の引数を、条件によって異なる関数に与えてあげる」という処理は、多くのビジュアルプログラミング言語では (if true (+ 1 2) (- 1 2)) のような若干冗長な方法を取らざるを得ないはずです。(ノードベースなら、1, 2にあたるノードから + - にあたるノードの入力に「分流」させる方法を取ることが出来るので、若干マシですが)

「Lispベースのビジュアルプログラミング言語としてのデザインツール」という大層なコンセプトを掲げてしまっているのですが、突き詰めるほど、GUIベースのビジュアルプログラミングが文字列ベースのコーディングにその柔軟性や素早さで敵わないということが身に沁みます。

わからなさのわからなさ

Sorry, this entry is only available in Japanese.

説明ベタなので誰かにソフトの使い方を教えたりする度に微妙な雰囲気になってしまう。僕の説明ベタさの原因は、誰かが何をわかってて何をわかってないか、そしてその人が何を「わかりやすい」と感じるかへの想像力がまるでポンコツだからなのだけど、この自分の「わからなさが分からない」という感覚が分かるまで、だいぶ色んな人を困らせてきたんだろうなぁとしょんぼりする。

ちょっとした笑い話なんだけど、病院勤務のパートナーが「100mlで6gの塩分量のとき、大さじ一杯の塩分量は?」という質問を結構いい大人の患者さんにしたら、考える素振りもせず「わからない」と即答されて困ったらしい。だけどこれは「大さじは15ml」という知識と、この質問を「6の15%は?」という算数の問題に換言する思考力、あとは「かける0.15は、小数点を1つずらして1.5倍すればいい」という単純化が必要なので、案外難しいことをやってのけてるのかもしれない。このひとつひとつは単純なステップを自然に想像できないと、冒頭の質問は手を付けるまでもなく難しそうな計算問題として投げ出したくなるのだろう。

とはいっても、このくらいの日常計算わかれよ!って言いたくなりもする。そこでこの患者さんの分からなさを分かろうとするために自分なりに想像したのが「sinの微分は?」という質問だった。これは高校数学の「sin、cosの微積分はそれぞれの正負との4つをぐるぐるする」というかすかな記憶と、微分とグラフの傾きとの図形的な相関のイメージさえあれば数字すら必要ない4択クイズになる。冒頭の塩分計算よりもある意味で簡単だ。だけど、sinだの微分だのって響きにほだされて、結構な人が考えるまでもなくギブアップするんだろうなぁと思った。

僕はたまたまCGを生業にしていてsinの微分は「大さじは15ml」くらいの当然の常識なのであんまり例として良くなかったかも。どのみち、大さじですら、レシピ通りの料理をする限りml換算する必要はほぼ無い気がする。15%を求める問題だって、消費税が5%だった頃の税別価格に触れてない人には日常的にパッと出来る計算ではないのかもしれない。

だけどこの「持ち合わせの知識でちゃんと向き合えば些末な問題でも、みてくれの難しさから分かろうともしなくなる」気持ちっていうのは多かれ少なかれ誰にでもあることだと思う。自分にとってのうまい例はあまり見つからないのだけど、それは僕が何を分かってないのかすら分かってないから当然なのかも。ともかく、誰かにとってわからないことを苦もなくわかってしまう人からすると、考えればわかることじゃん!ってやきもきしたくもなる。しかしその人がそれを「わかる」ために当たり前に前提にしている知識もまた誰かにとっては当たり前ではないかもしれなくて、そしてその問題を食わず嫌いせずにパパっと処理できるのもそういう場数を踏んだゆえのことだ、という想像力が無いと、色んな人のことを腹立たしく思うことになるし、困らせることになる。これは本当に自分がソフトを誰かに教えてた時の反省なんだけど…。比嘉了さんがいつか仰ってたことだけど、「わかる」ことはその「わからなさがわからなくなる」ことなんだなと実感する。

そして当然「わからなさのわからなさ」が「わかる」ということは「『わからなさのわからなさ』がわからなくなる」ことでもあるので、「わからなさのわからなさ」がわからない人にやきもきする気持ちにも上手く対処していかないとないけない。 

TENETで疑問におもったことのメモ

Sorry, this entry is only available in Japanese.

RedditのメガスレッドのFAQを参考に、特に疑問に感じていたことや友達と話題になった所を個人的に調べてメモ。あとMakoto Kitamuraさんから頂いたコメントがかなり正確そうだったので、追記。公式ガイドブックが来たら更に編集するかも。


タリンの高速道路での241の行方

まず抑えておくのは、241自体は終始順行であること。241の視点に立つと:

  1. ウクライナ保安庁の輸送車から順行のP(Protagonist = 名もなき男)にケースごと奪取される
  2. オレンジのケースだけ逆行するセイターの車に投げられ、241は逆行Pの運転するSaab(グレーの車)に投げられ、そのまま後部座席に収まる。その様子を逆行セイターに目撃される
  3. フリーポートで逆行Pが降りた後、何らかの方法でセイター一味に回収される

つまり、Pが初めて逆行した後Saabに乗り込んだ時点で241は既に後部座席に収まっている。その証拠に、Pは車を発信する直前後部座席をチラッと確認する。そしてその「241が後部座席に収まった」原因を作るために、再び高速道路に駆り出す。

ちなみに、逆行した時点でなぜかケースの位置がGPSで捕捉できているが、その原因を作るために逆行Pは発信機をケースに付けにいくことにも注意。(この時発信機とスマホは順行している)

オペラハウスの逆行弾は、建設時点から建材に埋め込まれていた?

わりといろんな場面で疑問に思う点。順行Pとニールが乗っていた車のサイドミラーの割れはレンタカーから借りる時点で入ってた? とか。メガスレの説としては、ニールの「逆行するのは流れに逆らって泳ぐようなもの」という台詞から想像するに、逆行物質は順行世界に逆らって進むうちに時間の矢の抵抗を受けてやがて順行に転じるとのこと。これは辻褄の合う部分もあって、オスロのフリーポートの最奥部に二人が入った時、弾痕のヒビが少しずつ広がっていくような描写があった。弾痕自体は逆行Pの銃によるものなので、逆行視点ではガラスが自然治癒したことになってしまうが、時間の矢の抵抗説によるとそのヒビは無限に過去へと遡っていくのではなくやがて順行へと転じるので、「逆行視点で」ヒビが逆行して治癒していくのは説明がつく。同様に、サイドミラーの割れも、ある時点から独りでにヒビが入りはじめて、逆行者とぶつかったことで完全治癒する。あとは:

  • キャットの臀部を撃ち抜いた弾痕
  • 順行グレネードによって壁の中に埋め込まれた青チーム隊員

とか。

とはいっても、順行Pが逆行Pの腕に付けた傷は順行じゃん? オペラハウスの弾痕は(更に過去では)綺麗サッパリ消えたとしても弾だけ建材の見えない所に埋まってたってこと? そもそも未来人が金塊寄越すのも無理では? とか色々疑問も出てくるけど、そこはもう気にしない。

スタルスク12で挟み撃ちでビルをぶっ壊す意味は?

アレが現象としてどういうことだったのかはパンフレットに書かれているが、そもそもぶっ壊した意味は、地下通路へと入る「別部隊」が敵に見られないための目くらましだったっぽい。台詞の流れではアイヴスの発案に思えるが、青・赤チーム双方が、それぞれ相手のチームから「あのへんの崩壊したビルがちょうど5分で元通りになるから、そのタイミングで狙って撃ってくれ」と聞かされていた通りにただ発破したというこということになる。だからあれは誰も発案者の居ない因果のループ。これは挟撃作戦全体に言えることだけど。

自由意志は結局どうなるの?

物語全体が両立主義(決定論と自由意志が両立する考え方)にも似た立場で書かれている。ニールは未来の死を知ってなお自由意志のもと「燃える熱さに飛び込む」。デスノートに書かれた人物のように、意思を失った機械のように未来に合致した行動を取るということではなく、未来を知った上での気変わりや微妙な行動の変化も含めて、予め歴史に織り込まれているという世界観。

一方で、主人公が過去を変えようとした時、プリヤやニールが「改変出来たとしても、その世界を知覚することは出来ない(If that universe can exist… then that’s not what we live in.)」という趣旨の発言をしていたことから、逆行後に意図的に見知った歴史と違う行為をした時はその過去が新しい世界線となるが、自分たちの居る世界線自体は変わらないという解釈も出来る。

また、祖父殺しのような過去改変が行われた場合については「多元宇宙と意識の関わりは謎」とか雑にボカされていたけど、結局未来人の計画が阻止されたことで、プロットの範囲では矛盾をきたしていない。

結局TENETはどうなるの? プリヤはなぜキャットを殺そうとしたの?

追記: Makoto Kitamuraさんから頂いたコメントのほうがRedditのFAQより正確そうだったので:

未来に情報を残してはいけないのはアルゴリズムの存在です。作戦開始前にアイブスが主人公と二人だけの特殊チームだと告げたセリフは「カプセルの中身を知る者を残すわけにはいかない、つまり俺たちだろ」(No one who knows the contents of the capsule can leave the battlefield. I think we take care of ourselves.)= 死を覚悟できてるのは俺たちだけだろ、です。(この覚悟の証明が最初のテストが必要だった理由の1つです。他にも単純にプルトニウム241を移動させるため)

レッドチームの隊員が「ブルーチームの姿が見えない、嫌な予感がする」と言っているように、他の隊員は逆行は理解していても死は覚悟していませんし、「誰が爆弾を解除するんですか」と質問している通り、一般兵はアルゴリズムの存在を知りません。

逆行技術自体は遠い未来に必ず見つかりますが、アルゴリズムがどんな形で隠されているのか、ましてや全部が過去に一度に集まったことがあるなどとは、なにがあっても知られてはならないので、全部が集まったことを知っていたプリヤは消されました。

アルゴリズムは結局過去に向けて埋め直せば良かったんでは?

(北村さんより)劇中にあった説明としては、この時代の核管理が前後のどの時代よりセキュリティが厳しいからっていう理屈。だとすると更に過去に埋めても逆に危険という理屈なのかなと。わかんないですけどね。

Pが黒幕なのに「テスト」をする必要はあったの?

上記のような目的から、最終的には主人公自らも(情報が漏洩する前に)自死する必要があるかもしれない、少なくとも命を賭けて情報を守らなくてはいけないので、その素質を見抜くための「テスト」は必要だった。あとは単に、「テスト」の記憶がある以上、過去の自分に楽をさせちゃうと過去改変になっちゃうし、という。

キャット結局合図を待たずに殺しちゃったけど?

キャットはそもそも作戦のある種の「担保」であって、なくてはならない存在ではない。仮にキャットがセイタ―の自殺を上手く先延ばしに出来たとしても、セイタ―がやがて死んだ時点でアルゴリズムの場所は送信されるので、結局爆心地からTENET一行が奪取できるかどうかに懸かっている。キャットが奪取よりも前にセイタ―を殺したことで場所自体は送信され、作戦成功以外に後は無くなったが、結局奪取に成功したので何事もなかった。というのがRedditのFAQでの結論。

でも爆発後に「記録」を揉み消せばよくね?

“Another pile of emails set to reveal the pickup location, if his heart stops.” とあるように、取り返しのつかない形でメールをたくさんばら撒いたのかもしれない。

じゃあ後でこっそり掘り返せば?

映画上、そこは「爆発で埋める」「記録を残す」ことが成功した時点で未来でアルゴリズムは確実に起動され、その後TENETサイドがいかなる方法をとっても遡及的に無効化される、ってことにしたいっぽい。

似た状況はラストシーンにもあって、プリヤはキャットが携帯をかけた時点で、その後それがPに届くのを阻止しようが無効化される。とFAQでは説明されているが、セイタ―と違い「記録」の宛て先は現在のPなのと、どのみちプリヤが何か行動を起こす前に車中で殺されているのでちょっと違うような。

弾痕と水たまり

オスロの回転扉の窓に逆行Pが二発打ち込んだ弾は逆行視点で普通に窓ガラスにヒビを残したが、タリンで踏んだ水たまりは踏む時に水が逆再生で集まってくる。逆行物質が順行世界のものに与えた衝撃は水たまりの場合「未来」へ、弾痕の場合「過去」へと伝搬している。そのへんの設定はわりと雑?

字幕だけじゃ分かりづらい

ファンメイドのTranscriptより:

「パラシュートは?」

N: How’s your parachuting?
P: I broke an ankle during basic training. Singh’s house isn’t tall enough to parachute off of.
N: It’s bungee jumpable.
P: I don’t think “bungee jumpable” is a word.
N: It may not be a word but it may be our only way out of that place. Or in to it for that matter.

「推論か?」「演繹だ」「演繹法か」

旦那: Fine assumption.
P: Deduction.
旦那: Deduction then. Look, my griend.

「結構な思い込みだな」「いや、当然の推理だ」くらいのニュアンスか。韻を踏んでいたのに合わせて熟語で揃えたかったのかな。

マヒヤの台詞

P: Well it seems… bold.
M: “Bold” I’m fine with. I thought you were gonna say “nuts”.

「陽電子は時間を遡る」

微かに残るキップ・ソーン監修の痕跡。具体的にファイマン図とジョン・ホイーラー(青チーム隊長の名前の由来)に触れている。

P: No. Technology that can invert an objects entropy.
N: You mean reverse chronology, like Feynman and Wheeler’s notion that a positrons and electrons moving backwards in time?

「君の店に来た男」

ディナーしたレストラン? とも思ったが、キャットの勤めるオークションハウスの “Shipley’s” 。台詞の随所で登場する

「検証窓」

reimbursement window : 弁済、償還。なんとなく意味は通る。

「顧客を倉庫へ紹介する」

キャットが贋作の置き場所を語るシーン。

K: We started a network. Rotas, his construction company, built them, I brought in the clients. The facilities are tax havens.

Rotas は具体的な社名として随所に登場する。例のコンテナも、Rotas所有のもの。3人はオスロ空港の倉庫近くから運び出されたであろうことを期待して入った。

「またロンドンに戻るのか?」

N: You’re not going to London to see Kat?
P: No. It’s way too dangerous.
N: Not even at a distance?

ニールとPが「遠くでこっそり見守ってていい?」ってイチャついてるシーンかと思ってた。

英語のお勉強

  • You’ve been made.
  • Take one’s life
  • ignorance is our ammunition,
  • The filthy business…
  • Vengeful Bitch

そもそもTENETはそこまでハードSFとして考察に対する強度を持った作品ではないと思うのだけど、描写から作品世界のルールを帰納するのは二次創作的な面白さがあって楽しい。

Bootstrapping

Sorry, this entry is only available in Japanese.

Wikipedia

あるシステムの中で何かを良くしようとした時、その「良くする方法」を良くすることもできる。さらにいえば「『良くする方法』を良くする方法」を良くすることもできるし、実際この入れ子は何段にでも重ねられる。

普通、あるシステムを良くするには、そのシステムに言及・操作するためのメタシステムがが必要だ。だけどもし、この「良くする方法」の多段構えをメタシステム無しにそのシステムの自身の中に埋め込めることができれば、あとはそのシステムが勝手に自己最適化を図ってくれる。そのシステムが扱う「良さ」の良くなり方(の良くなり方の…)も独りでに良くなってくれる。

遺伝の歴史がまさにそうで、「良さ」を「生き物の適応度」に読み替えると意味が通る。遺伝の本質は形質を受け継ぐ正確性よりむしろ、どう不正確さ、つまりグリッチが入り交じるかにある。そのグリッチがたまたま形質にいい方向へ作用することで、生き物は環境により良く適応していく。一方で、遺伝の仕組みもまた40億年の歴史を通してより洗練された手法へと進化してきた。放射線などによって外因的に引き起こされる突然変異から、交叉、有性生殖、そしてミーム…? 遺伝による生命の適応と、遺伝というシステム自体の適応、そして恐らくさらに高階のレベルでの適応が同時に起こっていることこそが、今の遺伝の仕組みを最適化アルゴリズムとして有用足らしめているという倒置も面白い。 無神論者としては、この複雑な生物相(2020年の文明社会の脆弱性を当てずっぽうに突いたコロナウイルスも含めて)を作り上げた遺伝というシステムのそうした多段適応にこそ神性を感じる。「高次の意思体によって生命はデザインされた」という一方通行の二段構えは構造としてあまりイケてない。(宗教自体は尊重してます)

一方で、「良さ」を「組織の生産性」に置き換えれば、ダグラス・エンゲルバートが提唱したブートストラップ戦略になる。ブートストラップは「Pull oneself up by one’s bootstraps(自分のブーツのかかとの紐を引っ張って自分を引き上げる)」という成句表現が由来で、自己参照的に自分をアップデートする構造を指したりする。パソコンの起動プログラムが自分自身を読み込んで立ち上がるのをブートと呼ぶのもそこから。

最近Lispベースのグラフィックデザインツール、Glispを開発していて感じるのは、このブートストラップ構造に自分は無茶苦茶惹かれてるんだなぁということで。Lispがまさに、構文を操作するための構文がそれ自身に埋め込まれている最もシンプルなプログラミング言語だ。

良さを文字通り「作品の良さ」、システムを「デザインツール」として考えると、ほとんどの場合、メタシステムは「ツール開発会社」になってしまう。そうなると、メタシステム側がシステムをうまい具合に良くしてくれるまで、システムの内側の僕らに為す術はないわけ。そこにシステムそのものにそれ自身を良くする(自己言及する)方法が埋め込まれている重要性があって、こっからすげー色々考えてることあるんだけど眠い。書くのやめた。とにかく、表現やその為のツールをブートストラッピングするというのは自分の一生涯のテーマのような気がする。まだ全然作品には反映出来てないんだけど…。

リベラリズムや個人主義云々も、倫理や感情といった「お気持ち」の問題に立ち入らずに、社会規範の最適化に遺伝が成し得たようなブートストラップ性をどう付加するかという問題として捉えられるような気がしている。多分頭のいいひとがそういうこと考えているはずなので、良い本とかあったら教えてほしいです。ゼミが始まる前に武蔵美辞めちゃったので、自分の人生にそういうメンターが居ない。

システムとメタシステムが分離されていて、システムはそれ自身に触れることは出来ずその内側でしか思考することしか許されない状態ってのは、ID説や第一級関数のないプログラミング言語、上意下達な組織くらい窮屈なものだなぁと思う。

Tenet 雑感(ネタバレ)

Sorry, this entry is only available in Japanese.

ネタバレ


ようやく観てきた。これは確かに頭の中にファイマン・ダイアグラムのような図を描きながら観ないとこんがらがるやつだなぁと思った。スタルスク12の作戦は、一度目は途中で何がなんだか分からなくなった。


『インターステラー』は20代で観た中で今の所一番好きな映画だ。設定資料集から、科学的設定を解説した Science of Interstellar、その他自分なりに色々読み漁った。映画館にも5回通った。

そもそもインターステラーはクリストファー・ノーランのオリジナル企画ではなくて、理論物理学者のキップ・ソーンと、映画『コンタクト』のプロデューサー、リンダ・オブストによるトリートメントが元になっている。確か、中性子星の連星が重力波を放ちながら衝突する冒頭シーンに始まり、ワームホールは行き帰り用の2個、ブラックホールなんかはスイングバイの度に利用する設定だったのでガルガンチュアの他に6、7個登場していたような気がする。とにかく節操ない。というのも、キップ・ソーンはカール・セーガンがコンタクトの原作を執筆した時の相談相手で、ベガ星系への恒星間航行にワームホールを提案した張本人だった。しかし、映画ではただの光の虫食い穴として描かれてしまったのが心残りで、もう一回ちゃんと宇宙のエキゾチックなイベントを光学的に正確に描写きたい一心で生まれたのがインターステラーの企画だった。というのは僕の勝手な想像…。

とか良いながらこのシーン本当に大好き

だが紆余曲折あってノーランが監督するとなった時、オモシロ天体ショーの下りは殆ど「これは映画なんだ」とバッサリ削られて、その主題は父娘の話に取って代わられた。ワームホールやブラックホールが間近で見られるシーンは数分にも満たず、相対論的に正確なレイトレーシング(CGにおける光の軌道計算)によって描かれた星空や降着円盤の歪みを見て取れるのはほんの数秒・数カットしかない。キップ・ソーンも Science of Interstellar でそのことへの恨み言を書いていたりするが、「映画としては彼の取捨選択は正しかったと思う」と擁護するようなことも書いていたりする。かわいい。

右上にブラックホールの反対側から回り込んで入射した360度の星空が集まって見える

だからテネットでは監督として「映画としての体裁」を保とうとするバランス感覚が影を潜め、完全にギミック駆動に振り切っていたのが何よりも嬉しかった。やっぱりトンチが好きなんじゃん、ようやく素直になれたねっ!っていう。決めつけですが。それが良くも悪くも、人間描写の情感をスポイルしていたのかもしれないけれど、 インターステラーの父娘の話をかったるいと思っていた人間としては一向に構わない。むしろ雑味がなくなって良い。こちらとしては「ノーラン的ややこしさ」をギュッと濃縮した原液をグビッとやりたいだけなので。

登場人物がプロットに都合よく動かされている駒のように感じるという批判意見も目にしたが、むしろ設定上そのように見えて然るべきだと思った。逆行世界から順行世界に働きかけをするには、結果を生んだ後にその原因を作ってあげる必要がある。例えば、タリンの高速道路で、逆行するセイターがキャットに銃を突きつけながら3、2、1と指折り数え、耐えかねた名もなき男は空のアタッシュケースを投げて寄越すシーン。逆行セイターの主観時間に立ってみると、先にアタッシュケースを名もなき男の車に投げた(=受け取った)後に、その原因を作るために1、2、3、とカウントアップしたことになる。一方、タリンの自由港の回転ドアのシーンでは、名もなき男は逆行セイターに241の在り処を吐いた後、順行するもう一人のセイターに後ろからど突かれ、アルゴリズムは何処かと聞かれる。そこで名もなき男は「もう言った」と伝えると、妙に納得したように逆行セイターと同時に回転ドアへと対消滅する。これはタイラーの主観時間では、この時点で十数秒後の自分が名もなき男らに241の在り処を訊き出せることを知っていて、扉を潜ると案の定名もなき男に241の居場所を(逆再生で)自ずと語りだしたことになる。そして名もなき男が在り処を吐く原因を作るために、キャットの臀部を撃つわけ。だから、逆行世界の摂理を熟知し、それを使いこなせる人物ほど、順行世界で予め知った逆行自分のとる行動を、機械的に逆向きへとなぞるようになる。しかも、それはあくまで自由意志の元でだ。

テネットでは、そもそもパラドックスが起こり得ない(起こったとしても知るもんか by 未来人)世界を描いているので、多世界解釈は物語上の設定として必要は無い。その場合、もし既に目にした逆行自分に逆らうような行動を逆行後に気まぐれに起こそうものなら、そもそも予め目にしていたのは、その気まぐれな行動を起こそうとしている逆行自分だったということだ。気まぐれも込みで因果がうまい具合に閉じた世界がただ最初から存在しているのみで、そこに生きる登場人物は、パラドックスを起こさないための自制心を持つ必要すらない。それは諦観でも無気力でもなくて、現に僕らが「起こってしまった過去は変えられない」と何の疑いも無く信じるのと同じくらいの確からしさで、「起こってしまった自分の未来は変えられない」と、当然の摂理として内面化しているだけのことだ。そして確定した未来(過去)を知ることと、自由意志のもとでその行動を逆向きにトレースする事は、彼らの世界観では両立する。その最たる例がニールだ。

だから、僕らがストーリーテリングの前提として受け止めている因果律と自由意志の在り方を捉え直さない限り、テネットの登場人物の行動はひどくご都合主義、あるいは自己犠牲的に見えるはず。確かに一ノ瀬さんも仰る通り、時系列を読み解いただけで作品を理解した気になるのはまだ浅いのかもしれない。(未だにこんがらがってるけど…)


というのは僕の解釈なので、誰かと答え合わせしたいです。2日連続で付き合ってくれたパートナーにこれ以上しつこくテネットの話題を振るのも忍びなくて…。

普通に感想を言ってしまうと、インセプションの「階層」と違い逆行世界をシチュエーションで区別する事が出来ない分、わりとあからさまに色や音楽で区別をつけているのは面白かったです。最後運動会の組分けみたいなっててかわいい。あと、ノーラン作品はブルータリズム建築が本当によく似合う。東欧を舞台にしたのも納得でした。

本当は観てみたかったシーンは、回転ドアの中での対消滅の仕方と、時空をUターンする時に本人が見える風景だ。僕のナイーブな4次元観では、すべての人物は4次元空間上では、ある瞬間を表す「3次元の断面」が時間方向に積層して出来た4次元金太郎のような形をしている。それを未来方向へと垂直にサクサク薄切りしていくことで、時間の流れをその断面から観察することができる。

金太郎飴は本人の移動に応じてくねくねと傾いた形を取る一方で、ある一定の傾斜(=光子が描く世界線の傾き)の範囲内に収まる。ただ逆行者の金太郎飴だけは、(一往復半の場合)ちょうど下の図のような形で折れ曲がっている。この金太郎飴に水平に刃を当てるところを想像してほしい。過去からサクサクと切ると、突然回転ドアの内側で空中に体の断片が現れ、それが奇妙なスリットスキャン映像のようにみよーんと引き伸ばされて逆行者と第二の順行者に分裂する。

そして、2人の順行者と1人の逆行者とがしばらく同時に存在した後、今度は第一の順行者と逆行者がみよーんと対消滅する。どういう設定かは分からないが、もし時空のUターンが瞬間的に行われるなら、この「みよーん」は瞬間的に終わるだろうし、ゆるい弧を描くならもう少しヌルっとした「みよーん」になる。Houdiniでビジュアライズしてみたい。(追記: タリンの自由港ではドアの内部が見えるが、特にそういうスリットスキャン的描写もなくただ部屋の内部が回転してるだけだった。特にそういうこまい設定は考えてなさそう。テッセラクト同様に。)

これも素朴過ぎる時空の解釈なので多分間違っているのですが、逆行者の目線では、時空上をくるりと回転して引き返す際外の世界の時間軸が本人にとっての空間的次元の一つに揃う瞬間がある。その時、回転扉の内側の空間が突然インターステラーのテセラクトのような縞模様になるまで引き伸ばされて、過去現在に回転ドアを使用した人達が今からの時間差に応じた距離で並んで見える。その縞模様の部屋の遠く彼方には建設中と解体中の開口部が空いている。合ってるのかなぁ…。昔自分の部屋でよくこういうビジュアルを想像してた。自分の部屋の4次元マカロニを、長さ方向に切ると断面には何が見えるのかな? って。2次元住民の部屋が3次元時空に作るマカロニからの類推で考える。

ここまで時間をイジり倒してしまうと、あとは何が残っているんだろう。カットアップ、伸縮、反転…。あとは並進対称性とか? カノン進行みたいな。アルゴリズムたいそうやカイリー・ミノーグのMV、リプチンスキーのTangoみたいなアクションシーンになるのかな。さぞかしモサい揉み合いになりそう。ノーラン映画のアクションはいつもモサいけど。あるいは、Mr. Nobody のような分岐とか。どのみち、ジョジョの各部ラスボスの時空系スタンドみたいに、だんだん複雑化して訳わからんことになりそう。


カノンで思い出したけど、今更読み始めた『ゲーデル・エッシャー・バッハ』(GEB)にも蟹のカノンなるものが登場する。僕らが一番慣れ親しんでいるカノンは「かえるの歌」方式だけど、蟹のカノンはある旋律を逆行させたものがそれ自体への伴奏となっている。まさに音楽の回文。インセプションで再生速度を落としたエディット・ピアフがそのまま下層で響く重低音の旋律になっていたように、テネットのサウンドトラックにもそういう仕掛けが施されていたら面白い。誰か教えて欲しいです。

ところで最近作っているグラフィックデザインツールでLispという言語の処理系を実装しているのですが、Lispは、LispプログラムそのものをデータとしてLispプログラムに喰わせることが出来るという特異な性質を持っている。だからLispプログラムを実行する前にそのLispプログラム自身をLispの構文でもって自己改変させるなんて芸当が出来たりする(一種のマクロ展開)。文章で説明するとややこしい。どの言語にもそうした「コードを改変するための構文」はあるのだけど、コードそのものの構文とコードを改変するための構文は区別されている(C++のプリプロセッサがその例)。だから、Lispコーディングを通して得られるある種の異化感覚は、その言語構文にメタ言及するための構文がその言語自身に埋め込まれているという奇妙な自己参照性に由来している(と思っている)。そんなことに思いを馳せるうちに久々にゲーデル熱が高まって、関連本を読み漁るうちにGEBに辿り着いた。超面白い。こんな有名な本、もっと早く知りたかった…。

作品それ自体と同程度かそれ以上に、作品の背後に横たわる抽象構造だけでメシが進んでしまう体質は各分野に散らばっていると思う。純粋数学、お笑い、映画、現代美術、そしてハッキングと。そういう体質の持ち主は、メディアやジャンルを越えてある種のマインドセットで共鳴し合っている。それは対称性や自己参照性(ホフスタッターのいう『不思議の輪』)、あるいはメタ性を見出す歓びというか何というか。とにかく奴らはそういう審美眼がうまい具合に満たされるとエラく嬉しくなれてしまう。GEBでも取り上げられているエッシャーやバッハはまさにそういった気配を感じるし、ノーラン作品もそう。なんなら彼はエッシャー作品を眺めながら構想を練るらしい。

世の中の作品のほとんどが、ある表現形式を自明のものとして受け入れた上でその「内側」で完結する。逆にそういう形式の枠組みがあるからシーンやカルチャーなるものがまとまりをもって生まれるとも言える。だからこそ、その形式を用いて形式そのものへのメタ言及や相対化を仕掛けるような表現はどうしても希少になりがちだし、貴重だ。「ギミックでメシが進む」体質の人間としては、そういう表現に常に飢えている。とかいうと何だか賢ぶりたい感が出てしまうんだけど、別にそういうことでもなくて、最近なんかは、ぺこぱやアニメの『デカダンス』にハマってる。どちらも、漫才、MMORPG系アニメというジャンルをフリにした表現なので。ついでに言うとデカダンスで登場する2つの世界は双対関係になっていて面白い。

テネットは、時間芸術たる映画の中で時間そのものに自己言及する作品だ。360度映像が撮影から「フレーミング」という概念を取り去りながらも、そこから別の映像文法が生まれたように、物語の公理たる「因果律」が置き換わることで、全く新しいストーリーテリングの手法が立ち現れる。これはユークリッド幾何学の平行線公準を否定することで球面幾何学が生まれたのにも似ている。そして、球面幾何学における「三角形」を僕らが普段目にするような三角形として解釈すると破綻するのと同様に、テネットの物語における「原因と結果」「自由意志」を、僕らが慣れ親しんだ意味でのそれと解釈すれば、途端に作品全体が不自然なものになる。しかし、あくまでテネットという公理系の内側ではそれは無矛盾に閉じていて、それは作中の回転ドアを使いこなす人物達には何ら問題なく受け止められている。

これはテネットに対する遠回りな感想のつもりでした。確かにテネットは洒落臭いトンチ映画ではあるのだけど、僕らが「良さ」の局所解を求めて狭苦しくうろつき回ってるその山頂が、実は広大な適応度地形のほんの一部でしかないと気づかせてくれる感動は、既知の「良さ」の峰の頂上付近で器用に叩き出された高得点よりも桁違いに大きい。

それは「チャレンジを評価したい」とかかしこまった話ではなくて、もっと感覚的に、そういう表現が単にむちゃくちゃカッコ良く感じるだけなんです。カッコよさの様式の内側で無難にカッコつけている作品とは、カッコよさのオーダーが違う。

時間遡行というアイデア自体は大森望さんがパンフレットで挙げてらっしゃったような先例があるのですが、テネットは僕にとって、曇り一つ無くカッコ良いなぁと思えるブロックバスター映画でした。

こういう映画を見終わると、僕がノーラン映画に感じるこのカッコ良さを、同業の多くの人はゲーミングPCのデザインみたいなグラフィックやシネマルックのお洒落な実写MVとか、もっと幅広いことに感じられるのだろうな、羨ましいなぁ、と感じてしまって落ち込む。

女書

Sorry, this entry is only available in Japanese.

僕がUnicode表の中で一番気になっていた「女書」という中国南部の文字体系がとうとうNoto Sans Familyに加えられた。これでVJに使える

と思って気軽にシェアした所、女性が漢学に触れる事が許されなかった時代に彼女らが独自に編み出した表音文字だったと教えて頂いて震えた。「涙の言語」とも呼ばれているそう。

漢字自体の複雑さに加えて、限られた人しかその学習ができなかったゆえの識字能力の差は悲しい。漢字圏のそうした状況の中でひらがな、ハングル、女書といった表音文字が並行的に生まれた歴史はしっかり勉強したい。

新字体、簡字体を更に推し進めたような字体整理が進んだ未来には、今の漢字の複雑さやそれを「言語としての豊穣さ」として捉える価値観は、難読プログラミング言語のように露悪的に映っていたりするのかもしれない。だとしたらちょっとだけ痛快だなぁ。

https://github.com/notofonts/noto-sans-nushu

嫌な奴

Sorry, this entry is only available in Japanese.

言い訳すべくもなく「自分の性格は悪い」とはっきり自覚する体験を通して一番良かったのは、世の中に少なくない性格の悪い人達が、どうやってその自分の性格の悪さを自己正当化し続けているかをそれなりに理解できることだと思う。性格が悪いと自覚しながらそうあり続けるのはあまり愉快なことじゃない。

自分の場合は、すぐディスり散らかす性格のことを「日本的な同調圧力に屈せず思ったことを素直に言ってしまう実直さ/爛漫さ」だと暗示していたパターンだった。「ハイコンテクスト文化馴染めないんでw」という言い訳は頭の中で何度も繰り返していた。この手の性格の悪さはリベラルな人に多いので、同族嫌悪を覚える。

そういえば僕が高校時代から尊敬していた帰国子女のクリエイティブ・ディレクターが、最近出産したパートナーに「犬を産めばよかったのに」とこぼしたことを冗談めかして話していた。周囲も見かねて「その言い方は無いですよ」とたしなめると、ご本人は「僕、外人なので」とのたまった。ああ、この人はそのパターンか、と。おそらく彼の周囲には今までそれを指摘してくれる人がいなかった、もしくは指摘してくれる人を本人の中で「正義感に燃えるお気持ちフェミ」としてはねのけてきたのだろう。流石に邪推か。だけども、そういう振る舞いに心当たりがあるだけに見ていてしんどい。

これだけ女性蔑視はダメという社会合意がなされているわりにこの手のミソジニーが明らかに多いのは、取り返しのつかないインセルばかりを象徴的な仮想敵にするあまり、自分中のそうしたその無意識レベルの自己正当化に気づきづらくさせているのは一因としてあると思う。

かくいう僕もミソジニー体質だったので理解できてしまうのだけど、それなりに進歩的な価値観だと自認していて、自分なりの「これ以上はアカン」ラインを自分なりに死守しているとつい安心する。そして明らかに悪意に満ちたスリザリンばかりを反面教師していると、そこより遥か手前に超カジュアルに内面化している性差別を普通に見落とす。

性差別に限らず、パワハラから日和見主義まで、「性格の悪さ」のいろいろな側面には、こういう罠が潜んでいそうだなとふと思った。