メガデモ勉強会2021で発表しました

event, CG, レイマーチング, TokyoDemoFest, WebGL, GLSL, 発表資料, 登壇

昨日の2/14（バレンタインデー）に開催されたThe Tokyo Demo Fest team presents: メガデモ勉強会2021に参加しました。

私は「64KBのWebGLデモを実装する技術とデモ制作から得た『学びと発見』」というタイトルで発表を行いました。

発表スライドはこちらです。

Revision2020のPC 64K Introで優勝したデモ作品『RE: SIMULATED』を題材にして、効率的なデモ制作に必要なエディタ機能やWebGLのプロジェクトの構成、制作中に直面した問題と解決方法について解説しました。

発表の締めとして「CGを学ぶことで世界の解像度を上げるのが楽しい」「レイマーチングはCG入門に最適」という持論について語りました。

質疑応答と補足

  • 質問1: シェーダーを分割することで容量がどのくらい増えるか？
    • マルチパスを前提のエンジン設計にしたので、シェーダー分割してもTypeScriptのコード量は増えない
    • 重複コードはzlib（pnginator.rb）で圧縮されるため、シェーダーの圧縮後のコードもほとんど増えない
    • 前半と後半で2分割したときは45byteだけ増えた（PR）
  • 質問2: シェーダーの数と行数について
    • サウンドシェーダーは1ファイル。グラフィックス用のシェーダーは合計10ファイル
    • サウンドシェーダーは行数が1800行ほどだが、zlibで効率よく圧縮できるので、最終的なファイル容量にはあまり影響しなかった
    • グラフィックス用のシェーダーは最大（宇宙空間のレイマーチング）で700行、最小（Bloomのポストエフェクト）で10行ほど
    • 用途によって幅があるが、レイマーチング用のシェーダーだと平均して400行くらい
    • Shadertoyと同じようにCommonのシェーダーの仕組みも用意したが、重複したシェーダーはzlibで圧縮されるため、容量削減の効果は低かった
  • 質問3: ディレクションについて
    • 制作前に打ち合わせをしてBPMは決めていた
      • 音楽と絵の同期はBPMで行っているので重要
    • 方向性は絵が先行
    • 尺については音楽が先行
  • 補足1: Bloomのポストエフェクトはエンジンのビルトイン機能にした
    • 縮小バッファーを利用するマルチパスのBloomにしたので、ビルトインにしたほうがサイズを小さく効率よく実装できそうだったから
    • フォント描画用のテクスチャ生成機能などShadertoyにはない仕様も何個か実装した
  • 補足2: OpenGLよりWebGLの方がGLSLのコンパイル時間が長い
    • WebGLのデモではなく、OpenGLのexeによるデモにすれば、GLSLのコンパイル時間を短縮できる
    • Windows版のChromeおよびFirefoxでは、ANGLEを経由してDirect3D上でWebGLを実現しているため、ANGLEを経由する分だけGLSLコンパイルに時間のかかるケースが多い（Twitter）
    • chrome.exe --use-angle=gl というオプション付きでChromeを起動すると、ANGLEを経由せずにWebGLを利用できる（Twitter）

感想

かなり久しぶりに日本のデモシーンの人たちとワイワイできて楽しかったです！

最後のTokyoDemoFestは2018年の12月なので、もう2年以上も前なんですよね。時間が経つのは早いです。

discord上の懇親会では「どうすればライブコーディングを普及できるのか？一般人でも理解できるような実況が必要という仮説」「物理的な会場のクラブの体験とVRの違い」など興味深いお話を聞けて面白かったです。

素晴らしいイベントを企画・開催してくださったTDFのオーガナイザーのみなさん、本当にありがとうございました！

関連記事

過去の関連登壇や記事のリンクです。

event, CG, レイマーチング, TokyoDemoFest, WebGL, GLSL, 発表資料, 登壇
comments powered by Disqus

gam0022.net's Tag Cloud

Recent Posts

最新記事

Read more