此處介紹的，是 3dtiles 1.0（不含 next），以及 i3s 1.7
1. 相同點
均將三維模型通過轉換的手段細碎化，使得局部加載壓力降低，渲染性能有了提高的可能性。
均使用樹結構這種空間索引類型進行原始模型空間上的分割，允許使用常見的樹結構。
二者在樹的末梢，又叫葉子節點，也即真正承載三維數據的文件中，均使用了面向 GPU 友好的格式。
均爲開源三維數據格式標準。
均使用 json + 二進制 的組合方式，對細碎化後的數據文件進行組裝。
2. 不同點
開閉性
i3s 雖然格式開放，但是加載過程是封閉的（ArcGIS JsAPI不開源）
可擴展性
i3s 存在設計冗餘，json 描述文件的字段非常豐富，但沒有留下擴展餘地；3dtiles 在 json 描述文件的設計上較爲簡單，使用擴展項來擴充新功能
資源解耦
i3s 在葉子節點（稱作 Node）的數據文件設計中做到了幾何、非幾何、紋理的解耦合，可分別優化；3dtiles 在葉子節點（稱作 Tile）的數據文件設計中使用了開源三維數據標準 glTF 2.0；
物理存儲
i3s 支持 slpk 這種 zip 格式的單文件打包，也支持 RESTful 訪問（官方在 ArcGIS DataStore 中使用了 CouchDB）；3dtiles 目前最廣泛的實現仍舊是離散文件的靜態伺服
版本演進
i3s 社區版本與 OGC 版本不同步，目前社區版已推進到 1.8，而 OGC 版本是 1.1；3dtiles 則一致
非空間屬性數據
3dtiles 對瓦片中三維對象的屬性數據設計一般，不推薦將大量屬性寫入瓦片文件中；i3s 在設計上就支持 RESTful，可承載大量屬性數據（非幾何）
內容區分
i3s 整份數據集的名稱是“場景圖層（scenelayer）”，而 3dtiles 則是“瓦片集（tileset）”，二者在數據類型區分層級不同，i3s 的類型界定層級是整個場景圖層，而 3dtiles 則是具體到某一個瓦片。
結構描述
雖然都使用 JSON 描述數據集，但是存儲的位置卻不盡一樣。i3s 在整個圖層有一份獨立的 JSON，在每一個 node 還單獨分離了各自的 JSON 描述文件；3dtiles 則不管瓦片數據集還是瓦片的描述 JSON，統一集中在入口文件。
座標系統
3dtiles 僅支持唯一的三維笛卡爾座標系，其參考橢球爲 WGS84，其座標系編碼爲 EPSG:4979；i3s 可以是任意的座標系，但是調度方式受限於 ArcGIS JsAPI，不知道其原理。
3. 優點
3dtiles
在 b3dm 和 i3dm 瓦片中充分繼承了 glTF 的優點，並且自己也可以通過擴展的方式來增補新的功能；
內容組織非常靈活，性能上限取決於數據生產工具編寫人員的能力。
座標系組織靈活，允許開發者使用轉換矩陣統一轉換至 EPSG:4979 座標系下
i3s
每一個資源均有完備的 json 定義，充分考慮到了各種情況；
在 1.7 版本中，空間索引在物理文件上使用了 nodePage 來存儲，提高索引速度；
葉子節點（也即 node）內容的組織上，充分解耦合了幾何、非幾何屬性數據、紋理、要素邏輯構成等，以便分別優化；
規範原生支持 RESTful，配合 CouchDB 存儲有利於語義化尋找特定資源；
有專門的 BIM 類型場景圖層，ArcGIS JsAPI 應該是針對這種局部且細碎的模型有專門優化；
支持多種座標系定義；
資源文件有 gzip 壓縮，幾何資源文件還可以進一步使用 draco 壓縮編碼並 gzip 再次壓縮減小體積。
在 1.7 版本，因爲增加了 nodePage 機制，索引性能有明顯提升。
4. 缺點
3dtiles
JSON 中元數據較少；
瓦片文件嵌合了幾何、屬性、紋理等所有信息，對帶寬壓力大的服務器/客戶端來說，請求稍大的瓦片比較費力；
JSON 入口文件過於靈活，若將主入口文件設計得過大而不做 external tileset 的拆分，受制於 Cesium.js 的讀取機制，會白白浪費索引性能。
i3s
沒有留有可供擴展的定義；複雜層級的模型組織不支持。
3dtiles 系列斷斷續續寫了一年，就寫到這裏，1.0 標準包括瓦片數據集各種對象的定義、瓦片文件的格式、兩個擴展項已全部解讀完畢，或有疏漏，歡迎交流。
即將開啓第二階段：3D Tiles Next.