完全な文字起こし

デイブ：こんにちは、Robloxの創業者兼CEO、デイブ・バズッキーです。皆さんは現在、「テック・トークス」をお聞き、あるいはご覧になっています。今日は、第2世代ゲームエンジンの構成要素、クラウドとの連携、そしてユーザーが高解像度で瞬時に参加できるようにするための仕組みについてお話しします。ここには、Robloxを代表する技術のドリームチームが集結しています。

ヴァルン・マニ、セルゲイ・マケエフ、ツヴェタン・ツヴェタノフが参加しており、ストリーミングに関するあらゆる点について掘り下げていきます。Slimやアセットのトランスコーディングなど、Robloxが最終的に10万人のプレイヤーをサポートできるようにするすべての要素についてお話しします。過去10年、あるいは20年のゲーム業界を振り返ってみると、

3Dコンテンツをユーザーに届けるには従来の方法がありますが、この方法にはいくつかの課題があります。なぜなら、Robloxでは「即座に接続」を実現しようとしているからです。 ええと、スマホでも巨大なPCでも同じ体験ができるようにしようとしているんです。しかも、遅延なしで。従来のゲームの仕組みを見ると、そうはいかないですよね？

えっと、私が子供の頃を思い出すと、ゲームはフロッピーディスクというもので配布されていましたよね。でも今でも、ゲームは大きなDVDで配布されていますよね。そう言ってもいいですか？ 

ヴァルン：そうですね。そして、その鍵となるのは、すべてがひとまとめにパッケージされている点だと思います。そうですよね？DVDであれ、今日ゲームをダウンロードするにしても、分割できない巨大なパッケージとして提供されるわけですから。

だから、4.7ギガバイト、あるいは場合によっては10ギガバイトものデータがすべてダウンロードされるまで待たないと、プレイを始められないわけだ。 

セルゲイ：そうですね。ヴァルンが言ったように、ゲームによっては20ギガや40ギガにもなるものもあって、プレイを始めるまでにすごく長い時間待たなきゃいけないんです。それって、ゲームの「流れ」を台無しにしちゃうようなものですよね？

だって、例えば仕事が終わった後、1時間か2時間くらいゲームをしたいと思っていても、アップデートとかで30分や40分も待たなきゃいけないわけだ。まあ、それがまさに僕のプレイ体験なんだよ。 

デイブ：それって、ビデオや映画の世界でこれまで見てきたことと似てない？

昔、映画がDVDで流通していた時代を覚えているし、例えばBitTorrentの時代も覚えているよ。当時は全部ダウンロードする必要があったけど、今ではAmazonやNetflix、Hulu、Tubiに行けば、すぐに観られるようになった。でも、ゲーム市場ではまだそこまで進んでいないと思うんだ。

まだだ。まだだ。まだそうはなっていないと思う。 

ツヴェタン：それを狙っているのは私たちだけなんです 

デイブ：それを狙っているのは私たちだけです。つまり、歴史的に見て、Robloxは裏側でそのように機能してきました。多くの人は気づいていないかもしれませんが、Robloxのホームページに行って「プレイ」をクリックすれば、即座に参加できます。これは実は非常に非伝統的なやり方です。なぜなら、洗練されたゲームプラットフォームでは、プレイできるようになるまでに最大200ギガバイトものダウンロードが発生することもあるからです。

つまり、僕たちはすでにこのインスタントプレイを実装しているってこと？ そう。 

ツヴェタン：ええと、私の知る限り、Robloxはこの「即座に参加してプレイ」を可能にしている唯一のプラットフォームです。ああ、そうでした。 

ヴァルン：ああ、すみません。あと、さっき動画ストリーミングの話をしてたよね？ 例えば、映画全体をダウンロードしたくない場合、目の前の部分だけ必要な分だけダウンロードする、あれをバッファリングって言うよね。

僕は、映画をストリーミングしているわけだよね？ そう、その通り。でも、それは一方向的な話なんだ。そこには時間軸しか存在しないからね。うん、そこがここでの大きな違いなんだ。Robloxでそれを実現するのが難しいのは、完全にインタラクティブな3Dワールドだからで、インスタンスとアセットの両方をストリーミングする必要がある。これらは、Robloxにおけるあらゆるものの基本的な構成要素だからね。 

Dave: Roblox A A、そして、これはさらに難しくしていると思うんだ。なぜなら、従来のビデオゲーム市場では、

ハイエンドPCやローエンドのモバイル端末など、異なる環境向けのゲームバージョンを見かけることがよくあります。私の解釈では、ハイエンドPCでは数百ギガバイトものデータをダウンロードできるため、非常に大規模で複雑なアセットが使用されます。一方、モバイルでは、クリエイターが 

セルゲイ：ある時点で。

ええ、そうですね。それは、それは、とても良い指摘ですね。というのも、従来のゲームでは、いわゆる「アセットクッキング」と呼ばれるプロセスがあるじゃないですか。つまり、プラットフォームごとに、非常に最適化されたバージョンを準備するんです。それを、もっと、そうですね、動画ストリーミングの視点から考えると、DVDのようなものですよね。

えっと、動画は一度エンコードするだけですよね？そうですね。でも、どのストリーミングプラットフォームでも、同じ動画に対して複数のエンコード版を用意していて、デバイスに合わせて自動的に最適化されるんです。そして、現在のゲームでは、アセットを事前に最適化して、特定のプラットフォーム向けに細かく調整して出荷しています。

だから、クラウド上でプラットフォームごとに1つのアセットの最適化されたバージョンを生成できるんです。その通りです。 

デイブ：その話はひとまず置いておいて。というのも、少し前に僕らはこんなビジョンを描いていたんだ。若いクリエイターが体験コンテンツを作ったとき、それがどんな言語環境でも動作する、ってね。どんなデバイスでも、しかもそのデバイスごとに異なる解像度で動作する、というビジョンだった。

これから、その詳細について掘り下げていきます。さて、従来のゲーム市場といえば、パッケージ版かダウンロード版ですよね。私たちは、あらゆるデバイス向けの即時アクセス、低遅延といった課題を、すべてまとめて解決したいと考えています。そこで今日は、文字通り「3Dストリーミング」と呼ばれるものについてお話しします。

クラウド上のコンテンツについてお話しします。また、「Slim」と呼ばれるものについても触れますが、これは皆さんきっと大いに興味を持っていただけると思います。では、本題に入る前に、ヴァルンさん、まず「Slim」とは何か、そして私たちが「クラウドトランスコ」と呼んでいるものについて、少しビジョンを説明していただけますか？ええ。それらがどういう意味なのか、教えてください。 

ヴァルン：そうですね、少し視野を広げて考えると、私たちの全体的なビジョンは、ゲーム市場の10％を占めることです。

ええ。そのための方法は、クリエイターが制作するコンテンツに対して完全な自由を与えることです。えーと、私たちの成長の仕方について考えると、2つの側面があります。プラットフォームの拡大か、あるいはジャンルの拡大のどちらかです。プラットフォームの拡大とは、同じコンテンツをいかにしてあらゆるプラットフォームで動作させるかということです。

つまり、一度制作すれば、Robloxならどこでも動作するようにする、ということです。そしてジャンル拡大については、皆さんにますます印象的で、ますますクレイジーなものを生み出してもらいたいと考えています。 

デイブ：ところで、「どこでも動作する」と言うとき、文字通り、本当に巨大で、クレイジーで、楽しいものを想像してみてください。『グランド・セフト・オート』や『レッド・デッド・リデンプション』のような、ハイエンドなコンソール向けタイトルが、

2GBのAndroidスマホから、その間のあらゆる環境まで。その通りです。 

ヴァルン：PCから2GBのAndroid端末に至るまで、クリエイターが追加作業をすることなく、ただ動作するべきです。それが私たちのビジョンです。その通りです。クラウド、トランスコーディング、そしてSlimは、その道筋に向けて私たちが踏み出した最初のステップの2つに過ぎません。

デイブ：なるほど、それはちょっとした予告ですね。これからSlimについて説明し、トランスコーディングについても、たぶんあなたが説明してくれると思いますが、まずは全員の自己紹介から進めましょう。セルゲイ、戻ってきたね。エンジン最適化に関するあなたの経歴を少し教えてくれる？ 世界で最も楽しいことの一つだよね？

C++やアセンブリ言語、CやD言語とか、最近取り組んでいることを少し話してもらえますか？ 

セルゲイ：ええと、そうですね、さっきおっしゃっていた通り、ええ、私はずっとゲームやゲーム関連の仕事をしてきて、人生の大半を、地域限定のXboxとかから始めて、そういった最適化作業に費やしてきました。

えーと、それから。Robloxのことを初めて知った時、僕は本当に衝撃を受けました。一度だけ作成すれば、ゲームに限らず、どんな体験でも、追加のユーザー操作を必要とせずに、あらゆるプラットフォームやデバイスで実行できるというアイデアに。

これこそが、極めて困難な技術的課題なんです。 えっと、まあ、誰もが想像できる通りですよね？ だから、それには、えっと、従来の最適化、例えばCMDやマルチスレッド、GPUのスケジューリングを非常に慎重に行うことなど、そういったものがたくさん必要になるんです。でも同時に、単一のデバイス上でどこまでスケールできるかには、ある種の限界があるんですよね。

幸いなことに、私たちにはクラウドがありますよね？ そこで、この処理の一部をクラウドにアップロードして、デバイス側をサポートし、より大きな壁を効率的にレンダリングできるようにするんです。ある程度の範囲では、例えば物理的なデバイスのメモリに収まりきらないような壁でもレンダリングできるようになります。というのも、それらはサーバー側にも存在していて、サーバーがすべてのクライアントが効率的にレンダリングできるよう調整してくれるからです。

デイブ：そうですね。要点をまとめると、これからお話しするヒントの一部として、従来のゲームエンジンは通常C++で書かれていて、すべてのアセットをダウンロードする仕組みになっています。でも、例えばプレイしたいゲームが「世界全体」だったとしたら、誰もその世界全体をDVDに収めることはできません。

だから、あなたが本当に示唆しているのは、Googleマップやその類のものに見られるようなことなんです。 そのすべてを同じ場所に収めるなんて、到底不可能です。ですから、私たちが「ストリーミング」と言うとき、ゲームやエントンにおいても同じことが言える、というのが話したいことの一部です。ロブロックスにたどり着いた経緯や、あなたの経歴、そしてクラウドトランスコーディングとは何かについて、少しヒントをいただけませんか。

では、 

ツヴェタン：えーと、Robloxに入社する前は、2つの分野で実務経験を積んできました。1つは、建築、建設、機械工学向けの3D設計・シミュレーションソフトウェアです。もう1つは、大規模分散コンピューティングでした。Robloxはまさにその両方の要素を兼ね備えているので、これらの分野で得た知識をRobloxに活かせるのです。

デイブ：そうですね。では、Robloxでのストリーミングについて話を進めましょう。えーと、ビデオストリーミングとは何かは分かっています。ビデオのストリーミングというのは、ある意味、リニアなものですよね？ 必要なのはフレーム一つずつで、それを次々と送信していくだけ。3D環境でのリアルタイムストリーミングがどういうものか、教えていただけますか？ 

ヴァルン：実際のところ、今のRobloxゲームのほぼすべては、インスタンスやアセットで構成されているじゃないですか。

インスタンスは、いわばワールドの構造のようなものです。そしてアセットは、実際のコンテンツとしてそのインスタンスを駆動する要素です。えーと、ストリーミングについて考えると、インスタンスのストリーミングと、それらのアセットのストリーミングの両方が必要になります。それを行わなければならないのです。つまり、ビデオストリームの場合、アセットは1つだけで、それがビデオそのものです。

Robloxでは、それを何千回、1万回と、何度も何度も繰り返しています。ですから、「インスタントストリーミング」と言う場合、周囲の世界を「必要十分な量」だけストリーミングしようとしているわけですが、プレイヤーがどう動くかは分かりません。プレイヤーはこっちへ歩くかもしれないし、あっちへ歩くかもしれません。世界の一部を「必要十分な量」だけストリーミングするか、バッファリングしたいのです。

そして、そのバッファリングした世界の中で、アセットを正確に適切な品質でバッファリングしたいのです。セルゲイが言及したように、動画には異なる品質レベルがあります。メッシュについても同様で、画像についても同じことが言えます。 

デイブ：では、これを分解して考えると、インスタンスというのは私たちが馴染みのあるものと言えるでしょうか？

車、木、別の人物、丘、そういったものですね。そして、アセットとは、それらのインスタンスを構成する技術的な要素のことです。つまり、それらの3Dオブジェクトの内部にあるものですね。ゲーム制作の現場では、三角形の塊やテクスチャの塊といったものがあり、私たちは、それらの中からどれを

いつでも実際に読み込むか、ということです。 

ヴァルン：そうですね。そして、それらをどの表現形式で読み込むか、ということです。つまり、ゲームの世界を歩き回っているとき、デバイス側が「よし、あの木が必要だ」と判断するわけです。その木は、多数のメッシュやテクスチャ、将来的にはアニメーションやオーディオなどで構成されています。

そこで、デバイスは判断を下すんです。「よし、あの木の位置や重要度、画面上で占める面積に基づいて、テクスチャは高画質で、メッシュは中画質で。オーディオについては、まだ必要ないかもしれないから、オーディオの読み込みは保留にしておこう」と。つまり、常にそういった判断を 

デイブ：つまり、ある意味、これは私がマッピングソフトを使う時の感覚に少し似ています。私は、小さな画像やマップの一部だけを読み込むんです。

つまり、その3D版や、インタラクティブな3Dコンポーネントについても話しているわけですね。わかりました。そして、ここには裏側で非常に重要な要素があります。私たちのビジョンは常に、どのデバイスや環境であっても、適切な要素をできるだけ早く読み込めるようにすることだと考えています。

それに、時々こう言うんです。「魔法のような感覚を最大限に引き出すために、できるだけ素早く表示したい」と。まるで「わあ、世界が目の前に現れた！」って感じですね。それでセルゲイ、何を読み込み、何を表示するかを、どうやって選別し、整理しているんですか？ 

セルゲイ：そうですね。えーと、最適化、つまり、知覚される、あの、レイテンシーのようなものですね。

それは非常に重要です。ヴァルンが先ほど言及したように、私たちは常に画面上の領域や、オブジェクトの重要度を測定しています。例えば、木を至近距離で見る場合と、同じ木を非常に遠距離から見る場合では、それらはまるで別の木のように見えるでしょう？

だから、遠くから見た場合、細かいテクスチャのディテールとかは、あまり気にならないでしょう。だから、木には低解像度のテクスチャを使っても問題ないんです。 えっと、画面上ではすごく小さいから、それが低解像度のテクスチャなのか高解像度のテクスチャなのか、見分けることなんてできないでしょう。

その代わり、データ量が少なくて済むので、ほぼ瞬時に読み込めるんです。でも、その木に近づくと、徐々にデータを読み込んでいき、より詳細な見た目になります。だから、その変化に気づくことも、違いを見分けることもできないけど、すぐに、本当にすぐに、それを見て操作できるようになるんです。

デイブ：それに、これに関連して、2GBのAndroidスマホやゲーミングPCを使っている時、すぐに何かに参加したいと思うことがあります。インターネットはすごく速いですが、帯域幅には限りがあります。10Mbpsであろうと100Mbpsであろうと、そのパイプを通して世界を押し込もうとしているようなもので、そこで押し通す情報のバランスを取らなければなりません。

あと、僕が時々こう考えるんだ。近くにある1本の木と、遠くにある100本の木が、同じ情報量で表現されることがある。でも、遠くにある100本の木は、近くにある1本と同じ視覚的な重要度を持っているかもしれない。だから、解像度を変えて表示するんだ。

例えば、近くにある木は、遠くにある木よりもはるかに高精細に描画されます。 

セルゲイ：ええ、その通りです。そして、あなたが言及した重要な点は、単にオブジェクトの重要度を測るだけでなく、どれだけのコンピューターリソースが利用可能か、ということです。

メモリはどれくらいあるか、ネットワーク帯域幅など、あらゆる要素を考慮しています。つまり、パフォーマンスを含め、ユーザー体験に影響を与えるあらゆる要素を考慮しているのです。メモリの容量など、あらゆる要素を考慮しています。 

デイブ：では、インスタンスは木のようなもので、アセットはメッシュやテクスチャのようなものだと話しましたね。

それらがどう違うのか、そして裏側で実際にアセットストリーミングで何を行っているのか、もっと詳しく教えてもらえますか？ 

ツヴェタン：はい。ええと、例えば、サーバーからストリーミングする際、何が重要なのでしょうか？そうですね。その重要度に基づいて、Gがこの情報を各クライアントにプッシュし、各クライアントは状況に応じて、そのアセットに対して異なるインスタンスを受け取ります。

表示されていますか？ 表示されていません。インタラクティブな領域に参加していますか？ それとも参加していませんか？ アセットストリーミングに関しては、ワールド内の内容を実際にストリーミングするのはクライアント側です。ええと、セルゲイが言ったように、ターゲットとする品質やデバイスの性能に基づいて、品質とデバイスの性能に基づいた、まさにその品質の表現のみをターゲットにしています。

だいたいそういう仕組みです。えーと、つまり 

Dave: 遠くにある木々は、うまくいけば非常にコンパクトですよね？解像度が低く、リソースをあまり消費しない。そうすれば、より近くにある木に、より多くの時間と計算リソースを割くことができます。そこで、「コンテンツパイプライン」あるいは「アセットパイプライン」と呼ばれる仕組みがあります。

ゲームクリエイターとして、このトランスコーディング・パイプラインが具体的にどう機能するのか、少し教えてもらえますか？例えば、Roblox Studioを使って素敵な車を作ったとします。その裏側では何が起きているのでしょうか 

ツヴェタン： 

デイブ：シーンの背後で何が起きているのでしょうか？ 

ツヴェタン：エンジンの改良に伴い、デザイナーやゲーム開発者の意図した芸術性を維持したいとも考えていました。

そこで、クラウドトランスコーディングというアイデアを思いつきました。これにより、クリエイターからコンテンツを取り込み、保存し、開発用デバイスや、クライアントが必要とするデバイスや機能に基づいて最適化することができます。そして、このパイプラインはエンドツーエンドで、オンデマンドかつ遅延型です。 つまり、クライアントが特定の表現形式をリクエストした際、その表現形式がまだ存在しない場合にのみ、処理を開始します。

もし存在していれば、そのまま返します。つまり、クライアントに提供する帯域幅と処理リソースの面で、非常に最適化されているわけです。ですから 

Dave: ええと、私たちが、この仕組みがなかった頃、あるいは実はつい最近まで、こうしたアセットの忠実度には制限を設けざるを得なかった時期がありました。

例えば、車の三角形はこれくらいまでしか使えない、と決めて、三角形が多ければ多いほど車はリアルに見える、といった具合です。あるいは、テクスチャのサイズにはこれだけのピクセル数しか使えない、といったこともありました。今私たちが言っているのは、その車をどのように構築したとしてもアップロードでき、その後、裏側でトランスコーディングが行われるということです。

その車の様々なバージョンを、三角形の数をどんどん減らして生成しているのです。 

ツヴェタン：はい、その通りです。あるいは、将来的には増加させることも可能です。ええ。そして、ええと、現在私たちには、エンジンの改良や利用可能な演算能力に応じて、三角形の数やテクスチャ、マップ、オーディオ、ビデオ、アニメーションなど、必要な要素の表現を向上させることができる機能があります。

つまり、 

デイブ：つまりこれはオンデマンドですね。セルゲイ、さっきあなたが言っていたのは、以前は「ベイク」と呼ばれる処理があって、ハイエンドなものをベイクしていたということですよね。私たちは、本質的にオンデマンドでベイクしているわけです。その車の様々な解像度でのバージョンが多数用意されています。それらはすべてそこに存在しています。そして、遠くにぼんやりと見える車は、それらの低解像度版の一つなのかもしれません。

そして、これは、ええと、私たちが「トランスコーディング」と呼んでいるものだと思います。そうです。では、トランスコーディングはどのように機能するのでしょうか？例えば、100万個の三角形をどうやって1000個に変換するのですか？つまり、その、ええと。 

ツヴェタン：ええと、インジェストですね。そうです。スタジオでは、実際にその100万個の三角形メッシュを取り込みます。それを、当社のバックエンドにあるコンテンツプラットフォーム、つまりバックエンドシステムに保存します。

そして、リクエストに応じて、LOD処理を実行するんです。 

デイブ：LODってやつですね。Level of Detail、つまり 

ツヴェタン：状況に応じて、そのメッシュやテクスチャの限られた表現において、できるだけ品質を維持しようとしているんです。 

デイブ：じゃあ、ヴァルン、これがデバイス間でどう機能するか考えてみると、君は、つまりクリエイターだよね。

君が巨大な高解像度の車を配置したとしよう。僕はローエンドのAndroid端末を使っている。君はハイエンドのPCゲーミングマシンを使っている。それでも同じゲームがプレイできるといいんだけど。その通り。具体的には、僕たち二人にとって何が起こるのか？そして、 

ヴァルン：つまり、基本的に、私のクライアントがオンラインになると、「やあ、僕はローエンドのAndroid端末だよ。これが必要なんだ」ってなるわけ。実は、まだ触れていなかった点があるんだけど、これは単にディテールのレベルの問題じゃなくて、プラットフォーム固有の表現の問題でもあるんだ。

つまり、AndroidやiOSといった各プラットフォームには、それぞれ固有の表現方法があるんです。テクスチャを圧縮したり、最適に動作するように調整したりできるんですよ。だから、私のAndroid端末がオンラインになると、「ねえ、あの木のローエンド版テクスチャのAndroidバージョンが欲しい」と要求するわけです。するとクラウドサーバーがそれを生成してキャッシュしておくので、次にAndroid端末がオンラインになっても、

再処理する必要はなく、私が作成したバージョンをそのまま送信できます。PCがオンラインになると、「おい、俺には世界中のあらゆるリソースがあるんだ。高品質版をくれ、非圧縮版をくれ。最高品質のものを求めているんだ」と言うようなものです。そして、それをキャッシュします。つまり、これは将来にわたって無限に通用するということです。

デイブ：それに、無限に瞬時でもあります。僕は『グランド・セフト・オート』が大好きなんですが、彼らは、本当に驚愕するような新バージョンをリリースする予定で、すごく楽しみにしています。もし僕が、あるアセットを調整したいアーティストだったとしたら。僕たちの、うまくいけば将来のシステムでは、再アップロードに5秒ほどしかかからないでしょう。

あなたと私のゲームが、そのアセットの再トランスコードをトリガーするんだ。 文字通り、ピーク時の同時接続数、例えば2500万人が『Grow a Garden』のようなゲームをプレイしている状況でも、5秒から10秒で、その新規プレイヤー全員に、その新しいアセットが反映される可能性がある。だからこそ、これはある意味未来の形だと思うんだ。なぜなら、『グランド・セフト・オート』の素晴らしさの一部は、彼らが非常に高いクオリティを最初から組み込んでいる点にあると思うから。

彼らはそれを巨大なDVDに収録するわけですから、完璧であることを保証しなければならず、それを修正する余地はありません。その時点で絶対に完璧に仕上げなければならないのです。そして、そして、そして、そこで私は、私は、おそらく最後に。将来を見据えた対策として、瞬時の変更に加え、芸術的な意図を保存すること、つまりオリジナルの芸術作品を保存することには、何か良い点があるように思えます。

ある意味、それがどう役立つか、少し話してもらえますか？えっと、 

セルゲイ：はい。つまり、私たちは、できるだけ多くのオリジナルの芸術的コンテンツをキャプチャしようとしていて、そのために、すべてのアセットのソースバージョン、つまり元のバージョンを保存しているんです。そして、ご想像の通り、私たちは、例えばテクスチャのよりシンプルなバージョンを生成してダウンサンプリングするだけでなく、将来的にアップサンプリングすることも可能です。なぜなら、私たちはすでに、元の意図が何であったかというセマンティック情報をキャプチャしているからです。

テクスチャの簡略版を生成してダウンサンプリングするだけでなく、将来的にアップサンプリングすることも可能です。というのも、元の意図といったセマンティックな情報をすでにキャプチャしているため、将来的にこのアセットをアップスケールできるからです。つまり、ユーザーの操作を一切必要とせずに、

見た目をより良くできるんです。 

デイブ：その通り、それは将来に向けて大きなヒントになるでしょう。えーと、では、これまで話してきた内容に、もう一つ要素を加えましょう。つまり、ストリーミングを行い、瞬時に修正を加え、クラウドトランスコーディングを行い、あらゆるLOD（詳細度）を配信する。そして、冒頭でほのめかしたように、それを「Slim」と呼ばれるもので補完するつもりです。

Slimはワークアウトプログラムではありません。Robloxのようなものでも、Robloxのスナックのようなものでもありません。それらは、うまくいけば私たち全員を本当に気分良くさせ、頭をクリアにしてくれるものですが、Robloxエンジンの文脈における「Slim」とは何でしょうか。 

セルゲイ：そうですね。えーと、では。ちょっと話を戻して、あの、例えば木の話、もう一度例を挙げましょうか？

つまり、木があるとして、さっき言ったように、遠くに複数の木があるような状況で、Slimはそれらの個々の木をすべて森のようにまとめ、最適化するんです。個々の木としてではなく、もっと大きなものとして最適化する。個々のリソースの集約みたいなもので、

これがSlimの技術です。常に特定のコンテキストにおいて、そうしたアセットを最適化します。例えば、建物があるとしましょう。 その建物の中に、たくさんの、えーと、部屋があるとして。建物の外にいるなら、中の部屋なんて気にならないでしょう。そこで、Slimはこの文脈を認識していて、その場合のように建物の内部をすべて非常に効率的に削除し、最適化して、そのアセットの非常に最適なバージョンを生成してくれるんです。

Dave: そう、これの設計を進めてくる中で、僕たちが、いや、僕が考えていたユースケースが3つあるんだ。1つ目のユースケースは、人々がますます複雑なアバターを作っているってこと。歴史的にRobloxでは、服を何枚重ね着できるか、アクセサリーをどれだけつけられるか、アイテムをどれだけ持てるか、といった点にすごく慎重だった。

でも、将来的にはアバターに100個ものアイテムを装着する時代が来るかもしれません。クリエイターたちはパフォーマンスの面でも非常に賢明で、パフォーマンスを優先するために、あえてアバターの精細度を抑えることもあるでしょう。つまり、複雑なアバターが第一のケースです。第二に、あなたが言及したように、遠く離れた場所に100本の木があっても、誰もそれとはインタラクションしないようなケースです。

そして、3つ目は、内部に部屋がある建物かもしれません。ええと、私たちがここで試みようとしているのは、それが動くアバターであれ、たくさんの木々であれ、建物であれ、このまったく同じシステムが、本質的に単一のオブジェクト、単一のメッシュ、単一のテクスチャに合成されるということです。これは本当に驚異的です。

えっと、 

セルゲイ：はい、その通りです。まさにその表現がぴったりですね。つまり、このシステムは複数のアセットを動的に合成して表現し、その合成の境界や詳細レベルなどを動的に決定するのです。常にこのワールドコンテキストの中で動作しています。

つまり、2つの異なる体験において、ターゲットデバイスや使用されるコンテキストに基づいて最適化が異なるのと同じようなものです。また、そのコンテンツの動的な更新もサポートしています。ですから、常に静的な最適化というわけではありません。

何かが時間の経過とともに変化する場合、それを動的に更新できるため、その変化はスリムな表現に反映されます。 

デイブ：ええと、私がこれを本当に気に入っている理由の一つは、まるで自分がRobloxの開発者になったような気分になれることです。例えば、大規模な展開や、非常に複雑なアバターを実現したいと強く望んでいたとします。

夢のような話かもしれませんが、例えば、近くにいる人に近づくと、相手が帽子を脱いだり、新しいアクセサリーをつけたりできる。これが、近くにあるオブジェクトに対してこのシステムが機能する仕組みで、通常は高精細で動作するでしょう。そして、そのアバターが遠ざかっていくにつれて、単一のオブジェクトへと合成されていきます。

そして、LOD（詳細レベル）に合わせてさらに遠ざかっていきます。ええと、冗談で言うんですが、究極の形としては、遠く離れたアバターが12個の三角形と、本当に小さなテクスチャで構成されるようなものです。これは、まさに開発者が夢見てきたようなものだと思います。そして、これが可能にするものの一つは、より大きなワールドの実現です。

デバイス間をまたいで。 

ヴァルン：その通りです。つまり、Slimが本質的に行っているのは、スケーラビリティの新たな軸を提供することです。これまで、異なる詳細レベルでのクラウドトランスコーディングについて多く語ってきました。今、ここにコンポジット、つまり合成という別の軸のレベルを追加しているわけです。そうですよね？そして、ここでは2×2のマトリックスを想像してみてください。その上のどの点も、有効な体験となるのです。

その通りです。つまり、高品質でコンポジティングを低く抑えることもできれば、非常に低スペックのデバイスや別のデバイスを使っている場合は、高品質でコンポジティングを高くすることも可能です。そして、それらのどのポイントも理にかなっています。ですから、巨大なワールドについて言えば、そのワールド全体が12個の三角形で構成されていても構いません。また、十分に離れていれば、あるいはそれが違いを生じない場合なら、なおさらです。

Dave: そこで、ユーザー体験について、そしてSlimがどのようにしてより良いユーザー体験につながるのかを考えてみます。LOD（詳細度）について考えるなら、クラウドトランスコーディングが思い浮かびます。Slimについて考えるなら、現在のRobloxや1年前のRobloxと比較した際のストリーミングが思い浮かびます。これはユーザー体験にどのような影響を与えるのでしょうか？ 

ツヴェタン：ええ、Slimについては、開発者がより豊かで大規模かつ複雑な世界を作り出し、それがエンドユーザーに対してどのように振る舞い、インタラクションできるようにするという考えで構築しています。

ええと、エンドユーザーと相互作用し、反応する世界です。シーメンス？ええ、非常に簡単に。まるで、ええと、エンドユーザーにとって、そのユーザー体験は、まるで最も高性能なマシンを使用しているかのように全く同じになります。そして、ええと、Slimは、ええと、現在、静的モデルを可能にするシステムです。そして私たちは、ええと、ご存知の通り。 将来的には、階層的に生成されるアバターや動的モデルを実現し、エンドユーザーにとってシステムを可能な限り高速化できるようにする予定です。 

デイブ：エンドユーザーにとっては、スペックが低い端末でもより豊かな世界を体験できるということですね。

私のローエンドなスマホでも、あなたのゲーミングPCで一緒に遊べるようになるかもしれません。クリエイターは、アバターの服のレイヤー数を気にせず、より高精細なものを作れるようになります。より複雑な乗り物や、精巧な機械的なオブジェクトも、Slimによって圧縮されることになるでしょう。これは本当に、本当に素晴らしいことです。

それから、これらがいかに連携するかについても考えてみる必要がある。クラウドトランスコーディングについて話したよね。つまり、低LOD（詳細度）を提供することだ。それから、Slimについても話した。これは本当に軽量なモデルだ。これらは連携して機能するのだろうか？ 

ヴァルン：その通りです。私が「アクセス」について言及した際、まさにそのことを指していました。つまり、すべてのSlimモデルも、まったく同じクラウドトランスコーディングのパイプラインを通過するのです。

なぜなら、それらを合成し、コンテキストやコンテンツに基づいてSlimが「合成結果はこうあるべきだ」と判断した時点で、同じトランスコーディングパイプラインを通過し、すべてのコンテンツに対して低画質版、高画質版、Android版、iOS版を生成するからです。

つまり、これは、これは、非常に、非常に相補的な関係にあるんです、えーと、 

Dave: つまりクリエイターにとっては、遠隔地からコンポジットされた非常に複雑なアバターをスリムモデルに変換し、さらにトランスコーディングするという、まさに二重の負担のようなものですね。そのアバターは、繰り返しになりますが、12個の三角形と単色程度のものでも構いません。そして、 

ヴァルン：期待したいこと、あるいは私が予想するのは、ある種の第一段階です。

既存の体験のすべてが、より低スペックのデバイスでも動作し始めるようになるということです。 

Dave: そうですね。 

ヴァルン：でも、本当にエキサイティングなのは二次的な効果ですよね？クリエイターたちは、「ああ、世界にもっと多くのものを盛り込めるんだ」「ああ、追加できるんだ」と気づき始めるでしょう。ええと、考えてみてください 

デイブ：考えてみてよ、えーと、僕が動画を作っているとしたら。カメラの設計はほぼ完成されているようなものだ。

4Kカメラを手に入れれば、どこに向けても、普段通りに動画が撮れるか心配することはない。でも、今のクリエイターにはそんなカメラがない。もしカメラを間違った場所に向けてしまったら、 世界が崩壊してしまうかもしれない、だろ？解像度が高すぎるからさ。例えば、1万人の群衆に向けてカメラを向けたら、まるで……だから、これは没入型3Dカメラの制約を解き放つようなもので、 

ヴァルン：でもクリエイターに自由を与えるわけですね。

そうすれば、プラットフォームの拡大やジャンルの広がりも実現できる。うん、 

デイブ：それに、いつになるかは分からないけど、ムーアの法則的な計算能力の向上、スリム3D、ストリーミングAI、ローカルでのアップサンプリング技術などが組み合わさった時点で、このカメラがもはや制約ではなくなる時が来ると思うんだ。巨大なスタジアムに10万人の人々を配置し、フォトリアルな映像で友達と交流し、ローエンドのデバイスで低遅延のストリーミングを楽しめる、そんな感覚が得られるようになるだろう。

それが、私たちが「没入型40カメラが成熟した」と言う時になると思う。えーと、良いニュースか悪いニュースかは分からないが、やるべきことは山ほどある。だから、私たちの仕事はなかなか面白いものになる。 そして、そのテーマ、つまり究極の3次元・4次元カメラへとどれほどのスピードで進んでいるのかという点についてですが、セルゲイ、Slimの次なる展開は？ これを超えて、次に何を最適化すべきでしょうか？

えっと 

セルゲイ：Slimに関しては、ええと。いくつかの大きなステップが、ええと、目の前にあります。 例えば、その、次のステップは、Slimを完全に動的にして、アバターや移動する車両、動くメカニズム、えーと、そういったものをすべてサポートできるようにすることです。しかし、その後に続くより重要なステップは、バロンが言及したように、Slimを階層化することですね。つまり、Slimが生成するアセットは、えーと、通常のアセットとほぼ同じものになるということです。

それらは全く同じストリーミングパイプラインを通ります。各Slimモデルには固有のロジックや仕様があるため、最適化を行っています。しかし、もしこれをさらに進めて、複数のSlimを一つに結合し、いわば「メガSlim」を作り、それをフラクタル的な方法で繰り返し展開できたらどうでしょうか。

デイブ：これは私たちの設計上の課題の一部だったんだ。というのも、君が最初にSlimを提案した時、私たちはアバターを検討していて、別のプロジェクトも進めていたからね。 100体のアバターをどう組み合わせるか、スタジアムに10万人の人々をどうシミュレートするか、といったことを考えていたんだ。そして本当に印象的だったのは、君がこう言ったあの日だ。「スリム・アバターを使って、全く同じ技術で100体のアバターを1つの集合体としてまとめられるかもしれない」と。

その話が出た時、僕らはちょっと「うわっ、すごい」ってなったよね。あの階層的な性質に？ 

セルゲイ：ええ、その通りです。この例を極端なところまで推し進めると、例えば、仮想カメラで地球全体を見渡せるような状況が想像できるでしょう。地球全体が見え、それはまるでテクスチャが施された球体のようなものです。

カメラが近づくと、個々の大陸が見えてきて、さらに個々の都市が見えてきます。そして、人で溢れかえるスタジアムまでズームインすることも可能です。なぜなら、すべてのシミュレーションはサーバー上で実行されており、クライアント側には、えーと、世界全体に関する詳細な情報は必要ないからです。

明らかに、たとえ高性能なPCを使っても、この惑星全体をデバイスのメモリに収めることは不可能です。しかし、私たちのサーバーは非常に高性能で、この「キー表現」を生成することで、惑星規模からルームスケール、さらにはマイクロワールドに至るまで、あらゆるレベルを表現できるのです。

デイブ：そうですね。僕たちやあなたが身につけている腕時計のレベルまで、あるいはそれ以上にまで縮小できるかもしれません。そこで、サタン、これについて考えてみると、クリエイターたちの活動はどのように変わると思いますか？そう、これで、アバターのパフォーマンスを心配しなくて済むようになるでしょう。

えっと、他にどんな変化が見られると思いますか？ 

ツヴェタン：これは、私の考えでは、彼らが現在抱えているあらゆる制約を取り除くことになるでしょう。あなたが言ったように、彼らは自分が作り出している世界がどれほど複雑かについて考える必要がなくなります。ただ、プレイヤーに対してどのようなゲームのダイナミクスを提示したいか、それだけを考えればよいのです。

それ以外は何もない。残りのすべては、私たちが自動的に処理する。 

デイブ：なるほど、その自動化の部分について詳しく聞けて良かったです。ご存知の通り、従来のRobloxでは「テクスチャアトラス」と呼ばれる手法を使っていました。当時はテクスチャ用のテンプレートがあり、ユーザー自身がそれをどう扱うか考えなければなりませんでした。スリムモデルでは、それが完全に自動化されていると推測します。

えーと、例えば低解像度でのテクスチャ生成とか。 

ツヴェタン：はい。それは自動で行われますし、セルゲイが階層的なダイナミックワールドについて説明した、あの構成要素の決定も同様です。 

デイブ：なるほど。じゃあ、ここからが本当に驚くべき話になるんですが、えーと、物事が単純化されるのは想像しやすいですよね？

まるでアーティストなら、ある種のものを想像するのはとても簡単だ、という感じです。もっと粗くしたり、何かを平坦にしたりするのは簡単ですが、解像度を高めることを想像するのはずっと難しいですよね。 そこで、AIの未来について少し掘り下げてみたいと思います。現在、AIに関しては多くの研究が進められています。例えば、ビデオゲームの生成や、リアルタイムの没入型ストリーミング、ワールドモデルなど、そういった分野です。

ええと、私は、これは単一のモノリシックなものではなく、3つ、4つ、5つ、あるいは6つのモデルが連携して動作するスタックになるだろうと、ますます強く感じています。そこには、例えば4Dでやっているように、私たちが一緒にいる時に、コマンドラインを使って「ワシントン記念塔をゴジラに変えて」と言うだけで、バッとその場で実現するようなものも含まれるでしょう。

えーと、そして最終的には、オブジェクトや世界、あるいはゲーム全体を生成できるようになるでしょう。できればマルチプレイヤー環境での実現を目指しています。そうすれば、私たち4人が一緒に歩き回りながら、「おい、あそこを見て」と指さし、4人で新しいゲームをデザインして、それが魔法のように現れるようなことが実現するはずです。 もう一つ、副次的な側面があります。ええと、あなたが言っていたコマンドプロンプトやワールド生成、3Dに加えて、アップサンプリングという要素があります。例えば、Robloxにある20年前のゲーム『クラシック・クロスロード』を想像してみてください。そこには実は十分な情報があるんです。

もしあのクラシックな『Crossroads』を、セルゲイが言っていたように、フォトリアルな中世風に見せるとしたらどうでしょう。ゲームプレイは同じまま、あの楽しいロケットランチャーのツール類もすべてそのままなのに、突然すべてが新しい見た目になる。では、この文脈ではどう機能するのでしょうか？

えっと、誰かLODについて話したい人はいますか？ というのも、今はLODを下げるのではなく、上げる必要があるからです。 

ヴァルン：その、セルゲイがさっき言っていたポイントの一つだと思うんだけど。将来的にこういうことをできるようにするために、オリジナルの芸術的な意図をできるだけ多く保存しておくってことだよね。で、僕のお気に入りの例なんだけど、これはランダムな例だけど、例えばテクスチャを使っているとしよう。でも、そのテクスチャが実は誰かが撮った写真だったとして、もしその時に使われた絞り値（F値）を保存しておいたらどうだろう。

サイズ、つまりその写真が撮影された時のF値を保存しておいたとしましょう。そうすれば、私の「Uprising」アルゴリズムは、はるかに多くの文脈情報を得られることになります。そうですね。 そのテクスチャがどこで使われているか、例えば城に使われているのか、それとも床に使われているのかを知っていれば、私の「Uprising」アルゴリズムは、それを生成する際にも、そしてハイエンドPCや、まだ発明さえされていない未来のPCに至るまで、その制作者の意図を最後まで維持するという点で、はるかに賢く動作できるようになるのです。

それで 

デイブ：RDCでこれをお見せしましたよね。確か、『Crossroads』がアップサンプリングされる様子を15秒ほどの動画で披露したと思います。えーと、実際に何が起こるのかについて話しましょう。アセットはクラウド上にあり、3Dオブジェクトやテクスチャもそうです。 ええと、コンテンツシステムには追加のプロンプトが送信され、「これらのアセットはすべて、想像しうる限り最もフォトリアリスティックな中世の世界の一部であるべきだ」と指定されます。

すると、それらの様々な要素が、いわゆる「3Dアップサンプリング」あるいは実質的な「3D生成クリエイター」によって、フォトリアリスティックなバージョンにかなり近づけて再生成されるんです。では、例えば城がどうなるかについて、誰か詳しく話してみませんか？ 

セルゲイ：ええと、バロンが今言ったように、あの世界から、もっと多くのセマンティックな情報をキャプチャしているように感じます。

それが極めて重要な点です。例えば、この交差点の例で言えば、城を見てください。個々のアセットという視点で見ると、単にブロックの集合体、つまり箱の集まりに過ぎません。十分な文脈がないと、それらのブロックをより良く見せることはできません。

でも、城ってのは、単なる個々のブロックの集合体以上のものですよね。それらは全体として成り立っているんです。Slimは、こうした文脈の中で動作するから、全体としてその城を理解しているんです。だから、どんなアセンブリでも、個々のアセットではなく、城という全体について、はるかに多くの情報を把握できるようになるんです。

だから、そのアップサンプリングされた城の、もっと、えーと、優れたバージョンを作れるんだ。だって、それは、ただ、それを理解しているからさ 

Dave: つまり、ある意味、あの既存の『Crossroads』の城がなくても想像できるってことですね。ちなみに、『Crossroads』ってのは、すごく古くて、ブロックっぽい見た目のRobloxゲームなんです。

あの城は、実は「城を作って」というプロンプトにとってすごく良い手掛かりになるんだ。あのはかなり自由度の高いプロンプトだからね。ランダムな形のランダムな城が出来上がってしまうような感じだ。でも、クロスロードの城の寸法やサイズってのが、高品質な城にアップサンプリングするための、すごく良いプロンプト情報になるんだ。

セルゲイ：ええ、そうですね。まさにその通りです。というのも、まず、この城の3次元的な部分というのは、ゲームプレイの観点から見て非常に重要になりますよね？だから、ただ適当な城を生成して、それをゲームで機能させるようなことはできないんです。 えっと、その理由はね。でも、もしすべての次元や、すべてのセマンティクス、つまり、そのセットが使用されたあらゆる文脈を捉えることができれば、非常に効率的にアップサンプリングできるんだ。

それに、こうしてもゲームが壊れるようなことはない。というのも、もう一つ非常に重要な点がある。ゲームがプレイ不能になるようなアセットをアップサンプリングしてはいけないからだ。 

デイブ：そうですね、将来的には、3D情報に加えて、3D情報を編集するか、プロンプトを編集するか、そのどちらかができる世界が来ると思います。

両者が組み合わさってその世界を生成するようになるでしょう。先ほど話した5秒の更新、つまり将来のアセット変更は、5秒のプロンプト更新や、プロンプトへのちょっとしたヒントの追加になるかもしれません。そして、オンデマンドでその世界を遅延生成するのです。そして、最後に一つ、AIがどのように組み合わさってこれらをフォトリアリスティックにするかというあらゆる側面を考えると、まだ

そこには、最後のレイヤー、つまり2Dレイヤーがあります。ゲーム用PCでは何が起きているのでしょうか？あるいは、さらに高解像度アップサンプリングが行われる可能性のあるクラウド上のビデオ処理装置では何が起きているのでしょうか？例えば、私の頭の完璧な髪の毛。その髪の毛を処理するのに最適な場所は、2Dアップサンプリングツールを使ったローカル環境かもしれません。あなたは3Dで髪の毛を表現しようとする多くのゲームに携わってきたと聞いています。

あなたの見解としては、いつの日かすべての髪の毛の表現は2Dアップサンプリングで行われるようになると思いますか？それとも3Dの髪の毛になるでしょうか？ 

セルゲイ：ええ、その通りです。私たちはその方向に向かっていると思います。なぜなら、スクリーン空間でしかできない処理もあるし、そちらの方が効率的だからです。こう言いましょうか、スクリーン空間で行う方が効率的なんです。

例えば、こう、えーと、髪、レンダリングとか、そうでしょう？ だから、あるいは。今の多くのゲームエンジンは、MLベースのアップサンプリングをやっていて、例えば1080pから4Kへとアップスケールしている。でも、それ以上のこともできるでしょう？ シェーディングを変えたり、見た目を変えたりできる。

この例を極端に言えば、ゲームエンジンが単に、MLアルゴリズム用のセマンティック情報のようなものをレンダリングするだけで、そのMLアルゴリズムが、見た目の良い髪や、見た目の良いマテリアルを生成してくれる、といった感じですね。スクリーンスペースにおけるディレクティブのように。

デイブ：すごくいいですね。えーと、では、そろそろまとめに入りますが、C++のプログラマーやアセンブリ言語のプログラマーの皆さんに向けて。えーと、私もそうだったらいいのにと思うんですが、あれは世界で最も楽しいことの一つですよね。私たちはここで非常に難しいことをやっているんですよね？ これらすべての技術をあらゆるデバイスで動作させようとしているわけですから。

トランスコーディングに関する質問です。多くのPCには、処理を高速化するためのSIMDレジスタなどの最適化機能が搭載されていると承知しています。私たちのトランスコーダーでも、すでにSIMDの活用を検討し始めているのでしょうか、それとも将来の最適化として残されているのでしょうか？ 

ツヴェタン：ええと、まず最初に、ちなみに、トランスコーディングは現在、エンジン上でも実行可能です。

なるほど。素晴らしいですね。では、現在CMDの最適化を活用していますが、さらに先を見据えてGPUやその他の... 

デイブ：つまりトランスコードか。なるほど。GPUでのトランスコードは今後実現する可能性があるということですね。 

ツヴェタン：ええ、そうですね、検討中です。 

デイブ：なるほど。それはすごく、すごく楽しみですね。さて、えーと、皆さん、素晴らしいアップデートでした。えーと、視覚的な資料をご希望の方には、おそらくRDCのメインステージでのプレゼンテーションで。

そうすべきだと思います。今回の内容の多くはビジュアル資料も用意していました。話し合ったことはすべて、現在進行中です。慎重に見守っていますが、皆さん、そして皆さんの背後にいる様々なチームが、私が時々「ゲームエンジン2.0」と呼んでいるもの、つまりクラウドを多用したシステムに、本当に貢献してくれていると心から思っています。

この技術全体において、トランスコーダーが強力に支えています。皆さん、ありがとうございました。今日は皆さんを驚かせたと思います。本当に感謝しています。 

ツヴェタン：ありがとう。 

デイブ：では、こんにちは、デイブです。えーと、今回もテックトークでした。次回もお会いできるのを楽しみにしています。チーム一同、ありがとうございました。ありがとう。