C/S架构和B/S架构两种数字孪生技术路线的区别是什么？

山海鲸创造了一种 CS 和 BS 热切换的编辑模式，即CSaaS 架构，可以在安装软件之后一键从软件的 CS 状态切换为一个 BS 服务器，让私有化部署变得十分轻松。具体效果可以参照下面的视频：
山海鲸可视化的 CSaaS 功能演示视频
在视频中我们先在软件中进行了编辑，随后切换到 web 中依然可以在几乎完全相同的体验下进行编辑。

虽然山海鲸的 CS 和 BS 热切换非常强大和方便，但我理解这并未触及到这个问题的本质，这个问题的核心应该不仅仅是 BS 和 CS，下面我分三个层次再深入地聊一下这个话题：

1. 纯粹 BS 和 CS 的区别

这就不得不聊到为什么山海鲸会做 CSaaS 了。首先，CS 本身的优势是下载和部署简单，一个安装包就能解决所有问题。但软件安装之后，只有一台电脑能使用，如需要在其他电脑使用则需要各自再装一个软件，且 CS 在协同编辑上也不方便。而山海鲸很多客户是政企客户，如若领导要查看某项数据就需要装一个软件的话，那估计领导电脑就爆了。因此山海鲸结合两者的特点，不仅能一键切换，还能热切换甚至同时在 BS 和 CS 上操作（目前因为定价原因做了限制）。底层我们自己实现了一套框架（我们称之为VenJS，即Vue+Electron+Nestjs），让一套代码同时跑在软件中或者浏览器和服务器上，同时，我们做了一个协议的中间件，封装了 http 协议和进程间通信。基于 VenJS 写代码时候无需关心底层通信协议，协议的接口直接暴露在 axios 接口中。写代码的时候完全当作网站来写，由框架来把程序打包到软件当中。同一套代码，VenJS 既可以打包成纯软件，也可以打包成纯网站，也可以打包出混血儿（就是现在山海鲸软件主版本采用的模式）具体代码细节以后有机会开一个专栏写一下，我们也有考虑后续框架成熟后可能会开源出来运营。

2. 关于游戏引擎和 WebGL

实际上这两个完全不是一个层面的东西，所以我们可以拆成两个部分来看。我们先聊聊工具链完善的 PC 端游戏引擎 VS 一般只有一个框架代码的 Web 端 3D 引擎。无论是从视觉还是开发便利性来看，ue 或者 unity 这类游戏引擎完胜，不管是体积云天空、体积雾、水效这类复杂的视觉元素，或者地形编辑、材质节点等等这类辅助工具都会比 Web 上的引擎高一个层级，非要用 Webgl 框架，那美术得砍死你。如果只是做一些简单的 Demo，那 Web 端引擎只剩一个优势，就是对于 Web 前端开发者来说上手简单。当然 PC 端引擎最终能不能跑在 Web 上也算一个问题，这个问题我们在第三个层次再探讨，这里我们单纯对比框架本身。但如果要做大型项目，特别是数字孪生项目，就是各有优势了，因为这类项目对数据集成和一些 2D 图表的整合要求很高，这个时候 PC 上的游戏引擎用起来就不太顺手了，毕竟他们是游戏引擎，对于通信这类整合和 Web 前端框架相比就略显难用（当然也取决于开发者对不同语言的熟悉程度）。再进一步来说，如果像是我们山海鲸本身自己要做数字孪生引擎，自己要来提供数字孪生工具链的话，那就远不如开源的前端框架好用了。我们需要大量整合的底层接口，需要定制魔改的渲染管线，几乎都等于再写一个引擎的工作量了，所以选开源的来改方便太多。

3. 关于 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 的整合，哪个都不是简单的问题，只能说任重而道远啊。

综上所述，选择何种数字孪生技术路线更多要取决于最终的项目特点和公司自身的技术栈，以及项目中对于引擎的定制开发程度。