3D项目开发流程
3D Dev In Action！
问题&原因
以这次的3D关系图为例，我发现做的时候比较迷茫，缺乏一个流程指引。
如何确认需求？
心里得有个checklist的表格才行，不然很多东西想不到或者会遗漏。这也是经验性的内容，而经验性的内容一定要通过规章制度固化沉淀下来，没有积累光靠感觉是不行的。
可以从这几个方向去考虑：
1、这个功能的目的是什么，用户是谁，想要解决哪些问题？
2、需要展示的具体数据是什么？数据之间的关系是什么/有哪些？
3、用户会怎么玩儿这个功能？宏观与围观视图在功能和定位上的差异？具体有哪几个视角？
4、具体的交互有哪些(旋转、平移、点击、hover)
5、物体(节点、连线、标签等)有哪些不同的状态(正常、异常、高亮、虚化等)和展现形式？
6、有没有动画？
程序结构
试试基于RenderGraph的程序设计？
需要有一个规范的、固定的文件目录结构，知道什么文件放哪里。这样写程序的时候有原则，定位的时候也方便。
缺少空类型的设计
比如Node，没有空类型，就导致每次都要对getNodeById()的返回结果做判断。
Node光靠一个简单的interface定义，明显是不够的；应该将其设计为一个类，有属性有方法，能自我判断。
复盘总结
3D关系可视化复盘总结
需求
没有UI稿的情况下，我就准备开始搞一些UI的内容了(比如文字的高亮样式这种)，幸好被WY叫停。
程序设计
初期没有重视数据结构，搞了很多临时的数据处理操作，导致后面的改动成本大、理解成本高、开发效率低。实际上基于一个好的数据，短短几行就能搞定的功能，我要用N行临时代码才能处理掉。关系可视化已经是有业界公认的、最佳实践的数据结构的，我没必要自己瞎搞。
3D产业链复盘总结
需求
需求方太多，飞哥、海鹏、胡博、天宇，每个人来一点需求，不统一；中间其实有不少做了的功能，最终是废弃掉的
重点和优先级没把握好，一开始就陷入内部模型的细节里面去了，最终演示版根本没演示这些细节
没有落地成文的交互稿和UI稿，很多内容纯靠口头沟通
有部分内容经过沟通后依然没有达成共识的情况下，开发进行了 “特殊处理”，需求的内容应该具备确定性，要遵守流程规范；
需求变动缺乏充分的讨论，某部分内容的变更，都应该从整体需求梳理一遍，确定影响面和逻辑合理性，快速迭代和技术验证工作应该建立在合理的需求之上；
需求的核心关注点从产品范畴脱离，过于强调数据，导致最终成果不符合普通用户的预期；
解决方案
1.前期缺少一个明确的，经过验证的交互流程图（同3）
2.把一些验证类的东西放到了开发侧
3.需求评审，产出能够完整描述需求的产物（文档、交互图、视频等），需要着重描述清楚【用法】和【玩法】，可以尝试用unity之类的工具，加载网上现有的模型和场景，预先通过拖拉拽的方式，明确需求细节（大家都去试一下unity）
4.需求评审的【CheckList】和【错误列表】，如何保证需求评审完的产物是符合逻辑的，正确的，符合预期的（李少杰先列一个初步的）
5.没有一个负责人，大家各持己见，没有收束掉
6.了解游戏领域的工作流程（王渊）
流程
协作
【看下游戏领域现在是如何处理的】游戏领域、智慧城市、工业等
没有明确的资产对接标准，比如模型到底该按照业务进行分组，还是按照材质进行分组、模型命名的规则、模型的大小面数、材质复用的约束、模型的position规则、模型尺寸的单位大小(比如position1=现实中的1m)等等，初期搞的很随意
缺乏给设计师和数据维护人员使用的数据录入工具，没法所见即所得的调试数据和效果，一直到最后还在调试数据
1.视角方面的配置先按现在的工作流走（控制台打印参数，设计师录入表格，开发解析并生成json）
2.HDR按照现在的工作流（在设计师那边部署项目，预览HDR应用效果）
3.基于开源渲染工具做修改，提供替换模型和HDR，以及调试和打印渲染参数的功能（GLTFViewer）（周昌炬）
渲染相关的参数，开放出去可调试的太少，没有用好dat.GUI
程序设计
BUG太多了，特别是动画和状态这两部分，后期有相当大一部分时间，都在改BUG
1.初期做方案评审
没有基于上次成熟的vis-3d项目，从零新搞了一个项目
2.功能拆成单页，并附有完整的文档，通过插件化的方式提供3D处理方面的功能
对基于 Vue 的 three.js 框架了解太少，很多代码实际上都封装在组件内部了，但我们还是重复写了一遍（比如 render 的调用，control.update 调用，camera.update 调用等等），没有体现出使用该框架的优势1.；
3.自己有做功能封装，但是还是存在一些问题，需要额外处理
实际上是沉淀一个框架（王渊）
基建&生态
缺乏一个成熟的业务开发框架
缺乏可信赖的组件，比如描边特效、开箱即用的渲染器配置、动画、成熟的功能函数等，文档也没有(这里会涉及一个明年的基建问题，走组件化路线、工具化路线、还是其他路线？待讨论)
1.需要先有一个插件机制，然后把这些常见的功能都做成插件化可插拔的（postProcessing）
技术点
视觉还原上碰到的问题很多：色调控制、曝光问题、摩尔纹、黑块、半透明物体的深度问题、锯齿（这个似乎是因为 WebGLRenderer 的抗锯齿配置对后处理效果不生效，这个在 postprocessing 工具库的文档中有提到）、软阴影、漫反射地面(至今未完成)；我们是否应该搞个gltfviewer的技术拆解？
初期没有意识到HDR对于视觉是影响最大的，花了不少时间调渲染器的参数
视觉效果上抓不住关键点，大家能感觉效果不行，但是就是不知道该怎么改，只能盲目去试
性能上，从RayCaster改为了GPU拾取，耗费不少时间，特别是调试GPU拾取，我在瞎调，效率极低，不知道先渲染到纹理上打印出来看效果
在基本没有这方面技术积累的情况下，应该直接找一个现成的抄才对，而不是自己一个一个去踩坑
对于gltf/glb模型格式不熟悉，对于WebGLRenderer也不够熟悉
1、模型预处理，基于预览工具，增加一个模型检查功能（周昌炬）
渲染器仅做单模型渲染与模型检查