完整文字稿

戴夫：大家好，我是戴夫·巴祖基（Dave Baszucki），Roblox 的創辦人兼執行長，您正在收聽或觀看「科技對談」。今天我們將探討第二代遊戲引擎的組成要素、其如何整合雲端技術，以及我們如何協助使用者以高解析度即時加入遊戲。我們這裡匯聚了 Roblox 的技術夢幻團隊。

我們有瓦倫·馬尼（Varun Mani）、謝爾蓋·馬基耶夫（Sergey Makeev）以及茨維坦·茨維塔諾夫（Tsvetan Tsvetanov），接下來我們將深入探討所有與串流相關的技術。嗯，我們會談論 SLIM，也會談論資產轉碼，以及所有讓 Roblox 最終能支援十萬名玩家的技術。如果我們回顧過去 10 到 20 年的遊戲產業。

所有這些 3D 內容呈現給玩家的方式都遵循某種傳統模式，而這種傳統模式存在一些問題。因為我們在 Roblox 試圖實現的是「即時加入」。 呃，我們試圖讓相同的體驗既能在手機上運行，也能在大型電腦上運行，呃，我們試圖做到這一點而不產生任何延遲，而當我們觀察傳統遊戲的運作方式時，情況並不完全一樣，對吧？

就像我記得，呃，在我那個年代，遊戲是透過所謂的軟碟來分發的。但即使到了今天，對吧，我們還是透過大型DVD來分發遊戲。我這麼說沒錯吧？ 

瓦倫：是的。而且我認為關鍵在於，所有內容都是打包在一起的。對吧？所以無論是 DVD，還是現在下載遊戲，它都是一個巨大的封裝，你無法將其拆分。

所以你必須等到整整 4.7 GB，或者某些情況下甚至 10 GB 的內容完全下載完畢，才能開始遊玩。 

Sergey：沒錯。就像 Varun 說的，有些遊戲可能要 20、40 GB 左右，你得等上好久才能開始玩。這簡直是，你知道的，完全破壞了那種沉浸感，對吧？

因為，比如說你想玩遊戲，下班後可能只有一兩小時空檔，想玩個遊戲，結果卻得等上30、40分鐘，等它更新之類的。基本上，這就跟我的實際體驗差不多，就像是 

戴夫：這不就跟我們在影音和電影領域看到的狀況很像嗎？

我還記得以前電影是透過 DVD 發行的時期，也記得 BitTorrent 的時代。那時候你得先下載整部片，直到後來我們才發展到現在這種模式：我只要上亞馬遜、Netflix、Hulu 或 Tubi，就能立刻觀看。但我覺得遊戲市場還沒有完全達到這種程度。

還沒。還沒。我認為還沒。 

茨維坦：我們是唯一一家以此為目標的 

戴夫：這個方向。所以，從歷史上看，Roblox 一直都是這樣運作的，雖然這在幕後運作。大多數人可能沒有注意到，但當你進入 Roblox 的首頁並點擊「播放」時，你就能立即加入。這其實非常非傳統，因為當我在一些非常精緻的遊戲平台上，我甚至見過必須下載高達 200 吉字節的檔案才能開始遊玩。

所以，我們已經實現了這種即時遊玩？是的。 

Tsvetan：呃，據我所知，Roblox 是唯一一個允許這種即時加入並遊玩的平台。哦對了， 

瓦倫：對，抱歉。還有，就像你剛才提到影片串流那部分，對吧？比如說當你在進行影片串流時，其實是在做什麼？我不想下載整部電影，只是下載眼前正在播放的那部分，我們稱之為緩衝。

我是在串流這部電影，對吧？沒錯，但那只是單一維度的運作，因為那裡只有時間維度。是的，這就是關鍵差異。這也是在 Roblox 中實現此功能之所以困難的原因，因為它是一個完全互動的 3D 世界，你必須同時串流場景和資產，而這些正是 Roblox 中一切事物的基本構成單元 

戴夫：Roblox A A，呃，我認為這讓事情變得更加困難，因為在傳統的電玩市場中。

我通常會看到不同版本的遊戲，像是高階電腦版和低階手機版。而我對此的解讀是，在高階電腦上，我可以下載數百GB的資料，因此會有這些非常龐大且複雜的資產；而在手機上，我認為創作者幾乎會製作一個獨立的版本 

Sergey：在某種程度上。

嗯，是的。這，這，這點說得很好，因為在傳統遊戲中，你知道，他們有個叫做「資源預處理」的流程。所以他們會針對每個平台，準備一個高度優化的版本。如果你從更廣義的視頻串流角度來思考，這就像 DVD 一樣。

呃，影片只編碼過一次，對吧？沒錯。不過在任何串流平台上，同一段影片都會有多種編碼版本，這樣就能自動適應你的裝置。而且，呃，現在所有遊戲都會預先處理他們的資產，並針對特定平台提供非常精確的版本。

因此我們能在雲端針對每個平台生成單一資產的優化版本。沒錯。 

戴夫：先別急著說下去，對吧？因為不久前我們曾有過這樣的願景：如果你是一位年輕創作者，製作出的體驗內容，應該能在任何語言環境下運行。我們設想它能在任何裝置上運行，並在各種裝置上以不同解析度呈現。

我們接下來會深入探討這個。所以，傳統遊戲市場，你知道的，要麼是實體包，要麼是下載版。嗯，我們想解決這些問題：讓任何裝置都能即時存取、低延遲，並將這些優勢結合起來。因此，今天我們要討論的，就是所謂的 3D 和 40 串流。

我們將探討雲端內容，並介紹名為「Slim」的技術——相信這會讓大家非常興奮。那麼，或許我們可以先由 Varun 來簡要說明「Slim」的概念，以及我們所說的「雲端轉碼」究竟是什麼意思。 

Varun：所以，如果我們退一步思考，我們的整體願景是試圖佔據遊戲市場的10%。

沒錯。我們實現這個目標的方式，是賦予創作者完全的創作自由。嗯，若思考我們的成長策略，大致可分為兩個面向：一是平台擴展，二是遊戲類型擴展。所謂平台擴展，就是如何讓相同內容能在任何平台上運作？

也就是說，只需創作一次，Roblox 就能確保它在任何地方都能運行。至於類型擴展，我們希望你們能創造出越來越令人驚嘆、越來越瘋狂的作品。 

戴夫：當你說「隨處運行」時，字面意義上，就是想像一些真正龐大、瘋狂又好玩的作品。像是《俠盜獵車手》、《荒野大鏢客：救贖》這類高階主機遊戲。

卻能在 2GB 記憶體的 Android 手機上運行，以及介於兩者之間的所有裝置。沒錯。 

瓦倫：從 PC 一直到 2GB 的 Android 裝置，都應該能直接運作，無需創作者額外費心。這就是我們的願景。沒錯。雲端、轉碼和 Slim 只是我們朝這個方向邁出的最初兩步。

戴夫：好，這算是個小預告。我們接下來會說明什麼是 Slim，我想你大概也會解釋什麼是轉碼，但先讓我們先向大家做個自我介紹。那麼，謝爾蓋，嗯，你回來了，能分享一下你在引擎優化方面的背景嗎？這可是世界上最有趣的事情之一，對吧？

像是 C++、匯編語言，還有 C/D 之類的，你能分享一下你最近在做什麼嗎？ 

Sergey：嗯，是的，就像你之前提到的，我這輩子幾乎都在做遊戲相關的工作，一直都在進行各種優化，從早期的 Xbox 平台開始就是如此。

呃，還有。你知道的，當我第一次接觸 Roblox 時，我簡直被震撼到了，就像這個概念一樣，呃，一款遊戲只需製作一次，或者說，不單單是遊戲。就像任何體驗，只要製作一次，然後就能在任何地方運行，在任何平台、任何裝置上，而且不需要任何額外的使用者輸入。

這正是極具挑戰性的工程難題。 呃，就像，呃，大家都能想像的那樣，對吧？所以，呃，這需要很多，呃，你知道的，像傳統的優化，像是 CMD、多執行緒處理，還有非常謹慎的 GPU 調度，所有這些。但同時，你知道的，像是在單一裝置上，我們能擴展的規模是有一定限制的。

所幸我們還有雲端，對吧？ 所以，我們可以將部分工作上傳到雲端，協助這些裝置更高效地渲染更大的牆面。在某種程度上，當我們渲染的牆面甚至無法完全裝進實體裝置的記憶體時，因為這些牆面也存在於伺服器端，而伺服器會協助所有客戶端高效地渲染它們。

戴夫：沒錯。所以，重點是，我想我們接下來要分享的線索之一是：傳統遊戲引擎通常是用 C++ 編寫的，而且你得下載所有資源。但假設你想玩的遊戲是整個世界，例如，沒有人能把整個世界放進一張 DVD 裡。

所以你真正想表達的，我們在 Google 地圖和其他類似服務中已經看到了。 根本不可能，呃，把所有內容都放在同一個地方。所以當我們談論串流時，其中一部分內容就是將同樣的概念應用於遊戲，然後是 Enton。你能稍微說明一下，是什麼原因讓你加入 Roblox 的？你的背景是怎樣的？或許還能稍微透露一下什麼是雲端轉碼。

所以， 

Tsvetan：呃，在加入 Roblox 之前，我的職業經歷主要集中在兩個領域。一個是建築、營造和機械工程領域的 3D 設計與模擬軟體；另一個則是大規模分散式運算。我能夠將這兩方面的知識應用到 Roblox 中，因為 Roblox 的本質基本上就是這樣。

戴夫：沒錯。我們來談談 Roblox 上的串流技術吧。關於這點，嗯，我們都知道什麼是視訊串流。視訊串流是一種線性的過程，對吧？我只需要一個畫面，接著一個接一個地傳送。你能分享一下，在 3D 環境中，即時串流究竟意味著什麼嗎？ 

瓦倫：如果你仔細觀察，嗯，現在 Roblox 遊戲中的幾乎所有內容，都是由實例或資產組成的，對吧？

實體，也就是世界結構的組成部分。而資產則是驅動該實體、提供實際內容的元素。嗯，若以串流來思考，它涉及實體的串流，同時也包含這些資產的串流。這是必須要做的。所以，如果是在視訊串流中，你只有一個資產，那就是影片本身。

但在 Roblox 中，我們要重複執行這個過程數千次、上萬次，反覆不休。所以當你提到即時串流時，其實是在嘗試串流足夠多的周邊世界內容，但你無法預知玩家會怎麼做。玩家可能會往這邊走，也可能往那邊走。你需要串流或緩衝恰到好處的世界內容。

而在你緩衝的這個世界中，你需要以精確的品質來緩衝這些資產。正如謝爾蓋所提到的，影片有不同的品質等級。網格模型也是如此，圖片亦是如此。 

戴夫：那麼，如果我們將其拆解開來，是否可以說「實例」是我們可能熟悉的概念？

例如一輛車、一棵樹、另一個角色、一座山丘，諸如此類。而所謂的「資產」，則是構成這些實體的技術元素，也就是那些 3D 物件的內部組成。當我們在遊戲中時，我們面對的是一大堆三角形，一大堆紋理，因此我們討論的是要從中挑選哪些來

在任何時刻真正載入。 

瓦倫：沒錯。還有該採用哪種呈現形式。所以當你行走、穿梭於這個世界時，就像是你的裝置在說：「好，我想要那棵樹，或者我需要那棵樹。」那棵樹是由許多網格和許多紋理組成的，未來甚至可能包含動畫、音效等等。

於是它便開始決策。好。根據那棵樹的位置、其重要性，以及它佔據了多少螢幕空間。我想要高畫質的貼圖。我想要中畫質的網格。至於音效，也許我現在還不需要，所以先別載入音效。所以它一直在進行這些決策， 

戴夫：所以，某種程度上，這有點像我使用地圖繪製軟體時，我只導入一小部分圖像，也就是地圖的一小塊區域。

我們談的是這些元素的 3D 版本，還有互動式 3D 元件。好。而且，幕後還有一個非常關鍵的要素。我認為，我們的願景始終是：無論你使用什麼裝置，我們都試圖盡快載入正確的內容。

而且，我們有時會說，我們希望盡快載入這些內容，以最大化人類對「魔法」的感知。就像你會驚嘆：「哇，這個世界就這樣出現在我眼前。」所以，Sergey，我們該如何挑選，以及如何篩選該載入什麼、該導入什麼？ 

Sergey：是的。嗯，優化，像是，呃，針對感知上的延遲。

這點非常重要，因為就像瓦倫剛才提到的，你知道的。我們會不斷測量螢幕空間的範圍，以及物件的重要性。舉例來說，如果你在非常近的距離看到一棵樹，或者在非常遠的距離看到完全一樣的樹，這兩者感覺上可能就像是兩棵不同的樹，對吧？

所以如果你從遠處看，其實不太會在意細緻的紋理細節之類的。因此我們可以，我們總是能為那棵樹使用低解析度的紋理。 呃，你將無法分辨，你知道的，像是低解析度還是高解析度的結構，因為它，它只是在螢幕上看起來非常小。

但另一方面，我們幾乎可以立即載入，因為這樣傳輸的資料量更少。不過當你靠近那些樹木時，我們會逐步載入越來越多的資料，畫面也會變得更細緻。所以你不會察覺到過渡，也無法分辨差異，但你會立刻、立刻就能看到並與之互動。

戴夫：而且，這其中一部分原因在於，當我使用我的兩GB Android手機或遊戲電腦時，想要立即加入某個內容。即使網路速度非常快，我們並沒有足夠的頻寬。就像我們試圖將整個世界塞進那條管道裡，無論你擁有每秒10兆位元還是100兆位元，都必須平衡我們透過管道傳輸的內容。

而且，我有時會這樣想：一棵離我很近的樹，它所包含的資訊量可能等同於一百棵遠處的樹；但那些遠處的樹在視覺上的重要性，可能與近處的那棵樹相當，所以我們會以不同的解析度來呈現它們。

就像那棵離我很近的樹，它的畫質遠比那些遠處的樹更高。 

Sergey：是的，嗯，這完全正確。呃，還有，呃，你剛才提到的重點是，我們不僅在衡量物件的重要性，還得考量我們有多少電腦資源？

像是我們有多少記憶體？像是網路頻寬，還有所有這些因素。所以我們會將所有影響使用者體驗的因素都納入考量，這也包括效能。你知道的，像是我們有多少記憶體，還有所有這些。 

戴夫：所以，我們之前談過，實例就像樹，而資產則是網格或貼圖。

你能再多分享一下它們的差異，以及在幕後我們實際上是如何處理資產串流的嗎？好。 

茨維坦：是的。嗯，舉例來說，在伺服器端進行串流時，什麼是重要的？沒錯。根據，呃，重要性，G 會提供這項資訊，並將資訊推送給每個客戶端，而每個客戶端實際上會根據情況，獲得不同的，呃，實例。

它是否可見？是否不可見？是否參與互動區域？關於資產串流，其實是客戶端負責將世界中的內容串流進來。嗯，正如 Sergey 所說，根據我們設定的品質目標，以及裝置的效能，我們只針對那些符合品質標準且裝置能處理的精確表現形式進行串流。

基本上就是這樣運作的。呃，所以 

戴夫：希望那些遠處的樹木能非常精簡，對吧？也就是較低解析度，不佔用太多資源。這樣我們就能把更多時間和運算資源花在離我較近的樹木上。因此我們有這個稱為「內容管道」或「資產管道」的機制。

你能稍微分享一下嗎？假設我是個遊戲創作者，這個轉碼管道是怎麼運作的？比如我使用 Roblox Studio 製作了一輛很棒的車。背後會發生什麼 

Tsvetan： 

戴夫：場景背後會發生什麼？ 

Tsvetan：由於引擎的改進，我們也希望保留設計師和遊戲開發者的藝術意圖。

因此我們提出了雲端轉碼的概念，這讓我們能夠，呃，從創作者那裡導入內容並儲存起來。根據開發設備，呃，以及客戶端所需的裝置和功能來進行優化。而且，呃，這個流程是端到端的，採用按需延遲處理。 這意味著，只有當客戶端請求特定格式時，如果我們沒有該格式，才會啟動運算。

若資源已存在，則直接返回。因此，我們在提供給客戶端的頻寬與運算資源方面，能達到極佳的優化效果。所以 

戴夫：如果我，呃，還有我們，在很久以前我們還沒有這個功能的時候，或者說其實是最近，我們不得不對這些資產的保真度設限。

比如，我想我們會說你的車只能有這麼多三角形，三角形越多，車看起來就越精確。或者我們會說紋理的大小只能有這麼多像素。而我們現在所說的，我認為是你可以上傳那輛車，無論你是怎麼建模的，然後當你說在後台進行轉碼時。

我們會將那輛車生成各種版本，且使用的三角形數量越來越少。 

Tsvetan：是的，沒錯。或者說，未來甚至會增加。沒錯。而且，我們現在具備這項能力，可以根據引擎的改進以及我們擁有的運算能力，來優化三角形數量、紋理貼圖、音訊、影片、動畫等各種元素的呈現效果，無論我們需要什麼都能做到。

所以， 

戴夫：所以這是按需生成的，我想這跟你之前提到的「烘焙」概念有關，謝爾蓋。以前有種叫做「烘焙」的技術，像是會預先烘焙高解析度的模型。而我們現在基本上是在進行「按需烘焙」。那輛車有許多不同解析度的版本，全都儲存在那裡。然後我遠處看到的車，可能就是其中一個低解析度的版本。

這應該就是我們所說的轉碼吧。沒錯。那麼轉碼是怎麼運作的？比如說，你們是如何將一百萬個三角形轉化為一千個三角形的？我是說這個，呃。 

茨維坦：呃，資料導入。沒錯。所以我們在工作室，呃，實際上會導入那個，呃，一百萬個三角形的網格。接著我們將它儲存到，呃，我們的後端，呃，內容平台，呃，後端，呃，系統中。

接著，呃，在收到請求時，我們會執行所謂的 LOD 處理， 

戴夫：也就是所謂的「細節等級」（LOD）。細節等級的意思是 

茨維坦：取決於情況，我們會盡可能在有限的網格或貼圖呈現中保留最高品質。 

戴夫：所以，呃，瓦倫，如果我們思考這在不同裝置間是如何運作的，你是，呃，你是創作者。

你上傳了一輛巨大的高解析度汽車。我用的是低階 Android 裝置，你用的是高階 PC 遊戲裝置。希望我們還是能玩同一個遊戲。沒錯。像，我們兩邊會發生什麼情況？而且， 

瓦倫：所以，基本上是這樣的，當我的客戶端連線時，它會說：「嘿，我是低階 Android 裝置。我需要這個特定的版本」，因為有一點我們其實還沒提到，這不僅關乎細節等級，也涉及平台專屬的呈現方式。

所以 Android、iOS，這些不同的平台都有非常特定的呈現方式，你可以壓縮紋理，甚至可以調整它們，讓它們運作得更為優化。所以我的 Android 裝置連線時會說：「嘿，我要那棵樹的 Android 版本低階紋理。」然後雲端轉錄系統就會去為我生成那個版本，並將其快取，這樣下一台連線的 Android 裝置

就無需重新生成，直接傳送我製作的版本即可。當你的電腦連線時，它會說：「嘿，我擁有全世界的資源，給我高品質版本，給我未壓縮版本，我只想追求最高保真度。」接著系統會將其快取，這意味著這套系統具備無限的未來兼容性。

戴夫：而且也具備無限的即時性。我超愛《俠盜獵車手》，他們即將推出一個令人驚嘆的新版本，我對此非常期待。假設我是一位想調整資產的藝術家。在我們——希望是未來的系統中，我只需大約五秒就能重新上傳。

你和我遊玩時，系統就會觸發對該資產的重新轉碼。 而且字面意義上，你知道，在峰值同時在線量下，比如像《Grow a Garden》那樣有 2500 萬人的遊戲，你可以在 5 到 10 秒內讓所有這些新玩家，可能獲得那個新資產。這就是為什麼我認為這在某種程度上代表了未來，因為我認為《俠盜獵車手》的魅力之一在於，他們在遊戲中融入了如此高的品質。

他們要把內容燒錄到巨型DVD上，必須確保完美無瑕，且無法進行迭代修正。你必須在當下就做到絕對完美。所以，關於未來適應性，除了即時變更之外，保存藝術創作意圖——也就是保存原始藝術作品——似乎也頗有其價值。

某種程度上，你能說明這對我們有什麼幫助嗎？呃， 

Sergey：是的。因為我們試圖盡可能多地捕捉原始的藝術內容，所以我們儲存的是——對，就是原始版本。所有資產的原始版本。而且，正如你能想像的，我們可以。

不僅能透過生成更簡化的紋理版本來進行降采樣，未來還能進行升采樣，因為我們已經捕捉到了原始意圖的語義，所以日後可以將這項資產放大。而且，無需任何使用者介入。

我們就能讓它看起來更棒。 

戴夫：這點，這將是我們邁向未來時的一個重要線索。嗯，所以讓我們，嗯，讓我們在我們一直在討論的內容中加入第二個組成部分。所以我們正在進行串流。進行即時修正。雲端轉碼，傳遞任何 LOD。然後，就像我們一開始提到的，我們將用一個叫做 Slim 的東西來補充這一點。

所以 Slim 不是健身計畫。它不像 Roblox，也不是那種——希望能夠讓我們大家都感覺很好、思緒清晰——的 Roblox 小點心，呃，在 Roblox 引擎的語境下，Slim 究竟是什麼呢？ 

Sergey：是的。呃，所以。呃，讓我退一步，像，呃，再拿這個，呃，樹的例子來說明，對吧？

所以我們有，呃，你有一棵樹，就像我說的，比如說你可能有許多棵樹，呃，在遠處，呃，Slim 就是將所有這些個別的樹，呃，轉化為森林並進行優化，不再是個別處理，而是將它們視為一個更大的整體來優化，這就像是彙總，呃，彙總了個別的樹木，呃。

這就是 Slim 技術。它總是會根據特定情境來優化這些資產。假設你有一棟建築物，對吧？ 而且，這棟建築裡還有許多，呃。呃，房間。就像如果你在建築物外面，你不會在意建築物裡的房間。所以，Slim 能感知到這個情境，呃，它能非常高效地移除所有建築內部結構，就像在這種情況下，並進行優化，為你生成該資產的極佳版本。

戴夫：所以，在你們設計這個過程中，我有幾個用例一直在思考。其中一個用例是，人們正在打造越來越複雜的虛擬角色。過去在 Roblox 上，我們一直很謹慎地控制：你能穿幾層衣服？能戴多少飾品？能攜帶多少物品？

但未來虛擬角色可能擁有上百件物品。我認為我們的創作者在效能方面非常精明，他們可能會刻意降低虛擬角色的細節精細度，因為他們非常重視效能表現。複雜的虛擬角色是第一點。第二點，正如你提到的，那邊可能有上百棵樹，它們遠在天邊，而且沒有人會與它們互動。

然後，第三種可能是帶有內部房間的建築。嗯，我想我們接下來要嘗試做的是，無論是動態虛擬角色、一大片樹林還是建築，這個完全相同的系統基本上會將所有元素合成到單一物件、單一網格、單一貼圖中，這簡直令人難以置信。

呃， 

Sergey：是的，你說得完全正確。所以，這用詞很貼切。就像這個系統會動態生成一種合成視圖，呈現多個資產的組合，並動態決定這個合成的邊界、細節層級，它總是運作在這個世界情境中。

所以這就像在兩種不同的使用情境中，可能會根據目標裝置或使用情境的不同而採取不同的優化方式。呃，我們也支援該內容的動態更新。所以這並非總是靜態的優化。

如果某些內容隨時間變化，這將會反映在精簡的表現形式中，因為我們可以動態地更新它。 

戴夫：這，這幾乎，我之所以非常喜歡這點，是因為它讓我感覺彷彿自己就是一位 Roblox 開發者。而且我真的很想要大規模的應用，例如，非常複雜的虛擬角色。

這或許只是我的夢想，比如說，我能走到身邊的人面前。他們可以摘下帽子，戴上新的飾品——這就是系統處理近距離物件的方式，可能以標準的高保真度運作。然後當那個虛擬角色逐漸遠離時，它會被合成簡化為單一物件。

隨著距離拉遠，透過 LOD（細節等級）進行調整。嗯，我們常開玩笑說，最極端的狀況是遠處的虛擬角色可能只有 12 個三角面，搭配一張非常小的貼圖。這幾乎就是我認為開發者夢寐以求的景象。而且我認為這將使……嗯，這將使更龐大的世界成為可能。

橫跨各種裝置。 

Varun：完全正確。我的意思是，Slim 本質上為我們開闢了擴展性的新維度。我們之前談了很多關於不同細節層級的雲端轉碼。現在我們在此新增了另一層維度，也就是關於合成（composition）的部分。對吧？你可以想像一個 2x2 的矩陣，矩陣上的任何點都能提供有效的體驗。

沒錯。所以你可以選擇高畫質、低合成度，也可以選擇高畫質、高合成度——無論你是在低階裝置上，還是使用其他裝置。所有這些點都成立。因此，若談論一個龐大的世界，整個世界可能僅由 12 個三角形構成。此外，若你距離足夠遠，或者這無關緊要，那就沒問題。

戴夫：那麼，接著思考使用者體驗，以及 Slim 如何能帶來更好的使用者體驗。若談到 LOD，我們會想到雲端轉碼；若談到 Slim，我們會想到串流技術——相較於當今的 Roblox，或是一年前的 Roblox，這會如何影響使用者體驗？ 

茨維坦：是的，關於 Slim，呃，我們開發 Slim 的初衷是，呃，讓開發者能夠打造更豐富、更大且更複雜的世界，這些世界將，呃。

呃，與終端使用者互動並產生行為。西門子？呃，是的，非常輕鬆。就像不需要，呃，而終端使用者，呃，其使用體驗完全就像擁有，呃，最強大的機器一樣。而且，呃，Slim 是一個，呃，目前支援，呃，靜態模型的系統。而我們，呃，你知道的。 未來將支援分層生成的虛擬化身與動態模型， 

戴夫：這對終端使用者來說，可能意味著在低階裝置上也能體驗更豐富的世界。

比如在我的低階手機上，也能和你用你的遊戲電腦一起玩。創作者可以製作更高品質的內容，不用擔心虛擬角色身上穿了幾層衣服。更複雜的車輛，還有那些精密的機械物件，都會透過 SLIM 進行壓縮，這真的會非常、非常酷。

然後。嗯，或許該思考它們如何協同運作。我們談過雲端轉碼，也就是提供較低的 LOD（細節等級）。接著我們談到 Slim，這是一種非常輕量化的模型。它們能協同運作嗎？ 

瓦倫：完全正確。這正是我所謂的「存取」概念。所有 Slim 模型也會經過完全相同的雲端轉碼管道。

因為一旦將它們組合起來，且一旦根據情境和內容決定了 Slim 該如何運作，這便是組合後的最終形式。它會經過相同的轉碼管道，然後為所有內容生成低畫質版本、高畫質版本、Android 版本以及 iOS 版本。

所以這，這，這在兩者之間， 

Dave：所以這對創作者來說，幾乎就像是雙重打擊，非常複雜的虛擬角色遠端合成到精簡模型中，然後再進行轉碼。那個虛擬角色，說不定只有12個三角形，而且只有單一顏色。而且， 

瓦倫：你希望看到，或者我預期會看到的是某種第一階段的成果。

所有現有的體驗都能開始在越來越低階的裝置上運行。 

戴夫：沒錯。 

瓦倫：但真正令人興奮的是二階效應，對吧？創作者開始意識到，噢，我可以在這個世界裡加入更多東西。噢，我可以添加。嗯，試想 

戴夫：想想看，嗯，如果我在製作影片。這幾乎就像相機已經經過相當完善的設計。

你知道的，我拿著我的 4K 攝影機，完全不用擔心，無論我把鏡頭對準哪裡，都能像平常那樣拍出影片。但今天的創作者並沒有那樣的攝影機。比如說，如果他們把鏡頭對錯了方向。 整個畫面可能會失控，對吧？就像解析度太高一樣，比如說如果他們把鏡頭對準一萬人的群眾，那簡直是……所以這幾乎就像是釋放了沉浸式 3D 攝影機的潛力， 

瓦倫：同時也賦予創作者自由。

所以我們可以先拓展平台，再拓展類型。沒錯， 

戴夫：而且，我確實認為會有那麼一天——雖然我們還不知道何時——那將是摩爾定律的運算能力、Slim 3D、串流 AI、本地技術上採樣等各種技術的混合體。屆時這台相機可能不再是限制，如果你想在巨型體育場裡呈現十萬人，以照片級真實感與朋友們互動，並在低階裝置上以低延遲串流，那感覺會很棒。

我認為，當我們說這套沉浸式 40 鏡頭系統已臻成熟時，好消息或壞消息在於還有大量工作要做。這讓我們的職務變得頗具挑戰性。 而我，我想，在這個關於我們正以多快速度邁向終極三維與四維相機的主題下，嗯，Sergei，Slim 的下一步是什麼？接下來我們該針對什麼進行優化？

所以 

Sergey：關於 Slim，嗯……我們面前還有幾個大步驟。 比如，接下來的第一步是讓 Slim 完全動態化，以支援虛擬角色、移動車輛、動態機械結構等等。但之後更重要的一步，就像巴倫提到的，是讓 Slim 具備層級結構，因為 Slim 生成的資產基本上與一般資產完全相同。

它們會經過完全相同的串流處理流程。我們會針對它們進行優化，因為每個 Slim 模型都有各自的結構等特性。但如果我們能更進一步呢？如果我們能將多個 Slim 結合成一個，就像一個「超級 Slim」，然後像這樣以分形的方式不斷組合呢？

戴夫：這正是我們設計時思考的問題。因為當你最初提出 Slim 時，我們當時正在研究虛擬角色，而且還有一個獨立的專案。 我們在思考該如何將一百個虛擬角色組合在一起，以及該如何模擬體育場裡的一萬人？有天發生了一件非常有趣的事，記得是你說：「你知道嗎，我們或許能利用『Slim』虛擬角色，用完全相同的技术，將一百個角色組合成一個由一百個虛擬角色組成的集合體。」

就是那個時候，我們才恍然大悟。那種分層結構的特性，真的讓人大開眼界，對吧？ 

Sergey：嗯，是的，嗯，完全正確。如果把這個例子推向極致，你可以想像這樣：好，我們的虛擬攝影機可以俯瞰整個星球。所以我們看到整個星球，它就像一個球體，帶有紋理。

當鏡頭拉近時，你會看到各大洲，接著是各個城市，最後甚至能直視到擠滿人群的體育場——因為所有模擬運算都在伺服器端執行，客戶端根本不需要知道……呃……關於整個世界的事。

很明顯，你知道，你無法將整個星球塞進裝置的記憶體裡，即使是在一台強大的電腦上也是如此。但我們的伺服器非常強大，透過生成這種精簡的關鍵表示形式，我們可以從行星級別一路縮放至房間級別，甚至微型世界。

戴夫：嗯，沒錯。我們甚至可以細化到你或我手腕上戴的手錶，觀察錶上的小鈕扣，甚至比這更細微。那麼，當我們思考這點時，撒旦，你覺得這會如何改變創作者的創作方式呢？對吧。我們將——希望能夠擺脫那種「天啊，我得擔心虛擬角色的效能」的煩惱。

嗯，你覺得我們還會看到什麼其他變化嗎？ 

茨維坦：這將消除——嗯，依我之見，會消除他們目前面臨的所有限制。正如你所說，他們不必再去思考，呃，他們所創造的世界有多複雜。他們只需要思考，想向玩家呈現什麼樣的遊戲動態。

除此之外別無他事。其餘一切都將由我們自動處理。 

戴夫：所以，能深入探討這些自動化功能真是太好了。你知道，在舊版的傳統 Roblox 中，我們有個叫做「紋理圖集」的功能。我們其實提供了一個紋理模板，而你必須自己想辦法處理。我假設在 Slim 模型中，這一切都是完全自動化的。

嗯，像是以較低解析度生成那張貼圖之類的。 

茨維坦：是的。這會是自動的，同時也會自動決定那些……嗯，謝爾蓋在分層動態世界中解釋過的「建構塊」。 

戴夫：好，那麼現在，嗯，現在我們真的要大開眼界了，我們要來談談……嗯，想像某樣東西變得更簡單，這很容易吧？

這幾乎就像是，如果你是一位藝術家，很容易想像某種……讓它變得更粗糙、將某物扁平化，但要想像某物獲得更高解析度，就難得多。 所以我想要，我想稍微探討一下，呃，AI 的未來，目前在 AI 領域有許多研究，像是我們將如何生成電玩遊戲、即時沉浸式串流、世界模型等等。

嗯，而且我越來越覺得，我們會發現這並非單一的系統。這將是一疊由 3、4、5 或 6 個模型協同運作的架構，其中包含一個命令列介面——當我們聚在一起時，就像我們使用 4D 那樣，我們只需說：「把華盛頓紀念碑變成哥吉拉」，咻的一聲，它就會立刻變出來。

嗯，而且，最終還能生成物件、世界，甚至是完整的遊戲。嗯，希望是在多人連線的環境下。所以我們四個人一起走來走去，然後說：「嘿，看那邊，我們四個人想設計一款新遊戲，讓它神奇地出現。」 還有一個次要面向。嗯，除了你提到的命令提示字元、世界生成和 3D 之外，還有「上採樣」這部分。呃，如果我想像一下經典的《Crossroads》——這是 Roblox 上一款已有 20 年歷史的遊戲——其實那裡已經有足夠的資訊了。

如果我們拿經典的《Crossroads》來做，Sergey，你說過，把它做成這樣。就像一個寫實風格的中世紀版本，遊戲玩法可以保持不變。你知道的，所有那些有趣的小火箭發射器工具都一樣，但突然間一切都有了嶄新的面貌。那麼在這個情境下，這該如何實現呢？

我，我不知道誰想先談談 LOD，因為現在 LOD 必須提升而不是被捨棄。 

瓦倫：我認為這跟謝爾蓋之前提到的其中一點有關，對吧？重點在於盡可能保留原始的藝術意圖，這樣我們將來才能實現這些功能。還有，我最喜歡的例子——雖然這只是隨機舉個例子——假設我正在使用某張貼圖，而那張貼圖其實是某人拍攝的照片，如果我當時儲存了拍攝時的光圈值。

尺寸，如果我儲存了拍攝那張照片時的光圈值。現在我的「Uprising」演算法就擁有更多背景資訊。沒錯。 如果我知道那張貼圖被用在哪裡，如果我知道它被用在城堡上，還是用在地板上？我的「Uprising」演算法就能更聰明地進行生成，並在高端電腦或甚至尚未發明的未來電腦上，始終如一地保留原始創作者的意圖。

所以 

戴夫：我們在 RDC 上展示過這個，我記得我們播放了一段約 15 秒的影片，展示《Crossroads》被超採樣的效果。嗯，你能跟我們談談實際上可能會發生什麼嗎？這些資產都在雲端，包括 3D 物件和紋理。 嗯，我們會向內容系統發送額外的提示，說明這些資產都屬於……嗯，應該是一個比人們想像中更逼真的中世紀世界。

接著，所有這些不同的元素都會透過我們所謂的「3D 超採樣器」——或者更準確地說是「3D 生成式創建器」——重新生成，使其更貼近寫實版本。那麼，呃，誰想深入探討一下，例如這座城堡可能會發生什麼變化？ 

Sergey：我、我、我覺得就像Baron剛才提到的，你知道，呃，感覺我們似乎從那個世界中擷取了更多語義層面的資訊。

這點至關重要。舉這個十字路口的例子來說，對吧？如果你從單一資產的角度來看城堡，就像是一堆方塊，它們只是盒子。而且你缺乏足夠的上下文，所以無法讓那些方塊看起來更好。

而城堡，呃，它遠不止是單個方塊的集合。它是這些方塊的總和。呃，Slim 因為是在這樣的語境下運作，所以它能意識到這件事，把它當作一個整體來看待。因此，現在任何組裝過程，都會對城堡這個整體有更深入的理解，而不是僅僅關注個別資產。

所以，它就能製作出更……嗯，更優質的版本，像是那個經過上採樣處理的城堡，因為它，它就是，它就是理解到那一點 

戴夫：嗯，而且，從某種意義上來說，人們甚至可以想像，即使沒有現有的《十字路口》城堡。順帶一提，《十字路口》是一款非常古老、方塊感十足的 Roblox 遊戲。

那座城堡其實是提示詞的絕佳輔助。「幫我建一座城堡」這個提示詞本身相當開放，我們可能會得到一座隨機形狀的城堡。但「十字路口」裡的城堡，無論是尺寸還是結構，都提供了大量優質的提示資訊，能藉此將其上採樣成真正高品質的城堡。

Sergey：嗯，是的。嗯，這完全正確。因為，呃，呃，這座城堡的 3D 立體結構部分，首先，從遊戲玩法的角度來看，這會非常重要，對吧？所以你不能隨便生成一座城堡，然後指望它能在遊戲中正常運作。 呃，因為。但如果你能捕捉到所有維度，比如所有語義，在各種情境下，也就是說，在該資產被使用的所有場合中，那麼你就能非常高效地進行上採樣。

而且，這樣做也不會破壞你的遊戲。因為，這點也很重要。你可不想把一個資產過度簡化，導致遊戲變得無法遊玩。 

戴夫：嗯，我認為未來會有一種情境，除了所有的 3D 資訊外，你可以選擇編輯 3D 資訊，或是編輯提示語。

兩者結合起來生成那個世界，所以說。我們之前提到的五秒更新，未來可能變成五秒的提示更新，加上提示中多一點提示。然後按需懶惰地生成那個世界。還有，我認為還有最後一點，嗯，當我們思考 AI 如何在各個層面結合起來，讓這些東西達到照片級真實感時，我們還沒有。

還有最後一層，那就是 2D 層。你的遊戲電腦上會發生什麼？在雲端某個視訊裝置中又會發生什麼，那裡甚至可能進行更高階的上採樣？所以，嗯，舉例來說，我頭上的完美髮絲。處理那頭髮的最佳地點，可能是在本地端使用 2D 上採樣器。我知道你參與過許多嘗試在 3D 中處理頭髮的遊戲。

你怎麼看？你認為將來所有的頭髮效果都會改用 2D 上採樣來處理，還是會維持 3D 頭髮？ 

Sergey：是的，絕對是。我認為我們正朝著那個方向發展，因為有些事情只能在螢幕空間中處理，這樣效率更高。讓我這麼說吧，在螢幕空間中處理效率更高。

比如說，像這樣，呃，像頭髮渲染，對吧？所以，或者說。現在很多遊戲引擎都在做基於機器學習的上採樣，像是，呃，從 1080p 提升到 4K。但你其實可以做得比這多得多，對吧？你可以改變陰影效果，你可以，呃，改變物體的外觀。

如果把這個例子推向極端，遊戲引擎甚至可以直接渲染一些語義資訊給機器學習演算法，然後這個演算法就會生成看起來很棒的頭髮，或是很棒的材質。就像在空間中，透過指令。

戴夫：太棒了。嗯，那麼，隨著我們即將結束討論，或許對所有 C++ 程式設計師來說，還有那些組語程式設計師——呃，我，我真希望自己也能像他們一樣，那可是世界上最有趣的事情之一。我們現在正在做一件非常困難的事，對吧？我們正試圖讓所有這些技術在所有裝置上運行。

關於轉碼的問題。關於轉碼的問題是，我知道很多個人電腦都有優化措施，嗯，像是 SIMD 寄存器之類的，讓這些東西運行得更快。我們是否已經開始在我們的轉碼器中探索 SIMD 的應用，還是這是未來的優化方向？ 

Tsvetan：呃，首先，順帶一提，轉碼現在也可以在引擎上運行了。

好的。太好了。很好。所以我們正在利用 CMD 的優化，但我們，呃，還打算更進一步，使用 GPU 以及，呃，其他， 

戴夫：所以轉碼……好。轉碼在 GPU 上運作的可能性正在浮現。 

Tsvetan：嗯，是的，我們正在研究這件事。 

戴夫：好的。這會非常、非常有趣。好的，所以，呃，大家更新得很棒，呃，呃，對於想要看視覺呈現的人，可能會有 RDC 的主舞台演示。

我認為我們應該，我們有許多這方面的視覺資料。我們所談論的一切，都在開發進程中。呃，我們正密切關注，而且我，我，我真的認為，呃，在座各位以及你們身後的各支團隊，都在為我有時所稱的「遊戲引擎 2.0」做出貢獻，呃，這是一個高度雲端化的系統。

這整套技術都得到了 Transcoders 的強力支援。所以，感謝大家。我認為我們今天讓大家大開眼界。真的非常感謝。 

Tsvetan：謝謝。 

戴夫：好的，嗨，我是戴夫。嗯，再次感謝各位參與技術講座，我們期待下次與各位見面。代表整個團隊向大家致謝。謝謝。