昨年12月、ようやくプロジェクトが完了しました。 このビデオは、私たちの最新作であるImmersionと呼ばれる 4分間のアニメーションを示しています。 より正確には、これは一般に64kイントロと呼ばれるものの記録です。 しかし、これについては後で詳しく説明します。





このプロジェクトの作業は、過去2年間で最高の無料時間を費やしました。 すべてはRevision 2015で始まり、イースター休暇中に毎年ドイツで開催される大きなイベントです。 私たち二人はホテルから会場までの道に沿ってチャットしました。 前夜、64kBのイントロエリアでの競争のレベルは高かった。 とても高い。 経験豊富で有名なハンガリーのバンドConspiracyは 、真面目で素晴らしい作品でついに帰ってきました 。 私たちの最大の敵である「 近似」は、リリースサイクルの完了で完全に管理され、ストーリーテリングの大幅な改善を示しました。 生産性の高いグループであるMercuryは、イントロで独自の成熟したデザインスタイルを発見しました。



その年、私たちは手ぶらで来て、競技会には参加しませんでしたが、もちろんできるだけ早く帰りたかったのです。 しかし、これらの品質のイントロを示した後、私たちは疑問に思いました：美しいグラフィックス、優れたプロット、素晴らしいデザイン-このレベルにどのように上がることができますか？ 完全に実装したとしても、これら3つの競合他社すべてを打ち負かすことができる概念を思いつきませんでした。 言うまでもなく、私たちの技術スキルは各グループのスキルよりも低かったという事実です。 そして、私たちはホーエンツォレルン通りに沿って歩き、そのうちの1つが「発砲」するまでアイデアを交換しました。 海から成長する都市。 この概念は、正しく実装されていれば、イントロサブカルチャーが到達するレベルで競合する可能性があります。 改訂2016年 、準備をし、行ってください！



リビジョン2016はすぐに私たちを追い越しました。 リビジョン2017に間に合うでしょうか？ 残念ながら、この新しい期限に対処することはできませんでした。 イベントでどうなっているのかと尋ねられたとき、私たちは回避的に答えました。 「最初の部分は1年かかりました。 24時間以内に第2部を完了することができると確信しています 。 」 しかし、時間がありませんでした。 それにもかかわらず、リリースをリリースしましたが、2番目の部分は急いで行われ、 これは顕著でした 。 勝者と一緒にステージに近づくことさえできなかったほどです。 私たちは仕事を続け、必要なすべての愛を注ぎ込んで、最後に上記の最終バージョンをリリースしました。

64kイントロとは何ですか？

デモは、短編映画、ミュージックビデオ、ビデオゲームの岐路に立つデジタルアートの作品です。 非インタラクティブであり、ビデオクリップのように音楽に依存することがよくありますが、ビデオゲームのようにリアルタイムでレンダリングされます。



64キロバイトのイントロ（略して64k）はデモのように見えますが、サイズ制限が追加されています。 イントロは、サイズが65536バイト以下の単一のバイナリファイルに完全に収まる必要があります 。 追加のリソース、ネットワーク、追加のライブラリはありません。通常の要件は、Windowsと最新のドライバーがインストールされたPCで実行できることです。



このボリュームはどれくらいですか？ 比較の基準点を以下に示します。



64KBファイルに保存できます：

• CD品質の400ミリ秒のWAVオーディオ、または
• 192Kbpsから3秒のmp3、または
• .bmp形式の200×100 RGBイメージ、または
• イントロからのこの800×450スクリーンショットのような、中サイズと中品質のJPEG画像：

JPEG画像のサイズは65,595バイトで、64Kの制限を59バイト上回っています。



はい、そうです。投稿の冒頭に示したこのビデオは、1つのファイルに完全に収まり、ビデオのスクリーンショット自体よりもスペースを取りません 。



このような数字を見ると、間違いなく必要なすべての画像と音声をバイナリファイルに収めるのは難しいようです。 私たちは、私たちがしなければならなかったいくつかの妥協点と、すべてをこのような小さなサイズに収めるために使用したいくつかのトリックについてすでに話しました。 しかし、これでは十分ではありません。



実際、このような極端な制限のために、従来の技術とツールを使用することは不可能です。 独自のツールチェーンを作成しました-このタスク自体は興味深いものです。テクスチャ、3Dモデル、アニメーション、カメラパス、音楽などを作成しました。 アルゴリズム、手続き生成、圧縮のおかげです。 これについてはすぐに説明します。

いくつかの数字

使用可能な64Kに費やしたものは次のとおりです。

• 音楽：12.4KB
• 3Dメッシュ：12.5KB
• テクスチャ：4.8KB
• カメラデータ：1.3KB
• シェーダー：6.2KB、5000行のコードのうち
• エンジン：12.9 KB、2万行のコードのうち
• イントロ自体：12,000行のコード
• 費やした時間：長い時間、場合によっては千時間

このグラフは、圧縮後にさまざまなタイプのコンテンツが64KBを占有している様子を示しています。









このグラフは、最終リリースまでのバイナリサイズの変化（約2KBのアンパッカーを含まない）を示しています。

インスピレーションのデザインとソース

中心テーマが水に浸る都市であることに同意したので、最初の質問を自問しました。この都市はどのように見えるべきでしょうか？ それはどこにあり、なぜ浸水しているのですか、そのアーキテクチャは何ですか？ これらすべての質問に対する1つの簡単な答え：それは伝説の失われた都市アトランディスかもしれません。 これはまた、その外観を説明します：神の意志によって（文字通りデマックスexマキナ）。 これで私たちは決めました。









浸水都市の初期のコンセプト。 この記事で取り上げられているアートワークは、Benoit Molendaによって作成されました。



設計上の決定を下す際、私たちはプラトンがアトランティスとその運命を説明した2冊の本、 ティマエウスとクリチウスに導かれました。 特に、Critiaでは、都市の構造、その色、貴重なヘンカルの豊富さ（寺院のシーンの重要な要素になった）、都市の一般的な形状、ポセイドンとクレイトに捧げられた主要な寺院の詳細を詳しく説明しています。 プラトンは明らかに、彼が知っている国、つまりギリシャ、エジプト、バビロニアのスタイルの混合に基づいて説明を行っているため、これに固執することにしました。















ただし、主題に関する十分な知識がなければ、説得力のあるアンティークアーキテクチャを作成することは困難な作業のように思えました。 したがって、既存の建物を再作成することにしました。

• それらの一つは、アテナイのパルテノン神殿の複製です。
• もう1つは、Delphian Tholosの簡易バージョンです。
• 高架橋を作成するときに、 ポンデュガールとセゴビアの水道橋を利用しました 。
• 寺院は本質的に、古代世界の七不思議の一つであるエフェソスのアルテミスの寺院です 。

アルテミス神殿（Artemision）に関する参考資料の検索は予想外であり、経験が豊富でした。 最初は、写真、図、または地図のみを探しました。 しかし、 John Turtle Woodの名前を見つけたとき、すべてがより深まりました。 ウッドは神殿の場所を探していたのと同じ人物であり、結果としてそれを見つけました。 彼の名前で検索すると、ただのArtemisionよりも多くの結果が得られることを期待して、私たちはすぐに1877年に書かれた彼の本に出会った。彼は寺院の説明とスケッチだけでなく、失われた記念碑、資金に関する大英博物館との交渉、地元の労働者との関係、外交交渉など、任意の場所で発掘を行うことは不可能でした。



これらの本は、私たちにとってデザインの決定を行うために非常に重要でしたが、何よりも、それらを読んだことで、個人として、プロジェクトの作業をより高く評価しました。



























ところで、屋根はどのように見えますか？ ウッドを含むいくつかのスケッチでは、そこに穴があり、他のスケッチでは欠けていました。 ここには明らかに何らかの矛盾があります。 屋根の開いたモデルを選択することにしました。これにより、光線で城の内部を照らすことができます。 上記の図は、 エフェソスの発見からの建物の建築計画と断面を示しており、これは私たちの寺院の実際のモデルと比較することができます。

希望の外観を実現する方法

最初から、このイントロでは水の外観が重要であることを知っていました。 そのため、水中グラフィックの固有の要素を理解するために、参考資料の表示から始めて、多くの時間を費やしました。 ご想像のとおり、James Cameronの「Abyss」と「Titanic」 、 3DMark 11に触発され、照明はRidley Scott のBlade Runnerで研究されました。



水中にいるという正しい感覚を実現するためには、何らかの壮大な機能MakeBeautifulWater（）を実装して有効にするだけでは不十分でした。 それは多くの効果の組み合わせであり、適切に調整すれば、観客に幻想を納得させ、水中にいるような気分にさせることができました。 しかし、錯覚を破壊するには1つの間違いで十分です。 幻想が消える最初のリリース後のコメントに示されたとき、私たちはこのレッスンを遅すぎて学びました。















図からわかるように、さまざまな非現実的で、時には過剰なパレットも調査しましたが、そのような外観を実現する方法がわからなかったため、結果として古典的なカラースキームに戻りました。

水面

水面レンダリングには、平面からの反射が含まれます。 反射と屈折は、最初に側面に配置された1つのカメラを使用して別々のテクスチャにレンダリングされ、もう1つは水面の上に配置されます。 主通路では、水面は、法線ベクトルと注視ベクトルに基づいて反射と屈折を組み合わせた材料でメッシュとしてレンダリングされます。 トリックは、スクリーン空間の水面の法線に基づいてテクスチャの座標をシフトすることです。 この手法は古典的であり、十分に文書化されています。



これは、中規模では、たとえばボートのあるシーンではうまく機能しますが、たとえば、水から神殿が見える最終シーンでは、結果は人工的に見えます。 説得力を持たせるために、中間テクスチャーにガウスノイズを適用する芸術的なトリックを使用しました。 屈折のテクスチャをぼかすと、水に暗い外観と深みのある感覚が与えられます。 反射テクスチャをぼかすと、海の心配が増えます。 さらに、垂直方向により大きなぼかしを適用すると、水面から予想される垂直トレースを模倣します。









寺院のぼやけた画像が水面に映ります。



アニメーションは、頂点シェーダーで単純なGerstner波を使用して、ランダムな方向と振幅（指定された範囲内）で8つの波を追加して実行されました。 16個以上の波動関数を含むフラグメントシェーダーで、より小さな詳細が実行されます。 法線と高さに基づく人工的な後方散乱効果により、波の上部が明るくなり、上の画像では小さなターコイズの斑点として見えます。 ローンチシーンでは、レインドロップシェーダーなど、いくつかの追加のエフェクトが追加されます。





シェーダーのイラスト。 画像をクリックして、Shadertoyのシェーダーに移動します。

体積照明

最初の技術的な質問の1つは、 「光の柱を水に沈める方法」でした。 おそらく、美しいシェーダーを備えた半透明のビルボードが適していますか？ 媒体を介して進行する素朴な光線の実験を開始した。 初期のラフレンダリングテストでさえ、色の選択が不十分で、適切な位相関数がないにもかかわらず、ボリューム照明がすぐに説得力を持つようになったことを喜んでいます。 この時点で、私たちはビルボードで元のアイデアを放棄し、決して戻ってこなかった。



この単純な手法のおかげで、思いもよらなかった効果が得られました。 位相関数を追加して実験すると、 感覚は実際のものに似始めました。 映画の観点から、これは多くの可能性を開きました。 しかし、問題は速度でした。









光の柱がこのシーンにブレードランナーにインスパイアされた外観を与えます。



このプロトタイプを実際の効果に変える時が来たので、 DICEのプレゼンテーションである Sebastian Hillarによるチュートリアルを読み、 エピポーラ座標などの他のアプローチを研究しました。 その結果、 キルゾーンシャドウフォール （ ビデオ ）で使用されている手法に近い、いくつかの違いはあるものの、より単純な手法に落ち着きました。 エフェクトは、1つのフルスクリーンシェーダーによって半分の解像度で実行されます。

1. 光線は各ピクセルごとに放出され、各光円錐との相互作用は分析的に解決されます。
   
   
   
   数学的な計算については、ここで説明します 。 パフォーマンスの観点から、ライトのボリュームに境界メッシュを使用する方が効率的である可能性がありますが、64Kの場合、分析アプローチを使用する方が簡単だと思われました。 明らかに、レイは深度バッファの深度よりも遠くまで伝播しません。
2. 円錐内部のボリュームのビームの交差の場合、レイマーチングが実行されます。
   
   
   
   速度上の理由からステップ数が制限されており、レーンを避けるためにランダムなオフセットが追加されています。 これは、視覚的に疑わしくない、ノイズのためにストリップを削除する典型的なケースです。
3. 各ステップで、光に対応するシャドウマップが取得され、単純なHeny-Greenstein位相関数に従って光の効果が蓄積されます 。
   
   
   
   エピポーラ座標に基づくアプローチとは異なり、この手法を使用すると、媒体の密度が不均一になる可能性があり、変動性が追加されますが、そのような効果は実現しませんでした。
4. 結果の画像の解像度は、2パス双方向ガウスフィルターを使用して増加し、メインレンダリングバッファーに追加されます。 Sebastianチュートリアルの手法とは異なり、一時的な再投影は使用しません。 目に見えるアーチファクトを減らすために十分な数のステップのみを使用します（低品質設定では8ステップ、高品質設定では32ステップ）。

ボリューム照明を使用すると、適切なムードと独特の映画のような外観を実現できます。

光吸収

水中画像のすぐに認識できる側面は吸収です。 オブジェクトが削除されると、オブジェクトは次第に見えなくなり、色が完全に消えるまで背景と結合します。 同様に、光は水生環境に急速に吸収されるため、光源の影響を受ける体積も減少します。



この効果は、映画のような感覚を生み出す優れた可能性を秘めています。そして、それをシミュレートすることは非常に簡単です。 シェーダーで2段階で作成されます。 最初の段階では、オブジェクトに影響を与える光源を蓄積するときに、光の輝度に単純な吸収関数を適用します。これにより、光が表面に到達すると、光の色と輝度が変化します。 2番目の段階では、オブジェクト自体の最終色に同じ吸収関数を適用し、カメラまでの距離に応じて知覚される色を変更します。



コードには、ほぼ次のロジックがあります。

vec3 lightAbsorption = pow(mediumColor, vec3(mediumDensity * lightDistance)); vec3 lightIntensity = distanceAttenuation * lightColor * lightAbsorption; vec3 surfaceAbsorption = pow(mediumColor, vec3(mediumDensity * surfaceDistance)); vec3 surfaceColor = LightEquation(E, N, material) * lightIntensity * surfaceAbsorption;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

水生環境での光吸収のテスト。 色がカメラまでの距離と光源からの距離にどのように影響するかに注目してください。

植生の追加

私たちは間違いなく藻を使いたかった。 水中シーンの望ましい典型的な要素のリストでは、それらは最初の場所の1つに立っていましたが、それらの実装は危険であるように思われました。 そのような有機要素は実装が困難である可能性があり、不適切な実装は幻想への没入感を破壊する可能性があります。 それらは説得力のある形状を持ち、環境にうまく統合され、場合によっては表面下散乱の追加モデルが必要です。



しかし、ある日、実験の準備ができたと感じました。 私たちは立方体から始め、それを拡大縮小し、架空の茎の周りにらせん状にランダムな数の立方体を配置しました。これは、十分に長い距離から、多くの小さな枝を持つ長い植物に通すことができます。 モデルを変形させるために多くのノイズを追加した後、藻はほとんどまともに見え始めました。









まれな植物が少ないテストフレーム。



しかし、これらの植物をシーンに追加しようとすると、オブジェクトの数が増えると、速度が急速に低下することがわかりました。 したがって、説得力のある外観にするには、追加する数が少なすぎる可能性があります。 最適化されていない新しいエンジンは、最初の「ボトルネック」にすでにつまずいたようです。 したがって、最後の最後で、可視性ピラミッドを使用して粗いクリッピングを実装しました（最終バージョンでは正しいクリッピングが使用されます）。これにより、デモで密集した茂みを表示できました。



適切な密度とサイズ（正規分布の領域）があり、詳細が薄暗い照明によって隠されている場合、写真はおもしろく見え始めます。 さらなる実験では、藻類のアニメーション化を試みました。架空の水中電流の強度を調整するノイズ関数、植物が曲がる逆指数関数、正弦波が流れの先端をねじる。 実験中、私たちは真の宝物に出くわしました： 茂みを通る水中の光の放出は 、カメラから離れると消える海底の影のパターンを描きます。









植生が海底に影模様を投影しています。

粒子注入

最後の仕上げは粒子です。 水中調査を注意深く見ると、あらゆる種類の浮遊粒子に気づくでしょう。 それらに注意を払うのをやめると、それらは消えます。 パーティクルはほとんど目立たず、邪魔にならないように設定しました。 しかし、それらは具体的な媒体で満たされたボリューム感を与え、錯覚を強化するのに役立ちます。



技術的な観点から見ると、すべてが非常に単純です。イントロイマージョンでは、パーティクルは半透明のマテリアルを持つ四角形の単なるインスタンスです。 インスタンス識別子に従って1つの軸に沿って位置を設定することで、半透明性に起因するレンダリング順序の問題を単純に回避しました。 このため、すべてのインスタンスは常にこの軸に沿って正しい順序で描画されます。 フレームごとに、パーティクルのボリュームを適切に方向付ける必要があります。 実際、これの多くのフレームでは、シーンの粒子サイズと暗さが顕著なアーティファクトを非常にまれにしたため、これをまったく行いませんでした。









このフレームでは、粒子は深さの概念と、深さの増加に伴う密度の感覚を与えます。

ミュージック

高品質の音楽を約16 KBに収めるにはどうすればよいですか？ このタスクは新しいものではなく、 2000年の.productの後に書かれた64kイントロのほとんどは同様の概念を使用しています。 元の一連の記事は非常に古いものですが、その関連性は失われません。FR-08のサウンドシステムの仕組みです。



要するに、アイデアは楽譜と楽器のリストが必要だということです。 各インストゥルメントは、手続き的にサウンドを生成する機能です（たとえば、 減算合成および物理モデリングの合成を参照）。 楽譜とは、使用されるノートとエフェクトのリストです。 サイズを小さくするためにいくつかの変更を加えて、midiと同様の形式で保存されます。 音楽の生成は、プログラムの実行中に発生します。



シンセサイザーにはプラグインバージョン（ VSTi ）もあり、ミュージシャンはお気に入りの音楽作成プログラムで使用できます。 音楽を作成した後、作曲者はすべてのデータをファイルにエクスポートするボタンを押します。 デモにデータを埋め込みます。





デモを開始すると、巨大なバッファーで音楽を生成するためのストリームが起動されます。 シンセサイザーはCPUリソースを積極的に消費し、必ずしもリアルタイムで実行されるとは限りません。 したがって、デモやテクスチャなどのデータが生成される前に、ストリームを開始します。



Daniel Lindholmは、Dominic Rieszが作成した64klangシンセサイザーを使用して音楽を作曲しました。

作業プロセス

デモを作成するとき、最も重要な側面の1つは反復時間です。 実際、これは多くの創造的なプロセスに当てはまります。 反復時間が最も重要です。 反復が速くなればなるほど、より多くの実験を行うことができ、より多くのバリエーションを探索することができ、視覚を改善し、一般的に品質を向上させることができます。 したがって、創造性のプロセスにおけるすべての障害、一時停止、小さな摩擦を取り除きたいと考えています。 理想的には、いつでも何でも変更できるようになり、結果を即座に確認し、変更の過程で継続的なフィードバックを得ることを望んでいます。



多くのデモグループで使用される可能なソリューションは、エディターを構築し、その中にすべてのコンテンツを作成することです。 これはしませんでした。 最初は、C ++コードを記述し、Visual C ++内ですべてを実行したかったのです。 時間の経過とともに、ワークフローを改善し、反復時間を短縮するためのいくつかの手法を開発しました。

すべてのデータをホットリロード

この記事でアドバイスを1つだけ提供できる場合は、次のようになります。すべてのデータがホットリロードをサポートしていることを確認してください。 すべてのデータ 。 データの変更を検出し、これが発生したときに新しいデータをダウンロードし、それに応じてプログラムの状態を変更できるようにします。



シェーダー、カメラ、編集、すべての時間依存曲線など、すべてのデータを少しずつホットロードできるようにしました。 実際には、通常、エディターと追加のデモを立ち上げました。 ファイルが変更されると、その変更はすぐにデモに表示されます。



デモのような小さなプロジェクトでは、実装は非常に簡単です。 エンジンはデータの送信元を監視し、小さな機能が対応するファイルのタイムスタンプの変更を定期的にチェックします。 それらを変更すると、対応するデータの再起動が開始されます。



そのようなシステムは、そのような変更が依存関係とレガシー構造によって妨げられる大規模なプロジェクトでははるかに複雑になる可能性があります。 しかし、このメカニズムが生産プロセスに与える影響を過大評価することは困難であるため、努力するだけの価値があります。

カスタム値

もちろん、データの再読み込みは良いのですが、コード自体はどうですか？ 彼にとってそれはますます難しくなったので、この問題を段階的に解決しなければなりませんでした。



最初のステップは、定数リテラルを変更できるようにするトリッキーなトリックでした。 ジョエル・デイビスはこれを彼の投稿で説明しました 。ソースファイルの変更を認識し、それに応じて変数を更新するコードを使用して、定数を変数に変換する短いマクロです。 明らかに、この補助コードは最終的なバイナリファイルから欠落しており、定数のみが残っています。 これにより、コンパイラはすべての最適化を実行できます（たとえば、定数が0に設定されている場合）。



このトリックはすべての場合に適用できるわけではありませんが、非常に簡単で、数分でコードに統合できます。 さらに、定数のみを変更する必要があることが理解されていますが、デバッグにも使用できます。コードブランチを変更したり、 if（_TV（1））などの条件でパラメーターを有効/無効にします。

C ++の再コンパイル

最後に、コードの柔軟性を確保するための最後の手順は、 ランタイムベースのC ++ツールをコードベースに含めることでした。 コードを動的ライブラリとしてコンパイルしてロードし、シリアル化も実行します。これにより、プログラムを再起動することなく、このコードに変更を加えて実行中に結果を確認できます（この場合はデモ）。



このツールはまだ完全ではありません。そのAPIはコードに埋め込まれすぎて構造が制限され（クラスはインターフェイスから派生する必要があります）、コードのコンパイルと再読み込みにはまだ数秒かかります。 それでも、デモ内のコードロジックに変更を加えて結果を確認する機能は、創造的な自由を広く提供します。 現時点では、このツールの利点はテクスチャジェネレーターとメッシュジェネレーターにのみ使用されますが、将来的にはコンテンツを処理するコードセット全体にその作業を拡大したいと考えています。

続く

これで、H-液浸の開発に使用される技術に関する一連の記事として意図されているものの最初の部分が終了します。 この記事を校正してくれたAlan Wolfに感謝します。 彼のブログには多くの興味深い技術記事があります。 次のパートでは、テクスチャとメッシュの作成方法について詳しく説明します。