C/S架构和B/S架构两种数字孪生技术路线的区别是什么？
山海鲸创造了一种CS和BS热切换的编辑模式，即CSaaS架构，可以在安装软件之后一键从软件的CS状态切换为一个BS服务器，让私有化部署变得十分轻松。具体效果可以参照下面的视频：
可以看到，在视频中我们先在软件中进行了编辑，随后切换到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的整合，哪个都不是简单的问题，只能说任重而道远啊。
综上所述，选择何种数字孪生技术路线更多要取决于最终的项目特点和公司自身的技术栈，以及项目中对于引擎的定制开发程度。
