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

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