山海鯨可視化創造了一種CS和BS熱切換的編輯模式，即CSaaS架構，可以在安裝軟體之後一鍵從軟體的CS狀態切換為一個BS伺服器，讓私有化部署變得十分輕鬆。在視頻中我們先在CS模式下的軟體中進行了編輯，隨後熱切換到BS模式下的web中依然可以在幾乎完全相同的體驗下進行編輯。 ...
山海鯨創造了一種CS和BS熱切換的編輯模式，即CSaaS架構，可以在安裝軟體之後一鍵從軟體的CS狀態切換為一個BS伺服器，讓私有化部署變得十分輕鬆。具體效果可以參照下麵的視頻：
（https://www.bilibili.com/video/BV1NP411Z7zS/）
可以看到，在視頻中我們先在軟體中進行了編輯，隨後切換到web中依然可以在幾乎完全相同的體驗下進行編輯。
雖然山海鯨的CS和BS熱切換非常強大和方便，但我理解這並未觸及到這個問題的本質，這個問題的核心應該不僅僅是BS和CS，下麵我分三個層次再深入地聊一下這個話題。
第一個層次：純粹BS和CS的區別。這就不得不聊到為什麼山海鯨會做CSaaS了。首先，CS本身的優勢是下載和部署簡單，一個安裝包就能解決所有問題。但軟體安裝之後，只有一臺電腦能使用，如需要在其他電腦使用則需要各自再裝一個軟體，且CS在協同編輯上也不方便。而山海鯨很多客戶是政企客戶，如若領導要查看某項數據就需要裝一個軟體的話，那估計領導電腦就爆了。因此山海鯨結合兩者的特點，不僅能一鍵切換，還能熱切換甚至同時在BS和CS上操作（目前因為定價原因做了限制）。底層我們自己實現了一套框架（我們稱之為VenJS，即Vue+Electron+Nestjs），讓一套代碼同時跑在軟體中或者瀏覽器和伺服器上，同時，我們做了一個協議的中間件，封裝了http協議和進程間通信。基於VenJS寫代碼時候無需關心底層通信協議，協議的介面直接暴露在axios介面中。寫代碼的時候完全當作網站來寫，由框架來把程式打包到軟體當中。同一套代碼，VenJS既可以打包成純軟體，也可以打包成純網站，也可以打包出混血兒（就是現在山海鯨軟體主版本採用的模式）具體代碼細節以後有機會開一個專欄寫一下，我們也有考慮後續框架成熟後可能會開源出來運營。
第二個層次：關於游戲引擎和WebGL。實際上這兩個完全不是一個層面的東西，所以我們可以拆成兩個部分來看。我們先聊聊工具鏈完善的PC端游戲引擎VS一般只有一個框架代碼的Web端3D引擎。無論是從視覺還是開發便利性來看，ue或者unity這類游戲引擎完勝，不管是體積雲天空、體積霧、水效這類複雜的視覺元素，或者地形編輯、材質節點等等這類輔助工具都會比Web上的引擎高一個層級，非要用Webgl框架，那美術得砍死你。如果只是做一些簡單的Demo，那Web端引擎只剩一個優勢，就是對於Web前端開發者來說上手簡單。當然PC端引擎最終能不能跑在Web上也算一個問題，這個問題我們在第三個層次再探討，這裡我們單純對比框架本身。但如果要做大型項目，特別是數字孿生項目，就是各有優勢了，因為這類項目對數據集成和一些2D圖表的整合要求很高，這個時候PC上的游戲引擎用起來就不太順手了，畢竟他們是游戲引擎，對於通信這類整合和Web前端框架相比就略顯難用（當然也取決於開發者對不同語言的熟悉程度）。再進一步來說，如果像是我們山海鯨本身自己要做數字孿生引擎，自己要來提供數字孿生工具鏈的話，那就遠不如開源的前端框架好用了。我們需要大量整合的底層介面，需要定製魔改的渲染管線，幾乎都等於再寫一個引擎的工作量了，所以選開源的來改方便太多。
第三個層次：關於D3D和WebGL或者說將來關於Vulkan和WebGPU。這個問題首先有一個前提，那就是這個項目是否需要跑在Web上，如果需要，那就沒有對比的必要了。因為只要想跑在Web上，目前就只能用WebGL，Web端應用Unity最終的也得編譯到WebGL上運行，UE在官方版本中甚至直接取消了對於WebGL的編譯，要自己去編譯UE的社區版或者用ue的Pixel Streaming，當然這就完全是另一回事了。單純對比性能來說，WebGL肯定是完全沒法比的。如果項目不用跑在Web上，那其實這個問題就變成了應該選OpenGL還是D3D了，這個問題其實看看各大游戲引擎的選擇就可見一斑了。回到我們山海鯨本身，目前雖然我們實現了一鍵熱切BS/CS，但是渲染依然基於WebGL來做，下一步我們希望整合D3D的渲染能力，讓CS狀態下在D3D中渲染。當然這中間牽扯的Shader轉換、Windows句柄和Chromium的整合，哪個都不是簡單的問題，只能說任重而道遠啊。
綜上所述，選擇何種數字孿生技術路線更多要取決於最終的項目特點和公司自身的技術棧，以及項目中對於引擎的定製開發程度。
