Unity 近期發布了最新的云端分布式算力方案(點擊回看),能夠幫助開發者利用云算力和云存儲賦能開發過程。在技術開放日現場,Unity 技術專家為大家簡單介紹了云開發技術框架、RoadMap,以及現有云能力:云烘焙,云打包,云端資源格式轉換等。
本文節選了部分精彩內容,完整內容已上傳至 Unity 社區中的技術專欄?;廖哪?,點擊“閱讀原文”,即可跳轉至技術專欄學習:
https://developer.unity.cn/projects/openday-kevin
非常高興今天在這里和大家分享我們在做的 Unity 云端分布式算力方案,這其實是一個大計劃的前身,我們想用云來賦能開發者,滿足他們對于高算力、高存儲的需求。
我們做這件事的時候,先定義了一些 Workflow。比如游戲制作過程中,會有烘焙、光照貼圖、還需要去做打包 Assetbundle、導入資源或者資源格式轉化這些事情;在工業領域,可能需要兼容各種各樣的數據格式,然后借助 Unity 做一些 3D 的交互。這些事在日常工作中都是比較耗時的,如果都在一個本地的端上面做的話,就會比較有局限性。所以我們首先定義了 Workflow,無論用戶以什么樣的方式使用 Unity,我們都能夠以非常模塊化的方式給予云端方面的支持。
未來我們希望達到的是我們針對云以及云對端的賦能,讓大家在更豐富的終端做開發。比如現在我們只支持在 PC 的 Windows 和 MAC 還有 Linux 上做開發,但是將來如果真的那些比較重計算的這些消耗我們端能力的事情能夠被云賦能的話,其實有機會我們可以支持大家在更多的終端去做開發。
其實這和現在很火的 Metaverse 也是相關的。Metaverse 一定是支持任意端鏈接進入的虛擬世界,因此創作者也需要在任意端上做開發。不同的終端有不同的限制,比如有的終端 GPU 相對較弱,那么創作工具該如何解決這種問題,這是我們在思考的。如果能夠突破終端限制,我們就可以真正做到隨時隨地創作。
現在 Unity 一直在更新版本,添加新功能,如果未來都可以通過云服務的方式讓大家使用 Unity 的話,那么就沒有版本這個說法了,因為創作者總是會第一時間自動體驗到云端上最新版本的功能和服務。從而做的 Version-Less。
云服務也有利于促進團隊合作,因為它對需求的響應是非??斓?。如果大家在使用云端分布式烘焙解決方案時遇到了問題并反饋給我們,我們修改后,大家會立刻就能使用修改后的版本,因為它本身是一個云端的服務。
還有可擴展性,其實我們在國內就是要做一個跨云平臺的事情,讓開發者能夠觸達更多的云資源,甚至我們可以支持你做私有云的部署服務。
這個就是我們目前的一個架構,如果你們使用 Unity 的 XR Framework 的話會對這張圖非常熟悉。這其實體現的是一個理念:把 Unity 定義的生產流程當中會用到的能力進行標準化,并提供給開發者,然后開發者基于我們封裝的標準化流程做相應的生產流程,然后我們再去應對不同廠商它們在 IaaS 層的差異。
工作流方面的話,引擎這邊就會在底層的基礎能力上去提供標準化的創作管線,比如之前分享過的數字人生產流程,從掃描的數字人到建模、然后面部驅動、渲染、毛發、皮膚等一系列的流程。然后用戶可以按照工作流的邏輯和能力,自己進行定制化開發或刪減,做各種拓展。Unity 之前做的大世界方案也被拓展成了生產流程,之后我們也會在這些不同的生產流程上面做更多的迭代,并分享給開發者。
這里簡單講一下我們在云端目前做了一些什么事情。
除了云端分布式算力方案,還有對象存儲的桶的能力,這項功能在最新的 Unity 長期支持版里已經可以使用了。這個能力允許開發者非常方便地把資源存在云端/本地,不管是在開發階段還是運行期,實際上我們是封裝了對象存儲器所有的 API,直接生效給到你,然后開發者再去存。
然后基于對象存儲器的能力和云函數能力我們做了幾個功能,就是 lightmap baking, Asset Bundel Build,然后 asset 的導入,這些都是對現有生產流程的加強。然后還有就是 BIM 數據的 convert,把 BIM 的數據變成 Unity 能識別的數據,這是一個新的功能。還有今年 Instant Game,也是基于云端能力實現的。我們未來還會接著做的一些新功能。
實際上我們自己已經可以在云端協同地去做一些事情了,現在我們做的是把這些能力封裝成組件分享給開發者,一旦他們有類似的需求,就能直接使用我們提供的組件。這些組件有的是云上面的概念,我們就把它封裝成了 Event System 的方式,然后我們基于此做了一些功能,比如云端分布式渲染系統。
Unity 也在做多機協同渲染。其實之前 Unity 有做過一個 Cloud Rendering 的東西,但是它就是比較初級的狀態,現在我們實際上是在它的基礎上去做分布式的渲染,把我們的渲染任務分到很多渲染節點上面,然后再由一堆邏輯服務器去更新自己的邏輯,就是這樣一個事情。
因為我們對象存儲的地方已經做了一個封裝,然后再有 Event 的話,我們其實就可以在云上做一個類似于 Asset brower 的東西,這樣子的話可以讓我們的開發者非常方便地去搜索資源,即便這個資源不在本地。
基于這些,我們設想未來把這些能力都集中到引擎里,比如讓大家可以在云端與 HDRP 集成,然后讓 HDRP 進行分布式渲染,同時物理模擬過程也可以考慮做分布式。
這里想單獨介紹一下 Auto Streaming,簡單來說,這個 Auto Streaming 就是幫助大家減少首包大小的。
它解決了兩個問題。首先是安裝,當首包小到一定程度的時候你就可以用很多方式把游戲分享出去,比如說像以前 Unity 做的 Instant Game 的方式,或者預先把 Unity 足夠小的首包合進某一個 super app 這種方式來做到。而且足夠小的首包就意味著秒啟動,如果每個包下載數量低于 40 兆,就可以在 CDN 的加持下做到很快的下載,然后秒開。給到你的應該是一個類似于云游的體驗。
Auto Streaming 的 APK 可以實現漸進式的加載過程,會從不清晰的狀態慢慢到清晰狀態。這個也是 Auto Streaming 的一個小小的副作用,但是你享受的是一個 Native APP 的體驗。而且無論是從分發上還是啟動上,它跟幾個 G 的包體提供的體驗相差無幾。
這個圖也已經展示過了,實際上這個功能我們還在不斷地迭代,它現在已經可以把包體壓縮得比這個更小。
然后我們現在能夠提供的 Streaming 資源只有 texture、mesh,未來還會有 audio、font、animation 做上。其實我們分析過,就是哪些東西它占包體比較大我們就會先做哪些,把它做到很小,這個過程全部都在引擎里進行,所以對于開發者來說是無感的。它相較于我們用 addressable system 的區別是在于,你可能需要用到你的 code 去適應 Addressable system 的 API。但是你用 Auto Streaming 的話,它是在引擎里面幫你把這些事情做了。
Asset bundle 是把大一些的資源分離出來,在該處留下一個占位符。隨著相應的 code 在引擎上被觸發,我們會從 CCD 上下載對應的東西,加載出來。
這個是我們目前已經合作的平臺,這證明了這個東西它是可以集成到一個 Super APP 里面的,就像剛才我說那樣的,它其實做到了手包減小之后,它還可以做到免安裝。一個 2G 的游戲要集成到某一個平臺那是不可能的,但是如果是一個十幾兆的首包,它其實是可以做到的。
Auto Streaming 現在已經有很多 CP 廠商他們自己基于我們提供的技術,直接把游戲轉成了 Instant Game,所以它已經是一個日趨成熟的產品。
Unity Instant Game 產品詳情頁:
這是這個產品的交流群,大家如果想加入的話可以掃描。
接著講云端分布式解決方案的事情,就是我們做了一個分布式的烘焙,這個其實是用到了云函數和剛才講的對象存儲。第一個版本我們做的是 Enlighten 的,因為大家可能用 Unity 的都知道,就是很早以前 Unity 關于 realtime GI 都是用 Enlighten。后來有一段時間我們自己開發了一個 progressive,然后最近 2021 版 Enlighten 又回來了。我們現在第一個先用 Enlighten 做分布式烘焙,如果 progressive 有需求的話,我們也會把它排上進度。
簡單講一下云烘焙的一些概述,還有它的一些特點。
現在大家都在做大世界場景的游戲,烘焙就是一個問題,耗時是絕對的。云烘焙的理念其實很簡單,就是在 Unity 里面,我們在烘焙的時候實際上我們會把場景做一些處理,其實在這個過程當中你不用擔心你的場景數據傳到云上去會泄露一些資產,其實我們傳上去的是 enlighten 數據格式的 binary,然后傳上去之后去做光線的計算。
所以這個過程你可以理解成,我們把起始資產傳上去,然后拿到的是已經烘焙好的光照貼圖的一些中間結果,最后我們會在邊緣端去合成光照貼圖,所以基本上不會發生你的數字資產在云端被泄露的情況。而且一開始我們的 demo 就是巨大的,所以我們輕易不會有這種擔心。
云烘焙的成本非常低。首先它在云上是分布式的,就是你可以用很多機器去幫你做協同的烘焙。然后它是基于云函數的,所以成本可控?,F在每個云廠商都各有不同,有些云廠商可以是以 100 毫秒的粒度計費,有些可以 10 毫秒。成本計算就是你用多少是多少。而且它在云端是一個多進程,多機協同的,所以無論是從運算能力還是內存上面都是更有優勢的。最后就是免部署,因為它是一個云函數嘛。
它的使用方式也非常簡單,打開 Unity 編輯器,勾選 Lighting 面板 Enlighten 模式下的 Cloud Bake 即可完成部署。所以它對于你的開發體驗完全沒有影響的,它只是單純地用云來協助了你的開發過程。
我們自己做了一個場景測試,可以看到提升還是非常明顯的,基本上烘焙的大多數階段的任務都放云上去了,熟悉 enlighten 的開發者會知道 enlighten 的各個環節的并發度和場景高度相關,像我們這個測試場景有一些任務并發度不高,考慮到上傳下載的時間收益就有限,但也有一些任務并發度非常高的,比如 light transport 等,這種任務傳到云上它的收獲就會非常的大,所以整體收益其實也是蠻可觀的。云上機器和本地機器對比,但其實我認為不用關注云上的機器,因為我們本身是云函數,所以廠商分配什么機器給你其實你都不用在意,你只需要云函數可以運行你的云任務就可以了。