教程-使用Unity进行可视分析(5)

关于三维可视化视图的系列教程其五。本章主要是对制作流程的一些思考。

Posted by 秦浩凯(Haokai Qin) on 2022-02-12
Estimated Reading Time 5 Minutes
Words 1.6k In Total
Viewed Times

目录

前    言:为什么、以及什么场景下要使用unity进行可视化?
第一章:现有的unity可视化工具包
第二章:自行设计与实现unity可视化视图
第三章:设计与实现一个可视分析系统(上)
第四章:设计与实现一个可视分析系统(下)
第五章:设计与实现一个可视分析系统(技术问题专题)

第四章:设计与实现一个可视化系统(下)

本章主要是对制作流程的一些思考。

可视分析之‘分析’

本节将会简单地介绍‘可视分析’这个概念(不仅仅是“如何使用可视化系统”),包括它在可视化系统的地位,以及如何发挥作用。

可视分析是指如何使用可视化系统,以及通过阅读视图获得的结论。

小结:关于可视分析系统的设计、实现

——工时统计(详细)——

这是我第一次接触unity-hololens-WEB开发,此前并没有相关经验。
我们使用了大概两个月的时间完成这一系统的设计,并参加了ChinaVis 2021。
这个项目我每天贡献约八到十个小时。后期经历了约半个月的突击开发,每天大概贡献12小时以上。(几乎)所有的编码都是我完成的。

大概使用两周的时间确定了分析任务与场景,及使用的视图。我收集了大概15篇相关论文,从而确定了视图,以及能做出的结论。

随后进入实现阶段。
在实现阶段我首先设计了用于AR环境的六个视图;并实现了其中的地理视图、柱状图、平行坐标图、二维流场线图等。
在进行到第五周时,我们修改了原始设计,将其从纯AR系统修改为了现在的跨设备系统。由于人手不足,我裁掉了在平面端难以实现的视图,只保留了四个图。

随后直至最后一周,都在进行编码工作。
最后一周使用四天时间拍摄演示视频、制作说明文档等必要材料。这段时间进行了熬夜战斗。

整个项目中主要的困难在于如何实现各类代码。
实现的部分非常困难,因为可参考的代码不多(或者不能用,github上很多看起来可用但实际不行的代码),不得不用unity手搓可视化视图框架。

其次是演示环节的设计。应该如何讲述可视分析场景的故事?这个问题并没有想清楚。我的选择是照搬某篇论文的演示视频的镜头进行录制。

——可改进的部分——

  1. 从立意而言,实际上这次的挑战赛题目可能更偏重数据分析,以及分析结果(算法结果)的可视化。我们并没有使用太多算法,或没有实现,而是选择了偏重交互的路线。

  2. 从实现而言:
    2.1. 视图数量足够,但是平面部分可能过于简单了;而AR部分未必“好看”;这需要更多经验积累;
    2.2. 极坐标图不是很好的选择,至少最终效果并不好(实际上极坐标图从‘决定要用’到‘调试完成’只用了一个下午,时间太赶了);
    2.3. 算法部分太少。实际上这个题目可以用LSTM进行短期预测,但由于时间问题并没有真正实现;
    2.4. 设备成本太高,而强交互的增强现实可视分析真的有效吗?(这是评委的意见)

  3. 从任务进度规划而言:
    3.1. 由于设计不明确,设计上反复修改的次数太多。实际上就评委意见而言,很多当时纠结的细节(比如是否要使用某视图)完全可以不需要反复考虑。可以认为在这个层级的任务中,论文使用过的视图就足够了;
    3.2. 前期决心不明确;前期还打算兼顾科研进度,投入时间过少;实际上应该在完成科研方面必要文档后就转入这个项目,而不应该拖太久;
    3.3. 前期每天六小时的工作量还是太少。最好的状态可能是68小时,然后留出额外14小时处理科研和其他问题。

  4. 从技术而言:
    4.1. 代码复用做的不是很好;
    4.2. 没有使用设计模式,这本来可以成为一个很好的体验机会;

  5. 性能优化
    5.1 关于图形学的运用:这应该开个专题来讲,但使用的太过浅显(最基本的LOD/遮挡剔除),而且效果不如5.2。
    5.2 实际上减少交互响应组件数量、限制交互时更新的数据量更加有效。当然更好的优化,在当时是想不出来的,只能从特定逻辑上解决。

问题:如何管理团队合作项目?

这是一个非常困难的问题。
至少在我们制作这个系统的过程中,由于我(作者)本人第一次接触可视化工作,难以估计工作量,并没有进行详细的任务分配。这是不合适的。
我们的小组每周进行一次至少一小时的集中讨论,但只安排了一个人写代码。另外有一名同学负责进行数据处理工作。

由于只有一个人进行设计与实现,实际上并没有严格完成时间表,整个系统调试完成多花了半周,使得最终的演示环节没有足够时间进行拍摄,这一点应该注意。

在这里必须要强调的是:

  1. 负责人必须对项目的前因、过程与后果足够清楚,以安排分工;
  2. 分工是可以更改的,但不能不分;
  3. 应该确保所有人都能完成‘必要’的部分,对代码的质量检查也非常重要;

遗憾的是,在制作过程中,我并没有很好地领会负责人的职责。


If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !