X3D-一次編寫、處處、時時都可渲染的三維圖形格式

一方面，我們有Javascript的程式設計API，使用一些形式的三維畫布，像WebGL或O3D。另一方面，我們有保留模式的、DOM整合的三維圖形抽象，像X3D。

首先的一方面（讓我們稱之為Javascript方面）是由圖形程式設計師建立，這些Coder有的希望讓他們的硬體發揮最大的功效，有的則對
4×4矩陣的巧妙操作而陶醉，睡覺時都會夢到GLSL
。很多的X3D人，包括我自己，
熱衷於
做這種東東。

第二個方面，我將稱之為X3D方面，為那些web開發者或使用圖形像他們的工作致意的人們。也許他們想構建三維使用者介面，或者是他們在進行DNA的研究，或者採礦行業他們需要使用三維視覺化作為工作的一部分。

分到X3D這邊的人們可能也想使用在Javascript層所用不到的特性，如空間化聲音，或者想使用已經包含在X3D的面向圖形的概念，如光線交叉、碰撞檢測或檢視
投影剔除(frustum culling
)。

這些人可能也想他們的模型非常便攜 – WebGL是緊密遵循
OpenGL ES 2.0的一種API，而同時
設計上
X3D則是通用的，可以被OpenGL（任何版本）、DirectX或一些其它的未來的系統渲染。

所以，人們將會有選擇。我們每天都會看到像這樣的選擇。拿汽車做比，有些人喜歡
like to get under the hood and tinker
with the innards，有的人只喜歡進到車裡面並開到目的地。我們把Javascript這邊看作是
修補工具，而X3D作為僅想舒適的從“A”到達“B”的人們的交通工具。

讓HTML瀏覽器編寫者
原生
支援SVG與MathML用了一段時間，所以我們預計X3D也需要一段時間。

當然，我們期望HTML5瀏覽器編寫者最後會原生的包含對X3D的實現，要麼是包含像FreeWRL (http://freewrl.sourceforge.net

)這樣的
開源多平臺庫，或者是編寫他們自己的庫。

主要的區別在於Collada僅僅是模型交換格式，而X3D提供了模型交換及三維執行時環境。X3D給了你建立虛擬模型及與之互動的能力；它提供了不僅在螢幕上獲得三角形，並且交換及管理那些三角形(讓Web頁面建立者建立引人注目的內容)的方法學。

Collada允許用於
“bleeding edge”式的三維模型建立，而X3D給使用者的是穩定的、ISO標準化的格式
，這樣就不僅僅是三維模型的一般的交換，還有該模型的互動效果。

所以，再重複一下，就是我們有二元性，它給使用者可選擇性。

Dr Johannes Behr of Fraunhofer, 給過我下面的一個例項，我認為它很好的展示了我們怎樣看待Collada與X3D：

“Collada是一種真正的資料容器。所以你可以把你的模型從工具“A”搬到
工具
“B”再搬到
工具
“C”，而且還想在“C”中獲取你在“A”中的特定的擴充套件，儘管“B”對之無法理解。你看，差不多每款Collada工具都編寫並增加了自己對資料的擴充套件。Collada格式就是為了這種擴充套件性而生的，這是該設計的一種強大功能。

Collada因此也就是從工具“A”到工具“C”獲取資料而不會丟失內容的一種容器。但它不是一種傳遞或部署用的格式。

這與影像和文字檔案的情況相似。很多人用psd檔案儲存帶有層結構的影像，並從一個工具到另一個工具可以獲取資料，但沒有一個人會把那個psd檔案分發到
網路上。檔案檔案也同樣。每個人都會用.doc或.odf來儲存文字，但最終用pdf來傳遞。
因此，在不同領域都會有這種二元性。

3D方面也有同樣的處理。在你的管線中使用Collada，而在最終的執行時則是一種傳遞格式（像X3D）。

這不僅僅是我的觀點：想了解Collada和X3D之間更多背景知識，以及為什麼“X3D是應用於Web的一種理想語言“請閱讀白皮書， by Rémi
Arnaud (founder of the COLLADA initiative) 及 Tony Parisi,
(co-founder of VRML, and X3D architect):http://www.khronos.org/collada/presentations/Developing_Web_Applications_with_COLLADA_and_X3D.pdf

)

1) Flash不是開放標準。而Web是建立在開發標準之上的。

2) Flash當前不支援GPU的使用。

3) Flash沒有多廠商的支援。

Javascript能”處理“大場景嗎？你可以以任何一門計算語言來編寫出幾乎所有東西，它是否是最理想的反而不是真正的問題所在。

首先，我們來談談頂點/紋理渲染的速度。

In Javascript over WebGL,最少量的Javascript被用於渲染三角形與紋理 – 因為GPU在進行渲染。如果你丟入少量的housekeeping或互動，幀頻會顯著下降。

用一些真實世界的數字：
Dr. Johannes Behr of Fraunhofer發現在他的
X3D-Javascript-WebGL X3DOM實現中，小模型的渲染比同樣平臺原生X3D瀏覽器至少要慢30至50倍。
當然，更多的程式碼優化仍會進行；但要正確的來看待，我認為我為FreeWRL做的最大的優化是移除了用Perl進行housekeeping而完全基於C實現 – 幀頻的提升是比較顯著的。對於光線交叉、
投影剔除、使用者互動等，Javascript能計算得多快還有待確定，但看起來與原生應用程式相比至少要慢兩個級別。對於桌面系統，那可能還不是問題，但在移動領域電池使用時間與CPU週期緊密相關，可能需要更多的考慮。

第二，讀者也應該要記住X3D有內建的執行時環境；X3D瀏覽器作者花費了相當多的時間在確保執行時環境執行良好。具有原生X3D實現不僅意味著對三角形和紋理的更快渲染，也意味著統一、高效的執行時架構。

第三，我們發現浮點數的精度對高精度位置資料來說還不夠，所以X3D使用了雙精度數來進行內部計算，如插值器以及地理空間資料管理等。Dr.
Behr已提到他的小組在X3DOM 基於Javascript的X3D實現時已遭遇這個浮點精度問題。

最後，有個似乎被很多人漏過的問題，X3D提供了你的圖形軟體一種抽象的檢視，那是X3D瀏覽器實現者的工作，即確保幾何體儘可能高效快捷的被選入，而且
X3D瀏覽器會跟隨軟體及相關庫的改進。藝術家的時間最理想化的使用不是擔憂執行時的實現及特定軟體的效率，而是建立引人注目的跨平臺內容。

當前的X3D規範保留了與VRML-97的向後相容性。我們在繼續保持這種完整的向後相容性，同時讓標準成長到滿足當今的圖形需求，並推動該技術發展；比如X3D實現光線跟蹤。

VRML/X3D標準的“長壽性”和“跨平臺性”對很多使用者非常重要。我講個故事。最近有一位NASA的員工問我將VRML-1整合進FreeWRL瀏覽器的事，VRML-1先於VRML-97.我尋找線上規範，而且半天之後，該使用者就能在他的桌面Macintosh計算機上檢視這些檔案了。其它15歲的圖形格式還有多少能被渲染呢？

有人提到“三維圖形”的時候，從腦海裡面出現的第一件事就是這個偉大的產品來自好萊塢及遊戲公司。我們傾向於忘記科學及醫學成像這些領域中3D模型的“長壽性”與跨平臺的相容性是最為重要的事情。

Web3D協會正在繼續向世界帶來開放的三維渲染技術。

X3D:一次編寫、任何地方、任何時候都可渲染。