(学习笔记,错误难免,请指正;个人劳动,转载请注明出处)
原文档
MITK保留了VTK的渲染机制。本章讲述渲染过程和渲染窗口的核心组成部分。
综述
要将一个数据可视化,需要先把它存储在DataTree里。由程序决定是显示整个还是部分DataTree。具体data item的渲染由对应的mapper完成(参考mapper类)。DataTree里的每一个item都关联着一个mappers列表,每一个mapper保证数据在某个特定的窗口显示。
MITK是本着从多个角度显示数据的思想而设计的。比如一个体数据有3D渲染窗口,同时还有2D渲染窗口展示其中一片数据。一个多边形模型被显示为2D的contour(也就是3D模型与对应2D平面的交集)。这个思想适用于所有数据,因此不管数据类型为什么,都保持了显示的一致性。
RenderWindows指将数据可视化、供用户交互的窗口。实际的渲染过程由Renderers控制,更具体地来说是mitkVtkPropRenderer。mitkVtkPropRenderer继承了BaseRenderer,迭代访问DataTree里的每一个item,然后用对应的mapper渲染。
DataTree里的每一个item都附带有Geometry对象,以描述数据的geometry(也就是bounding box, location, 或spatial conversion hints等集合特征)。
封装VTK的渲染机制
作为一个框架,MITK尽量保留和利用VTK的可视化功能。
像VTK一样,MITK定义Renderers和mappers。这些类并不继承自VTK中类似的类,但集成了他们并具有相似的功能。不像VTK仅关注建立一个连接各组成部分(data, filters, mappers, renderers)的渲染管道的渲染机制,MITK有一个核心人物—-DataTree,它为渲染每一个item提供了方便。从内部来讲,MITK还是使用了VTK的渲染管道,但这对仅仅使用现有渲染功能的程序开发者来说是隐形的。
自MITK 0.8版本开始, vtkMitkRenderProp只代表一个prop 对象。这种方法的好处是所有渲染管理以VTK渲染管道的方式完成,而数据实际如果渲染由MITK决定。比如,MITK Mapper类可能使用VTK的类来渲染(actors,properties, …),又或者在适当的时候又使用OpenGL渲染(比如2D mapper类)。
RenderingManager:所有渲染的管理者
从高层看,MITK所有的渲染都由RenderingManager管理和监督。它的主要任务是提供一个处于中心地位的实例,让程序的任何一份部分都能请求重绘某个指定的RenderWindow。因此,可能有多个语句同时发出请求,但只能调用重绘一次,而不会造成不必要的反复重绘。
另一个任务是监管正在进行的渲染活动。对于大数据,高质量的渲染可能非常耗时,无法满足流畅的用户交互。为避免这些问题,level-of-detail rendering和abort-mechanism被引入,并由RenderingManager 管理,以便帧率和反应时间能满足流畅交互。值得注意的是,这些特征仅仅是提出了解决办法,具体的功能目前正在开发中。
渲染过程还可通过让DataTree自动检测数据变化并要求数据重绘来进一步简化。这种机制的基础已经存在,但许多情况下,这种请求还得由导致重绘的实体来发出。
相关的类: