文章版权由作者李晓晖和博客园共有，若转载请于明显处标明出处：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/
如果您觉得本文确实帮助了您，可以微信扫一扫，进行小额的打赏和鼓励，谢谢 ^_^
