Mouse Tracking Sphere-Implementation
From IGSTK
Contents |
Screenshot
Architecture
The demo application has been implemented by creating minimal examples of the following groups of classes
- Views
- Trackers
- Data representation
- Visual Representation
The following UML class diagram illustrates the basic hierarchies used in this application.
The conceptual aspects of these classes are described below.
Views
"Views" abstract the concept of a window on the GUI where a 3D or 2D scene is being displayed. The View class is responsible for user interactions that control the camera (the point of view). This classes are mostly based on VTK components. The combines internally the following elements
- vtkRenderer
- vtkRenderWindow
- vtkRenderWindowInteractor
- vtkCamera
The View is expected to act passively face to the representation classes. This means that the View will not be aware of the existance of the Scene, instead, the visual representation classes that define the scene will connect their vtkActors to the vtkRenderer of the View and in this way be ready for presenting an updated view at the next refresh of the screen.
Trackers
Trackers are classes that will gather information from external hardware devices. The information will in general pertain to position and orientation of surgical instruments as well as markers on the patient.
Visual representation classes
Visual representation classes are the ones that describe the appearance of the object present in the scene. These objects will be surgical instruments, markers, organs and medical images. The representation classes are based on VTK actors that define the modes used for rendering, the colors, opacity, position and orientation of these objects. Visual representation classes hold pointers to the Geometrical representation classes and have Observers to them in order to be aware of any change in their condition. In particular, the Visual representation classes are attentive to the changes in position an orientation of the Geometrical objects that may have been triggered by new information arriving from a Tracker.
Geometrical representation classes
Geometrical representation classes are the ones that describe the Geometry and position of the object present in the scene. These objects will be surgical instruments, markers, organs and medical images. The representation classes are based on ITK Spatial Object internally and adding wrapping code around them with the purpose of restricting the way in which these classes are used.
These Geometrical representation classes act as passive elements with respect to the Trackers, since the Trackers provide the information about position and orientation of these classes. Whenever the position and/or orientation of the Geometrical object chage, the object invokes an IGSTK event with the purpose of informing its Visual representation about the change and making sure that its VTK actors are updated accordingly.
Collaboration between classes
The following UML diagram illustrates the colaboration between multiple instances of viewers, representation objects, spatial objects and the trackers.
From Left to right:
- Multiple instances of viewers will provide windows to look at the scene from different points of view in 2D. Some of those viewers will provide 2D viewes, some others will provide 3D views. It is quite common in image guided surgery applications to provide 3 orthogonal viewes using 2D viewers, and one perspective view using a 3D viewer. In this particular example we illustrate the use of three viewers, two of them are 2D while the third one is 3D.
- A Scene object will consolidate a group of SpatialObjectRepresentation classes. These classes define how the actual SpatialObject will be displayed in a viewer. Each SpatialObject should have a single SpatialObjectRepresentation for each one of the views it appears in. In this example, a NeedleSpatialObject must have three different NeedleSpatialObjectRepresentation classes associated to it. Each one of them, associated to a specific instance of the view.
- The Special Object will be grouped under a GroupSpecialObject instance. This allows to centralize the geometrical information of the scene and prevent duplications of information that may risk to introduce inconsistances due to lack of synchronization or that will force to implement a significant overhead in redundant updates in order to prevent inconsistances.
- The position and orientation of some selected spacial objects may be updated from information provided by trackers. Here we differentiate the Tracker IGSTK object from the actual hardware device. The ITGSTK tracker acts as a proxy for the hardware device. It will pull information regularly from the hardware device by using an internal timer that the application developer can access in order to set a specific rate for pulling data from the hardware tracker. Each time that the hardware tracker is queried, it provides the position an orientation for all the tracked tools that are attached to it. For this reason, our proxy for the tracker includes the abstraction for the Tools. Each tool will be linked to one of the properties of one special object. For example, Tool-1 may be controlling the position of a NeedleSpatialObject, while Tool-2 maybe controlling the position of a guidewire, and Tool-3 may be providing the orientation for a drill.
The proxy tracker class allows the application developer to set specific rates for the update of the position and orientation information. This information is pushed in to the SpatialObjects by using Events. In a typical situation, the update rates for the tools will be lower than the updates from the Hardware device. The hability for setting different rates per tracked tool will make possible to give higher priority and attention to tools that are critical for the intervention, while still following auxiliary tools.
Communication among classes
The following UML sequence diagram illustrates the communications between the components described above
The active component is the MouseTracker, which at every movement of the users will update the positions of the EllipseObject. The EllipseObject is observed by the EllipseObjectRepresentation object. Every time that the position of the EllipseObject is updated by the tracker, the EllipsObject will invoke an IGSTK event and will therefore call the observer on the EllipseObjectRepresentation. At this point the EllipseObjectRepresentation will update its internal VTK actors in order to synchronize its internal representation with the information of the EllipseObject. After that, a periodic refresh of the View object will trigger the rendering of the screen.
