webgl框架介绍以及webgl项目的技术选型问题

文章转自：https://blog.csdn.net/lengyoumo/article/details/107576480?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-0-107576480-blog-125595691.pc_relevant_3mothn_strategy_and_data_recovery&spm=1001.2101.3001.4242.1&utm_relevant_index=2

请看原文

一 什么是webgl

webgl其实就是opengl。自大前端时代到来以后，硬件的给力，浏览器的发力，使得前端越来越硬气，开始尝试挑战分外之事，三维就是其中之一。浏览器打通了显卡的对接入口。使得前端开发人员可以使用gpu的算力来实现自己猥琐的意图。

二 webgl的框架介绍

webgl的框架我认为分类两大类：

前端级框架，比如js框架比较常见的有 threejs、babylonjs、cesiumjs等

引擎级框架，比如blender web、qt webgl、ue4、unity3d等

实际上远远不止这些。。。。

那么前端级框架和引擎级框架的主要区别在哪里呢？

他们的主要区别在于解决方案的完整性。

前端级框架，说是框架其实只是一个webgl库，提供一些3d绘制方法，敏捷轻量性能好，但不提供整体解决方案，维稳和拓展基本靠社区和js纯撸。

而引擎级框架提供的是整体解决方案、完整的开发工具链、以及庞大的组件群，体量大且需要编译。

2.1 前端级框架

就是说前端级别框架，主要解决网页端，基于js语言开发，属于js框架的一种

2.1.2 前端级框架的优缺点

【优点】

可以js编写，除了工程化开发外，无需编译，既改既得。

逻辑性能较好。由于js直接和浏览器的opengl借口对接，无需引擎级别的播放器等东西转译，所以性能比较好。但，不是最好。后面有介绍。

容量较小。由于没有引擎的播放器，又少了很多引擎内置的工具，所以相比较来说该项目的容量较小。但，不是最小。后面有介绍。

可分离渲染。我们知道webgl是使用canvas渲染的。而canvas和其他dom节点一样属于同层。所以我们可以把ui部分抽离出来用普通的dom去做渲染。虽然引擎级框架也能这样搞，但是必须抽象出很多通信方法，相比之下会有很多不必要的性能消耗

【缺点】

由于没有编辑器，纯撸代码，导致开发、调试、检错都十分麻烦。开发者为了调试效果和bug需要一遍遍的刷新网页（你不可以使用类似webpack的热更，因为你更不起）

glsl编写也很麻烦。由于属于js内嵌语法，没有什么现成的工具帮你规范化或检错。像这种需要频繁修改查看效果的语言，可想而知写起来有多麻烦。

插件支持没有引擎级的质量好

大多由社区维护。迭代比较慢，组件规范比较乱。

2.1.3 一些前端级框架介绍

【treejs】比较有名比较早。很久以前我用这个做过项目。总结过来就是，他是一堆工具的集合。相比较其他的前端框架，自由度比较高，另外解决方案也多。拿模型解析器来说，前端框架里，没有比threejs支持的模型格式更多的了。threejs的插件在网上也是一抓一大把，各种教程也很丰富。适用于绝大部分项目

【babylonjs】微软的webgl框架。相比较threejs，这个看起来要规范整洁很多。很多团队都开始采用这个作为webgl构建的主要技术栈。当时我用的时候，主要不满他的model loader。上面那位的优点，就是这位的缺点。有人说有些项目babylon能做 threejs做不了，那是绝对不可能的。

【cesiumjs】如果你做过gis项目，那么对这个一定不陌生，实际上相似的框架非常多，都是专门做地图预览、路线规划的webgl引擎。值得一提的是这类引擎对大规模渲染比较精专，但对较高显示质量的项目需求就明显力不从心了。

2.2 引擎级框架

引擎级框架通常使用前端以外的语言开发，需要通过编译打包生成前端项目。引擎级框架通常包含整套的解决方案，擅长解决复合问题，擅长跨平台打包。

2.2.1 引擎级框架的优缺点

! (前端框架优缺点) == 引擎框架优缺点 : p

【优点】

全面的平台输出。你现在需要做网页项目，ok没问题。但如果有一天你需要打包成windows应用程序、mac应用程序、linux应用程序，甚至是android、ios的app，也是完全ok的。这个无敌吧？

完整的可视化解决方案。无论是ui、还是控制、骨骼、光影、粒子、lod、shader、你能想到的大部分复杂功能，引擎都会给你完整的可视化解决方案。无需担心实现困难，或代价过高。

各种效果优化、性能优化完善。效果优化，包含一些光影、锯齿等等，性能优化包括物体等级显示、贴图打包、shaderLOD、esc、dots、tiny等等。后面说的这三个，是性能翻盘前端框架的重要因素。稍后介绍。

glsl的支持更好。引擎级都提供opengl的直接编写或编译。可以事实看到效果，有相关的编辑器插件可以用。

虽然打包需要编译，但开发、调试、debug非常开心。可以使用开发平台内核runtime。

使用强类型语言开发，天生丽质。一般有c++，c#，Typescript。(blender webgl是个奇葩，用python)

性能好。你肯能会奇怪我是不是脑子被驴踢了，缺点里写性能不好，优点里写性能好。是不是脑子被踢了。需要说明的是，普通的webgl项目性能是一定不如前端级框架的。但使用了ecs、dots、tiny project的项目，性能是一定会好过前端框架的。因为内存栈经过优化，可以更精确命中存储位置，而且可以输出webAssembly代码，不仅代码量会大幅减少，代码也会直接作用与浏览器，这要比js少一个语言解释的处理过程快不少。但这个需要特殊的技术栈，以及对框架更深的理解才行（亲测，调试不方便）

【缺点】

普通引擎webgl项目输出，性能不好。不及前端级框架。

无法直接对项目进行调试。输出项目需要经过编译

特别优秀的框架级引擎，需要考虑技术产权问题，需要付费。拿unity来说，1人1月大概至少1240. 不过如果公司有些名气可以申请合作，产品打上unity的标，可以不要钱。

2.2.2 一些引擎级框架介绍

【blender 4web】

blender退出的webgl框架，使用python编写，最大的优点是可以直接使用blender来操作模型及动画部分

【qt webgl】

使用qml编写页面元素，使用c++ 编写webgl项目部分。使用qt特有的事件驱动写法可以实现很多复杂的交互需求。依托qt强大的跨平台能力也会使项目的面相好一些。

【ue4】

使用c++编写，打包时输出webgl项目。可以使用引擎编辑器开发、调试，内置方法、组件极多，功能非常完善。ue4的蓝图系统始终被人津津乐道，还有shader的可视化工具，比起前端框架省掉了不少麻烦。ue4在任何平台输出都是效果最好的那个。但webgl性能一般。

【unity3d】

使用typescript或c#编写。由于支持typescript，所以可能对前端开发人员更好些（不过unity正在努力去掉ts）。像ue4一样也有可视化的shader编辑工具，2020年7月又推出了模仿ue4蓝图的可视化逻辑系统。可以使用引擎编辑器开发、调试，内置方法组件、第三方插件极多。功能非常完善。值得一提的是u3d可以导出两种webgl项目。一种是常规带播放器的webgl。性能比较一般。比前端级框架性能低。 还有一种tiny+dots+esc的组合解决方案，可以导出assembly代码的webgl项目。性能有质的飞跃，也许是性能最好一种方案。

技术选型问题

前端级框架 vs 引擎级框架

关键问题来了。你有一个webgl项目，你应该采用哪种方案？

展示类的小项目

【需求】

比如58同城的 3d房型预览，

淘宝的3d商品预览

京东的笔记本商品3d预览

【方案】

用任何框架都行。但更推荐前端级框架threejs、babylonjs。道理很简单。因为需求简单，开发并不费劲，就算不精通计算机视觉，普通前端开发者也能完成项目，未来迁移或转接也方便些。必将前端开发者遍地都是。。。

qt webgl其实也是个不错的选择。

blend4web。由于blender的加持，不仅可以解决开发调试问题，渲染和动画方面也会有质量保障。

地图、路线规划、交通指引等项目

推荐使用前端级cesiumjs。更适合大规模的建筑渲染。有很多内置功能方便开发。

u3d的tiny project可以解决webgl体量过大的问题，esc、dots可以解决大规模渲染问题。通过使用ai navgation可以解决寻路演示问题。

网页游戏、大型演示项目

这类项目不要犹豫，老老实实选择引擎级框架。不要心疼那个软件授权费。他会给你节省很多填坑时间、开发经费。而且也方便功能扩展，更方便未来多平台打包的需求。

blender4web，qt webgl，u3d，ue4 都可以。(blender4web是免费的)

废话部分

最近面试了很多公司，感慨颇多

技术选型是重中之重，应该是所有企业的共识，这不仅关于到当前项目的交付，也涉及到未来项目的生命线和前景。但就有人只想选自己精通的技术而忽略项目本身的成长需求。

不管是什么技术，选型决策者都应该具备开阔的技术视野。有个前辈曾对我说过，什么事情最好亲自尝试，知道和做过，是完全两个不同的概念。所以也推荐选型的项目管理人员应该亲自调研，以免造成损失。

有些公司明显因为技术选型的问题把项目带进的不上不下的境地。让我印象最深刻的就是前些天遇到一家专做交通规划的公司，选了一个不合适的技术栈全家桶，项目进行到中期整个技术部在填坑，填了2个月，最后决定重构、换栈。爽吗？当初多调研一下，顶多就是耽误点时间delay下进程而已。何必现在这么苦恼。归根结底，选型人员过于执着的选择了自己擅长的技术。

我做过很多项目，从网站前后端，到跨平台客户端，从软件到游戏都有过。webgl项目也不少：有在线演示，动画展示，产品展示，地图路线导航什么的。上面提到的工具我都亲自使用过。根据经验，技术选型总结下来就是，是什么鸟，吃什么食。吃什么饭，拉什么屎。总有些前端人员总是幻想js可以统一全平台，某些java后端开发总是幻想java可以搞定一切需求包括高交互项目。。为了项目和团队的健康，不要什么项目都选自己精通的技术，要选对的技术栈，选健康的解决方案。多做调研，多听意见，别犯浑。

————————————————

版权声明：本文为CSDN博主「千年奇葩」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/lengyoumo/article/details/107576480