![]()
智東西
作者|王涵
編輯|李水青
智東西4月15日報道,今天,“AI教母”李飛飛的世界模型團隊World Labs開源了動態3D高斯潑濺(3DGS)渲染器Spark 2.0。
![]()
▲Spark 2.0官宣開源(來源:X)
李飛飛本人在該成果發布的第一時間評論稱:“Spark 2.0現在可以在任意設備上流式傳輸超過1億個高斯潑濺!能夠為基于網頁的3DGS渲染開源生態做出貢獻,我們感到無比自豪!”
![]()
▲李飛飛評論(來源:X)
Spark系列模型于去年首次發布,是一個專為網頁構建的動態3D高斯潑濺(3DGS)渲染器。它與網頁端最流行的3D框架THREE.js集成,并利用WebGL2在任意帶有網頁瀏覽器的設備上運行,包括桌面端、iOS、Android以及VR設備。
與上一版本相比,Spark 2.0新增了一套細節層級(LoD)系統,能夠在任意設備上流式傳輸并渲染超大規模的3DGS世界。
▲在兒童房間里自由探索,物品細節清晰(來源:World Labs博客)
此外,新版還使用了.RAD的3DGS文件格式,支持漸進式細化的流式傳輸,而虛擬潑濺分頁系統則通過固定的GPU內存分配,實現了對無限潑濺世界的訪問,通俗來講就是可以渲染無限大的3D場景。
![]()
▲草原中的洞穴小屋,場景轉換無畸變(來源:World Labs博客)
如此流暢連貫的效果是怎么實現的?針對大規模場景的擴展難題,Spark 2.0運用了3項圖形學與系統底層方案:細節層次優化、漸進式流式加載以及虛擬顯存管理。
李飛飛團隊在博客中,對Spark 2.0背后的三項技術進行了十分詳細的展開,具體如下:
一、采取連續式細節層級,穩定渲染百萬級潑濺
在計算機圖形學中,處理大型3D場景時常常采用細節層級系統,該系統會根據物體與觀察者之間的距離自動調整渲染的細節程度,
不同的細節層級方法介于離散式與連續式之間,形成一個技術譜系。采用離散式細節層級(LoD,Level-of-Detail)時,系統需要為潑濺效果制作多個版本,從精簡到精細依次遞增,再根據各版本的近似邊界與相機的距離,在不同版本間進行切換。
Spark的早期系統設計支持離散模式,但其存在明顯缺陷:當用戶在場景中移動、不同版本突然切換時,畫面會出現明顯的跳變;此外,將潑濺效果按區塊分組后,用戶還能看到清晰的邊界痕跡。
Spark 2.0的LoD設計采用了一種連續式LoD方法,所有潑濺都存在于一個層級結構中,即LoD潑濺樹。Spark 2.0會沿著樹的一個邊界切割面單獨選取潑濺,從而在視口內優化潑濺的細節。
![]()
▲LoD潑濺樹(來源:World Labs博客)
樹中的每個內部節點都是其子節點的一個低分辨率版本,通過將子節點的多個潑濺合并成一個新的潑濺來近似表示子節點潑濺的形狀和顏色。這個過程一直持續到樹的根節點——一個單一的、大的潑濺,它聚合了該物體中所有潑濺的整體形狀和顏色。
利用這棵LoD潑濺樹,Spark 2.0會計算出穿過該樹的一個“切片”,從而為當前視口選取最佳的N個潑濺進行渲染。通過設置一個最大潑濺預算N(根據設備類型不同,通常在50萬到250萬個潑濺之間),系統確保每幀只需渲染恒定數量的潑濺,從而獲得穩定、高幀率的渲染性能。通過上下調整N值,即可在幀率和潑濺細節之間進行權衡。
![]()
▲公園中的自行車,細節真實,前后一致性強(來源:World Labs博客)
Spark 2.0通過同時遍歷多個LoD潑濺樹實例,對該算法進行了進一步擴展。與僅從單一根節點開始遍歷不同,針對每個3DGS物體,拓展后的算法會將其屏幕尺寸及潑濺節點 (dm0,Sm0) 一同加入初始優先隊列,后續流程與原有邏輯保持一致,可在場景中所有3DGS物體上同步篩選需細化的細節層級。
這一設計讓大規模組合世界的創建變得簡單高效:只需在空間任意位置添加3DGS LoD物體,Spark 2.0便能自動計算出每幀需渲染的所有LoD潑濺的最優全局子集。
二、設計新型文件格式,大場景3D世界在網頁上秒開
Spark2.0定義了一種新的文件格式.RAD(代表RADiance場),該格式能夠壓縮3DGS數據,并支持隨機訪問流式傳輸,從而在數據通過網絡傳輸時實現漸進式細化。
目前最常見的兩種3DGS數據文件格式是.PLY和.SPZ,它們代表了兩種不同的數據編碼方式:行式存儲和列式存儲。
.PLY文件是按行順序存儲的,在接收到數據后立即顯示潑濺,從而實現漸進式加載。但它未經過壓縮,且編碼精度存在浪費。.SPZ文件將相似類型的數據按列順序存儲在一起,從而獲得了更好的壓縮率。但遺憾的是,它無法實現漸進式加載,因為在任何潑濺獲得其所有屬性之前,必須接收完整的文件。
為實現3DGS數據的高效壓縮與流式傳輸,李飛飛團隊設計了全新的.RAD文件格式。該格式編解碼簡潔、擴展性強、編碼精度可調節,同時支持隨機訪問。
![]()
▲.RAD文件格式(來源:World Labs博客)
文件結構十分清晰:以RAD0文件頭開頭,隨后依次為頭部元數據長度、元數據JSON,以及一個或多個各含6.4萬個潑濺的數據塊。頭部元數據記錄了所有數據塊的偏移地址與字節大小,支持任意順序讀取數據塊內容。
單個數據塊也采用相似結構:以RADC塊頭起始,接著是塊元數據長度、元數據JSON,最后為該6.4萬個潑濺的壓縮數據。潑濺各項屬性按列存儲,可分別選用自定義編碼方式。同類數據集中存放,再通過Gzip壓縮,能獲得出色的壓縮率。
頭部采用JSON編碼,可通過版本字段與新增可選字段保障后續擴展。數據類型編碼與壓縮算法均以字符串名稱在元數據中指定,方便后續擴展新類型。
三、采用虛擬內存,開辟1600萬潑濺固定顯存池
虛擬內存是一項內存管理技術,它以固定大小的物理內存為基礎,向程序提供大容量的虛擬地址空間,并通過頁表以固定尺寸的頁為單位,完成虛擬地址與物理地址的映射。
Spark 2.0將這一思路應用到3DGS渲染中。具體來講,李飛飛團隊在GPU上開辟了一塊可容納1600萬個潑濺的固定顯存池,自動管理GPU中每6.4萬個潑濺為一頁的“顯存頁”,與.RAD文件中對應大小的虛擬數據塊之間的映射。
![]()
▲虛擬內存(來源:World Labs博客)
數據塊會按照LoD遍歷順序加載到空閑頁面中;當頁表占滿,且新數據塊優先級更高時,系統會按最近最少使用(LRU)策略淘汰舊數據。
Spark 2.0支持同時加載多個.RAD文件并共用同一張頁表。對每個文件,系統會記錄數據塊到頁表的映射,以及頁表到對應文件與數據的反向映射。
在遍歷多棵LoD潑濺樹時,引擎會記錄數據塊與文件的訪問順序,形成全局統一的優先級排序,進而對場景中所有3DGS物體的潑濺加載與存儲進行統一優化。
結語:Spark 2.0降低空間智能的創作門檻,爭奪基礎設施定義權
從2025年的首次亮相到今日的2.0版本迭代,Spark的進化軌跡某種程度上也映射著3DGS這一技術的成熟曲線。
三維內容的交付長期以來被兩座大山壓著:一是資產太重,動輒GB級的文件讓網頁端望而卻步;二是渲染太貴,高端GPU才能流暢運行的場景,手機瀏覽器只能圍觀。
Spark 2.0通過連續LoD、.RAD格式和虛擬顯存“三板斧”,讓高質量三維內容像普通圖片和視頻一樣,在互聯網上自由流動、即點即看。
李飛飛團隊選擇將該技術開源,降低了空間智能的創作門檻,同樣也是在爭奪下一代空間內容基礎設施的定義權。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.