REFAC: ViewerVTK, RenderingVTK as Separate Libraries
Doesn't introduce any new code. This splits off the VTK rendering specific classes into their own libraries. This:
- Decreases the amount of code you need to link to. Examples that don't use VTKViewer, need not include or link to it.
- More libraries can build in parallel (give and take based on library size, admittedly some are small here.).
- Sets it up to be more modular.
- A hard constraint between classes is made, nobody can do silly things like pass the SimulationManager into the VTKViewer which would create a circular dependence.
- It also makes it more extensible for other Viewer's or rendering backends. Not the intention behind this MR but good.
- If these are put on toggle one can build without any VTK rendering dependencies. (note: They are still linked too as we use ${VTK_LIBRARIES})
SimulationManager split into:
- SimulationManager
- ViewerCore
- ViewerVTK
Rendering split into:
- RenderingCore
- RenderingVTK
One change was required:
- KeyboardSceneControl was utilizing VTKViewer. This dependence was bad and needed to be split. VTKViewer & base Viewer were refactored with "info levels" to deal with this which allows a Viewer to define their own amount of info levels and toggle through them. VTKViewer has 3 now, 0 which displays nothing, 1 which displays the fps counter, and 2 which displays the fps counter and performance graph. This is also nice as the graph display was slow sometimes (created a sort of schrodingers cat situation). Now the KeyboardSceneControl can toggle through levels without needing any VTK specifics.
Tests:
- The tests in imstk have differing linkage in some cases to provide viewing capabilities. For instance RenderingTests target doesn't only link to Rendering for unit testing. It also links to SimulationManager for viewing capabilities. So these were changed.
- RenderingTests now only links to VTKViewer. Not SimulationManager.
- SimulationManagerTests also links to VTKViewer.