CEDEC 2024 -Day1-

こんばんわ。Pocolです。
CEDEC1日目が終了しました。
今日は以下の講演を聴講しました。

  • 鉄拳シリーズを通してみた格闘ゲームの変遷とその未来
  • “Game Survey”で開発・デバッグ効率が向上した取り組み AtoR from FINAL FANTASY XVII
  • PlayStation5上で人間のプレイヤーと同条件でのゲームプレイ自動化を実現するAI技術
  • プロシージャルゲームコンテント制作ブートキャンプ
  • リアルタイム光学エフェクトの深淵~究極表現への道と位置~
  • 『FINAL FANTASY VII REBIRTH』における会話イベントの量産とアニメーションワークフロー
    • 鉄拳シリーズを通してみた格闘ゲームの変遷とその未来

      とある諸事情で基調講演が事前収録に。
      鉄拳シリーズ30周年で,PlayStationで一番最初にミリオンを達成したのが鉄拳2とか,色々と多くのギネス記録を保持していて,1232件ぐらい検索するとヒットするらしい。他のゲームは普通数十件程度らしい。
      また,ネタとしてハリウッド映画の中で最低点を叩き出したことについても触れられていました。寝たい方はおススメとも力説されておられました(笑)。
      講演の中で鉄拳のストーリー紹介するのに「いらすとやさん」に平八などの絵を買いえてもらったとかで,ショートでまとめていたのが面白かったです。
      あとは,実売の情報もばばーんと出ていたのが,何気にすごかったです。
      他の会社とかだと伏せるところが多いですが。
      販売の割合を円グラフで紹介していたのですが,ヨーロッパなどで51%1で,北南米で33%の売り上げで日本は3%程度しかないそうです。
      鉄拳はコミュニティを大切にして,育ててきたっていう話が結構印象深かったです。やっぱり昨今見ていると,勝手に育たんよなと,いくつかの失敗事例とかも見て感じますし,やっぱりやってくれるファンを大切にしないといけないよなって共感しました。
      あと,意外と背景作り込んでいて,開発費が高騰するという問題に触れられていました。これは別に鉄拳に限ったことではなく,すべてのゲームがその傾向があると思います。この問題は本当に死活問題なのですが,うまい解決案が個人的にも出せておらず,業界全体の課題ではないかと思います。一筋の光となるのはやはりAIを利用した開発支援かなとは思っているのですが,まだ各社模索中ではないかと思っています。逆にもう打開したよ!っていう事例があれば,CEDECなり公の場で是非発表していただきたいです。事例ができると一気に物事が進む可能性はあるじゃないかなと思っています。
      アーケードゲーム開発経験はさっぱりなので,ゲーセンで電圧下がって,CPUクロックが下がり,浮動小数点誤差が発生するとかの話は,やっぱりプログラマーなんですかね,興味深かったです。あとは,ヒット判定が円柱というのもほぇぇと思いました。押し出しは球でやっているらしい。
      開発に役立つかどうかは全く分からないのですが,話としては面白かったです。

      “GameSurvey”で開発・デバッグ効率が向上した取り込みAtoR from FINAL FANTASY XVII

      今日聞いた公演の中で最も実用的な内容でした。
      CEDEC 2017のゼルダのデバッグの紹介が本公演のきっかけだそうです。
      バグチケット対応とかやっていると,「それどうやってやるねん?」とか「カメラのどの向きで,該当オブジェクトどれやねん?」みたいな文章から再現しても全然わからんわ。…みたいな状況が開発しているとよく発生するので,いちいち確認するのにSlackでメンション飛ばしたり,それの応答待つために何回かやりとりしないといけないとか,結構無駄なやりとりが発生しがちなんですが,カメラ座標の他にカメラ方向などのいくつかの情報を即時に反映させられて,無駄なやり取り少なくなって開発効率向上したよって話です。断片的な情報で聞くと,プログラム的にはあんまり大した内容ではないのですが,こういう地味なのが一番開発には効くと思います。自分的にはかなり良い公演でした。
       雑にいうとURIでジャンプして該当箇所の位置・方向を合わせて看板表示もできるようにしたよっていう感じです。講演資料が後ほどあっぷされたらぜひ見てみると良いと思います。おススメです。

      プロシージャルゲームコンテンツ制作ブートキャンプ

      Houdiniを用いて,水などのシミュレーションをしましたって話でした。
      Blender等に比べるとやっぱりお高いだけあってパフォーマンスが良いなどのメリットがあるそうです。
      TAさんとかが好きな内容かもしれませんが,UEとか使っている環境だと簡単にインポートできるとかでいいのかもしれません。正直に絵的にもしょぼいし,あんまりテクニックを教えてくれるという感じの講演でもなかったので,スポンサーセッションだなという感じでした。

      リアルタイム光学エフェクトの深淵へ~究極表現への道と位置~

      幾何光学ベースから波動光学ベースに手法をアップデートして,ボケ表現をグレードアップしたという内容でした。1時間に収まらないため,ボケの話に急遽絞られたようです。
      事前知識は必須ですが,これまで川瀬さんの講演を追ってこられた方は,非常にわかる内容だったのではないかと思います。ペンシルマップ作成が、リアルタイムになっていたのが意外と驚きでした。オーサリングしやすそうでいいなぁと思いました。
      あんまり,詳しく解説できる技量がないので,興味ある方はCEDILのスライドを参照していただくのが良いと思います。

      『FINAL FANTASY VII REBIRTH』における会話イベントの量産とアニメーションワークフロー

      自分はUEを仕事で使っていない勢なのですが,製品に使われている内容だけあって,非常に参考になるものがありました。
      4秒・6秒とか結構細かい単位でモーションを区切っていて,会話の尺から近いものを採用するとか,一言目は裏読みするため,二言目からカメラが変わるとか,…そういうことだったのか。みたいな知見も得られて,良かったです。でも講演で結局,手動調整9:自動調整1の割合で,あんまりやっぱり自動化できないのかーと,それでもゼロから作るよりは格段にマシだと思いますが,なかなか全自動にするのはやっぱりできないんだろうなと痛感しました。


明日からCEDEC!

こんばんみん。Pocolです。

いよいよ明日からCEDECですね。
今年は前日入りしています。
所属会社も変わったこともあり,レポート提出しないといけないので,レポート提出用に明日からこちらにメモを残していこうかなと思います。

ちなみ、みなさんご存じかと思いますが…
CEDECの受講パスですが,バーコードに不備があり交換の必要があるそうです。
詳しくは下記の公式ページをご参照ください。
パス交換のお願いとお詫びのご連絡

新しい名刺が欲しい方は会場でお声がけください!
明日からの3日間楽しみです!
それでは、また。


レイトレ合宿の季節ですね!

こんばんわ、Pocolです。
レイトレ合宿の季節になりましたね。

そういえば,去年のレイトレ合宿については何も書いていないような気がしたので,書いておきます。
昨年の結果は下記ページから確認できます。
https://sites.google.com/view/rtcamp9

私の去年のテーマは「GGXで描画する!」というものでした。
完全な鏡面反射では面白みがないので,すこしグロッシーな反射を描画したい。…と思いレンダラーを書いてみました。

ソースコードは下記にあります。
ponzu


実装としては,DirectX RayTracingを用いています。
デノイザーはクロスバイラテラルフィルタを使う単純なものです。
アセットはKenny Blaster Kitを拝借しています。

プログラム作成はかなりトライアルアンドエラーを繰り返すので,昨年からシェーダリロードに対応するようにしました。
今年はもうひとつ進めてblinkを用いたC++側のホットリロード対応しようかなって思います。

PNG出力はやっぱりfpngが圧倒的に速いので,昨年も用いました。恐らく今年も用いると思います。
https://github.com/richgel999/fpng

シーンデータはFlatBuffersを利用しており,デシリアライズの時間が短くなるようにしています。
https://github.com/google/flatbuffers

さて,今年開催されるレイトレ合宿10ですが,ルールや実行環境は下記の通りだそうです。
https://github.com/shocker-0x15/rtcamp10_setup/blob/main/exec_env_spec.md
今年は,256秒で描画しないといけないそうです。出来るだけ無駄なくプログラムを組まないといけないですね。
今年の参加エントリーはもう締め切られているため,レイトレ合宿への参加に興味がある人は,日頃からレイトレのプログラム画像をX(旧Twitter)などにあげると良いかもしれません。

Wave組み込み命令を使ったテクニック

今週の,Graphics Programming Weekly Issue 347 – July 7th, 2024で,Wave組み込み命令を使ったテクニックの記事が記載されていました。
非常に参考になるので,目を通しておいた方が良いかと思います。
Compute shader wave intrinsics tricks

ライティングに関係するものはSIGGRAPH 2017 Advances in Real-time Rendering Courseの”Improved Culling for Tiled and Clustered Rendering”に記載されています。
ゲーム開発者であれば,とあるプラットフォームSDKのサンプルプログラムにも記述があるので見てみると良いかと思います。

コースティクスシェーダ

ShaderToyにいい実装があったので,自分なりにパラメータ調整したやつ。

// Based on: https://www.shadertoy.com/view/3d3yRj
// See also: KdotJPG's https://www.shadertoy.com/view/wlc3zr

float water_caustics(vec3 pos, float thickness) {
    vec4 n = snoise( pos );

    pos -= thickness*n.xyz;
    n = snoise( pos );

    pos -= thickness*n.xyz;
    n = snoise( pos );

    pos -= thickness*n.xyz;
    n = snoise( pos );
    return n.w;
}

void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    vec2 p = (-iResolution.xy + 2.0*fragCoord) / iResolution.y;

    // camera matrix
    vec3 ww = normalize(-vec3(0., 1., 0.8));
    vec3 uu = normalize(cross(ww, vec3(0., 1., 0.)));
    vec3 vv = normalize(cross(uu,ww));

    vec3 rd = p.x*uu + p.y*vv + 1.5*ww;	// view ray
    vec3 pos = -ww + rd*(ww.y/rd.y);	// raytrace plane
    
    pos.y = iTime*0.25;	// animate noise slice
    pos *= 3.;		// tiling frequency

    float w = mix(water_caustics(pos, 0.085), water_caustics(pos + 1.0, 0.085), 0.5);

    // noise [-1..+1] -> color
    float intensity = exp(w*2.5 - 1.);
    fragColor = vec4(vec3(intensity), 1.);
}

ちなみに元にしたコードは,https://www.shadertoy.com/view/ssfBDfにあります。

バジェット&パフォーマンス メモ

開発の為に各社のパフォーマンスバジェット数などのメモを残しておきます。
基本はPS5世代のオープンワールド関連で,メモは随時更新します。
また、ここに載っていないものでご存じのものがあれば、ぜひコメント等にて紹介して頂けると幸いです。

Cyberpunk 2077

・GDC 2023, “Building Night City: The Technology of Cyberpunk 2077”.
エンティティは15 millionなので,15 * 100万 = 1500万エンティティ。
ワールドセクターは256m単位。



Spider-Man 2

GDC 2024, “Applied Mesh Analysis: Automating Distant City LODs in Marvel’s Spider-Man 2”.

Hogwarts Legacy

GDC 2024, “Open World Rendering Techniques in ‘Hogwarts Legacy'”.
TODO : 後で追記。

Alan Wake2

GDC 2024, “Large Scale GPU-Based Skinning for Vegetation in Alan Wake”.





Call of Duty:MW2



God of War Ragnarok

GDC 2023, “Rendering “God of War: Ragnarok””.



Horizon Forbidden West

GDC 2023, “Space-Efficient Packaging For Horizon Forbidden West”.

GDC 2022, “Adventures with Deferred Texturing in Horizon Forbidden West”.

Ghost of Tsushima

GDC 2021, “Zen of Streaming: Building and Loading Ghost of Tsushima”.


Final Fantasy 16

CEDEC 2023, “Final Fantasy XVI:大規模ゲーム開発に向けて開発環境の取り組み”.

Skull and Bones

CEDEC 2023, “Skull and Bones カメラ依存のテクスチャストリーミング実例紹介”.


Tom Clancy’s The Division

GDC 2016, “Global Illumination in Tom Clancy’s The Division”.


眼球のコースティクスのリファレンス

忘れないようにメモ。
眼球のコースティクスのリファレンス動画がX(旧Twitter)に上がっていました(5年前)。

高解像度バージョンの動画などはスレッドにリンクがあり,https://t.co/bc9HF4uWO5からダウンロードできるようです。

接線空間データの圧縮について

知識というのは更新しないダメですね。
法線データのOctahedral Encodingをよく用いています。

※図は[Cigolle 2014]より引用。

ここで,Octahedron を45度回転させて,符号をビットを別に持てば,表現する面積領域が増えるから精度が倍に上がるのと,OctWrap()の演算も無くなるので,デコードも高速できるそうです。

これが,John White 3Dというブログの,”Signed Octahedron Normal Encoding”という記事にのっていました。これをみて「ほぇぇ~」と感心しました。頭いい!
ただ、符号ビットを別に持つの何かやだなーと思っていたのですが,R10G10B10A2なら10bit分が残っているので,この32bitでNormal, Tangent, Bitangentを表現しちゃいたいところです。

以前に書いたかもしれませんが,SIGGRAPH 2020のDOOMで使っている,接線空間表現を使おうかなと思っていました。

※図は[Geffroy 2020]より引用。

しかし、今日もっといいやつを見つけました。
Jeremy Ongさんの”Tangent Spaces and Diamond Encoding”というブログ記事。この中でも上記のDOOMの方式が紹介されていますが,もっといいのがダイヤモンドエンコーディングというやつ。

※図は[Ong 2023]より引用

ここでも,Octahedronの考えを利用しています。ちなみにサンプルコードは下記の様です。

※コードは[Ong 2023]より引用

ダイヤモンドエンコードで得られた接線を表すデータを残りの10bit部分に入れてしまえば,うまくR10G10B10A2に収めることができます。

ちなみに,Octahedron Encodingですが,Z+の半球が約束されているのであれば符号ビットもいらないので,下記のHemi-Octで実現できるそうです。

※コードは[Cigolle 2014]より引用

…ということで接線空間データの圧縮についてでした。

参考文献

  • [Cigolle 2014] Zina H. Cigolle, Sam Donow, Daniel Envangelakos, Michael Mara, Morgan McGuire, Quirin Meyer, “A Survey of Efficient Representations for Independent Unit Vectors”, Journal of Computer Graphics Techniques Vol.3, No.2, 2014.
  • [JohnWhite3D 2017] John White 3D, “Signed Octahedron Normal Encoding”, https://johnwhite3d.blogspot.com/2017/10/signed-octahedron-normal-encoding.html, 2017.
  • [Geffroy 2020] Jean Geffroy, Axel Gneiting, Yixin Wang, “Rendering The Hellscape of DOOM Eternal”, SIGGRAPH 2020 Advances in Real-Time Rendering course.
  • [Ong 2023] Jeremy Ong, “Tangent Spaces and Diamond Encoding”, https://www.jeremyong.com/graphics/2023/01/09/tangent-spaces-and-diamond-encoding/, 2023.

Game Boy 研修(2)

今日は,エミュレーターの実装の進め方について紹介します。

基本的には…
MJHDというのブログ記事の「Rustでゲームボーイエミュレータを自作した話」に沿った手順で実装するのが良いと思います。
また,どのよう実装するかイメージがつかめない方は「脱・初級者のための自作GBエミュレーター開発」というスライドを参考にするものよいかもしれません。

Step.1 ROMをデコードする
Step.2 CPU処理を実装する
Step.3 PPU処理を実装する
Step.4 デバッガを実装する
Step.5 CPUテストROMを通す
Step.6 機能追加・改善を考え,実装する。

ROMをデコードする

まずは,ゲームボーイのソフト。つまりカートリッジデータが読み込みできなければ話になりません。
…なので,まずはカードリッジデータを読み込めるようにしましょう。カードリッジデータが読み込めれば,ゲームで使用する命令列などが読み取れるようになるはずです。
カートリッジのデータフォーマットなどについては,Pan Docs にまとまっているようなので,どういうデータ構造になっているのか?についてはドキュメントを読みましょう。
どんなプログラマーもドキュメントが読み解けるようにならなければいけません。特に,コンソールプラットフォームなどは秘密事項の塊で,インターネットに情報が出ることはめったになく,公式ドキュメントを見なければ何も出来ないということが多々あります。
そのため,ドキュメントを見ながら実装力をつける訓練の最初の一歩としてやってみましょう。

CPU処理を実装する

続いて,絵を出す前にCPU処理をエミュレートした方が良いでしょう。
ロード命令やジャンプ命令・加算・減算・ビット演算など基本的な命令を実現できるようになりましょう。
また,基本的な命令の実装を通じて,低レベルで何が行われるのか?を知ることが研修の目的の一つでもあります。

PPU処理を実装する

グラフィックスプログラマーを目指すものであれば,絵が出せなければいけません。また,やっぱりゲームは絵が出てこそ!というところもあるので,絵を出しましょう。
また、PPU(Picture Processing Unit)で何が行われているかを知りましょう。これを知るためには,PPU処理を実装するのが一番です。
PPU処理の実装が出来れば,一番処理にGame Boyプログラムで作った「Hello World」の文字列表示プログラムが動かせるようになるはずです。

デバッガを実装する

PPU処理まで実装出来たら,あとはひたすら精度・品質を上げていくだけです。
そのためには,デバッガの実装は必須でしょう。
また,デバッガを実装するためにどのようなことをしなければないのか,普段我々がVisual Studio何気なくつかっているブレークポイントなどの機能はどのようにしておこなわれているのか?などデバッガの仕組みを身をもって体験してください。

CPUテストROMを通す

最後の仕上げです。
実機で動作保証がされているCPUテストと呼ばれるROMを実行し,自作のエミュレーターで正常動作すること確認してください。
テストのROMは以下にあります。
https://gbdev.gg8.se/files/roms/blargg-gb-tests/
正常動作しない場合は,エミュレーターの実装に問題があるということです。
特に会社等では,テスト駆動開発を実施している会社もあるのと思うので,ここでテストの重要さ,製品の品質保証など,クオリティーを上げる大事さを学んでください。

機能追加・改善を考え,実装する

言われた仕様,あるいはお題に通りに作れば最低ラインは超えたことになります。少なくとも一般的な会社では言われたこと通りものを作ることが出来れば,きちんと給料は支払われるはずです。
ここから先は,「他とどう差別化するか?」という話です。同じ機能でも見た目をカッコよくできるのであれば,付加価値はあがるでしょう?また,他社や他人には出来ない機能追加をするのもよいかもしれません。あるいは,思い切って機能を削ることによる分かりやすさの改善・動作安定性なども差別化が図れるでしょう。
余力がある人は,自分なりのカラーを出せるように改造・改変してみてください。
特に昨今はKFCの事例のように何も考えない会社が作るとUX(User Experience:ユーザー体験またはユーザー体感)が激悪化しやすいです。また,どことはいいませんが解約手続きの面倒さなど,もう二度と使うもんか!と思うような酷いものあったりします。ユーザーにとって何か使いやすいのか?何が嬉しいのか?については我々は常に思考を巡らせる必要があります。特に日本の大手会社(例えば電機メーカーなど)などはこうした考えが非常に弱く,そのせいで海外メーカーにシェアを取られるというひどい状況に陥っています。携帯電話のUXの酷さなどはそのもっともたる例のひとつになるかもしれません。
我々はグローバルに戦っていく必要があります。そのためは,常にユーザーないし,使う側の立場にとって良いものを提供する必要があると思います。
そこで,余力がある人は作ったアプリに対して,ユーザーにとって有益であるような機能追加・機能改善を実行してみてください。
恐らく基本となる考え方は「自分だったら嬉しいか・喜ぶか」がベースになるのではないかと思います。そこから,平均と比べて自分がどのぐらいズレがあるのかを推測して補正していくと良いでしょう。