2018年带三维团队的一点总结

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/1.题记2018年对我个人是一个比较有转折的一年。年初和女友结婚,年中有了孩子,这期间见识了何为家庭琐事,也见识了育儿不宜,偏偏身体不争气,自己还住了几次院,让家人更添担心。生活的波澜让人猝不及防,想过那么多未来,都不如活在当下。到现在,我应该写了137篇博文,都是各类技术...

2018年带三维团队的一点总结

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

1.题记

2018年对我个人是一个比较有转折的一年。年初和女友结婚,年中有了孩子,这期间见识了何为家庭琐事,也见识了育儿不宜,偏偏身体不争气,自己还住了几次院,让家人更添担心。生活的波澜让人猝不及防,想过那么多未来,都不如活在当下。

到现在,我应该写了137篇博文,都是各类技术总结或探讨。每一篇的开头第一章都叫“背景”。这次换一个标题吧,写一篇不像技术总结的总结。

  2018年的转折不止在生活上,工作的范畴也发生了很大的变化。从前,我和几个小伙伴只有一亩三分地,我们耕耘好即可,现在一亩三分地突然变成了十亩良田,几个小伙伴也变成了一群小伙伴,他们中既有C 做平台的,也有C#写工具的,还有专业处理数据的,更有分别做二维展示、实景展示、三维展示的。我的职责已经不仅仅是把产品整合打磨,更要沟通业务需求、协调各部门研发合作。简而言之,我可能变成了一个即是研发经理也是产品经理的杂人了。

大概用了半年左右,我才慢慢适应这个角色。而当时我最需要适应的,并不是沟通和交流的高频次,而是带三维团队这件事上。所以,明明我是想写一篇年终总结,想来想去,不如就写带三维团队的下半场总结吧,毕竟投入精力最多的就是它。

在今年七月时写了一篇文章《带三维团队半年的一点总结和想法》,现在可以书接前文,言归正传了。

2.招到一个合适的人

有时候,招到一个合适的人真如捡到宝贝一样,八月时的我就是这种感受。

在上半年,虽然三维在业务场景上与二维的一体化基本已完成,包括了服务端的共用、前端代码的整合、平台端的集成,同时也在多个项目中落地实施。但是很遗憾,就我个人目前的体会看,三维在业务上更多的像个花瓶,真正觉得是有效需求的可能还是地下管网之类。所以当时将三维的方向大致分为了两块:业务上配合管线团队;展示上突出大屏特效。

既然是花瓶,就得做个好看的花瓶。既然想普适项目,就得充分考虑数据的缺失。上半年想重点推动在数据缺失时,只用建筑物SHP来建立灰模特效场景,虽然当时有一定方案积累,但是遗憾的是,无论从效率上还是展现效果上,都与我的预期相差甚远。

而这一切,直到招到这个合适的人,我称他为zxl吧。

3.合谋

3.1最急切的事情

八月,我列了几点我最想解决的问题:

a.解决十万级建筑物SHP的灰模特效展示效率。

b.解决管线数据处理的复杂流程。

c.研究三维动态线、动态水域。

十万建筑物的展示是入门级问题,必须解决。三维的动态线和动态水域是为了灰模场景效果做铺垫。而管线处理流程的简化则是减轻业务负担的必须。

3.2 回复

九月时,我所关心的这些问题,在大家反复的讨论验证中,终于都有了回复。

十万建筑物SHP的灰模数据,用4千的笔记本也能在浏览器端跑的很流畅,帧率可以稳定在40以上。

而解决这个问题的重点依然是数据处理上,之前采用的方案是将SHP处理为json,然后前端解析json后实时拉伸绘制。可想而知,仅数据的请求获取以及数据的解析都将耗去太多计算性能,即使在前端绘制上采用LOD方案依然不能根本解决这个问题。现在我们采用优先将shp数据处理成三维模型数据,然后再按照正常流程处理为3dtiles。这样,前端加载时不用再做计算拉伸这些复杂过程,效率当然会大大提升。

动态水域、动态线则通过shader编写特效也顺利完成。

管线数据的处理简化,核心点在纹理的一次处理后重复复用以及多个工具流程整合成一个,从而顺利将之前处理500M管线数据需耗费4个小时,压缩至十分钟可以流程化处理完。

4.上路

终于,十月开始,我们进入了三维特效之路的探索,这段时间刚好也处于公司各项目开始进入验收回款的阶段,项目的压力比之前大了不少。还好三维团队成员在上半年的积累中已经越来越娴熟,所以依然可以保证让我放心的将zxl抽出来专门研究三维特效。

说到我们研究,那到底要研究哪些东西?在十月的一次汇报中,我给公司总监罗列了这些点:

a.建筑泛光和颜色渐变优化:颜色和泛光参数化控制、边界锯齿、透明处不可点击问题等。

b.动态线优化:锯齿问题、线条长度不一致问题。

c.水域动画优化:性能优化、对建筑物遮挡问题。

d.面向三维的底图配图设计。

e.与大屏展示的结合:案卷、轨迹。

 十一月底时,这些问题也终于基本一一解决,呈现在我面前的demo已经让我兴奋不已,那天应该是发了一个朋友圈的。可是我依然很严苛的对zxl说,你还有很多不够的:比如为什么轨迹的线头是个箭头,缩放后堆在一起了,我需要的是百度的蝌蚪状轨迹,我还需要轨迹粗细可以随视角变化;为什么建筑物点击后没有选中效果;整个场景真的太安静,如果建筑物也能发生些动态变化是否更好?我甩给他很多个为什么,也给了他不少我收集到的其他公司三维场景案例。

我想那时候zxl可能还是有点郁闷的。七月参加一个培训,记得讲座老师是阿里云的某个总吧,就记得两个核心点,一个是中台共享,一个是研发人员要皮实。Zxl是个皮实的伙伴。他在十二月时解决了我很多个为什么。于是有了下面这个截图:

5.轨迹

依然逃不过轨迹这个话题。

上半年二维团队做了一系列研究,终于完成了1W辆车的实时轨迹存储和实时多轨迹展示方案,现在,三维团队也要来进行展示了,只有这样,三维的动态轨迹线才能真正和业务结合。

既然二三维一体化了,我们不能再来一套存储和对接方案。所以,我安排研发进行了轨迹中心的封装和重构,将轨迹处理和对接部分从二维中抽离成独立模块。由轨迹中心完成轨迹数据的推送和前端接收数据,此时,通过事件机制将轨迹分发。二三维模块均通过监听该事件来获取实时轨迹。

但是三维对轨迹数据质量的要求是高于二维的。轨迹线穿墙在二维中不会造成明显的视觉混乱,但是在三维中,轨迹线穿墙却是一个很糟糕的视觉感触。所以实时轨迹的路线匹配纠正是一个不得不进行的研究。以下为目前正在改造的二三维轨迹中心架构设计:

6.细化

时光进入十二月,三维场景展示进入了精细化打磨阶段。期间主要针对以下几个方面打磨:

a.在灰模中构建标志性建筑物;

b.案卷展示场景的研究;

我们先说说标志性建筑物问题。由于灰模均是基于建筑物SHP拉伸处理而来,其精细度相对于精模数据是大打折扣的。在一个城市场景中,如果没有标志性建筑物的展现,就像没有这个城市的灵魂。打个简单的比方,没有东方明珠的上海,即使展现了黄浦江,很多人一样不能一眼识别出这是上海。那么如何实现灰模场景中的精模效果呢?这又要回到数据的本身了。我们将此问题归结为两类:已有精模数据和没有精模数据。

当有精模数据时,我们把数据进行处理展示于平台,然后对模型外部进行高亮蒙皮,效果如下:

当没有精模数据时,我们对SHP做复杂处理,比如塔,我们可以做多个同心圆然后拉伸建模,效果如下:

但是,基于SHP拉伸不能处理复杂的构造。终归,我们还是要回到数据建模的路上。再次遗憾,公司的3dmax三维数据建模重来都是外包的。团队的数据处理人员以前只做二维数据勾画、配图等,现在必须上了,还好经过短暂的学习,现在基本可以做简单的模型:

再说到第二个重点问题,案卷展示场景的研究。热力和聚类是必不可少的两种宏观展示方案,但是,二维的热力都是平面的,三维的,必须有所不同。百度和高德的三维热力,是以立面格网来进行展示。我想,我们以真正的里面热力来试试。Zxl同学的解决效果如下:

随着视角的拉进,热力需要自动消失,此时应该展现出案卷的详细分布。当然,三维也应该有三维的案卷分布样子:

7.前行

最后时间翻过了2018,我觉得我还是有很多不满,很多期待。

期待,三维实时轨迹的完整流程全面落地。

期待,实时轨迹的高效纠正。

期待,三维的数据专家可以独挡一面,将模型处理做的更精细,将灰模做的更高效。

期待,案卷展示的方式、图标、甚至高光特效不断的美化。

期待,三维的长江更像滚滚长江;建筑物更像建筑物,还可以交互出更漂亮精致的效果。

期待,三维与图表的第一次亲密接触。

更期待,第一个三维大屏系统!

最后,奉上一个短短的截止到2019.1.8号的三维特效gif图:

thanks,my friends and brothers.

                           -----欢迎转载,但保留版权,请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

             如果您觉得本文确实帮助了您,可以微信扫一扫,进行小额的打赏和鼓励,谢谢 ^_^

源文地址:https://www.guoxiongfei.cn/cntech/7598.html