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

随笔3个月前发布 局外人
42 0 0

文章转自: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

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...