Scene Graph之我见--- 1. 为什么用Scene Graph

　　当然，决定下在可视化项目中使用Scene Graph的人并不是我。我只是进行相关的survey，design，和implementation罢了。

 

　　1。为什么使用Scene Graph。

　　如果有幸拜读过Scene Graph的创始人写的那篇paper，应该不会认为Scene Graph能够给我们的工作带来多大的革新。甚至，说的彻底一点，他无非就是提供数据结构，真正的算法，策略，统统都是要我们自己一行一行得去敲出来的。起码我在刚刚开始研究的时候不觉得它有什么好，就是一棵树罢了。

　　但是，当上头的需求压下来的时候，一切都变了。

　　BoundingBox, Intersect, Pick, Multi Window Rendering, 一个个似乎都在Scene Graph的结构下水到渠成的完成了，我甚至只需要简单的做个DLL，拿给测试，测试跑一遍，就交差了。原先一个礼拜的活，现在只需要一天。

　　废话说了一堆。。。总结下Scene Graph的优势。

　　首先，有一个概念必须要牢记，这是一个每每我再跟别人聊scene graph的时候，别人问得最多的问题。

　　Scene Graph解决的问题并不只有它才能解决，它只是给出了一个解决许多问题的工具。你不可能从别人的现成的库中找到你想要得代码，因为那都是为他们的客户解决他们的问题的特例。

 

　　a. Extensibility

　　松散的树形结构可以进行任意的配置，就工程角度来说，理论上可以满足客户需求的任意变更。今天你们客户说，这个CT上面的刻度尺，我想它应该是可以被移动的。明天他又说，sorry，我问过医生了，他觉得动不动都无所谓。改天又说，我想把这根刻度线拉长，绑在那根骨头上，我想我骨头运动时，我能实时计算出位移量。用了Scene graph，我们就可以轻松得告诉他，小case。

　　每个节点是可以在不同的层次上扩展的，可以指定某一个节点拥有特定的call back，也可以把整个节点替换掉。

　　但是缺点也是显然的，配置起来太麻烦。我需要知道每种节点能干什么，我需要去查user manual。

 

　　好在，我们的客户不是最终的医生，我们的客户是develop。

 

　　b. rendering

　　我通常把Scene graph看成是一个在数据流问题中规整数据的东西，数据流是指从数据获取，数据处理，到数据显示的所有，这三块中，最复杂也最恶心的当属数据显示。因此，大多数的人都把scene graph用在了rendering上。从哲学意义上讲，我可以把整个数据流都塞到scene graph里面，针对不同的具体问题，设置不同的树/列表，并做好相应的map工作。可惜的是，我现在接不到上述的需求，所以，我只能把他用在我的rendering里面。

　　不管是2D显示还是3D场景，良好的图元数据之间的规整关系可以有助于显示逻辑的设计，更有助于查找和遍历。

　　在我的理解范围内，rendering只是scene graph的附加品罢了。

 

　　c. Action

　　我把scene graph的行为认为是一种composite模式的体现，所以，就设计模式上来讲，没有任何新颖之处。但通常我们会发现一个节点的action会有如下的形式：

　　void Traverse(NodeVisitor* visitor);

　　显然的，composite跟Visitor结合起来了。更多的情况是composite + visitor + bridge，这样，scene graph的action就是三种行为型模式的组合了。

　　composite，可以高效的完成遍历工作，因此我们可以完成scene graph的遍历，并按我们的需求完成特定的工作。

　　visitor，可以使用特定的visitor，指定某个结点完成特定的功能，这样，筛选工作就能顺利的完成了，绘制前的场景筛选和搜索都可以借由特定的visitor完成。

　　bridge，接口与实现分离，不用多说。

 

　　下一篇，灵活的Scene Graph，会奉上我design的过程，和改进 :)