After years of using VTK, there’s one thing that’s been bothering us and we don’t know how to solve it yet:
We want to have a Scene Graph in VTK that can be shared across multiple renderwindows.
We noticed that it’s possible to create something like this, using a vtkAssembly. However, this assembly cannot be shared across multiple renderwindows. Is there any way we can define 1 scene somewhere and have that shared across renderwindows? As far as I can find, this doesn’t seem possible, which means that we might have to drop VTK when we want to implement this. Can anyone confirm our suspicions on this? Or is there anyone who might know how to use a Scene Graph in VTK?
Thanks for your question. Scene graph are usually addressed at the application level.
Within 3D Slicer (an application for medical imaging built on top of VTK/ITK/Qt/Python/…), we manage objects using a scene graph called the MRML Scene.
Then, if a node representing a volume is expected to be represented in multiple renderwindow, we have the concept of “displayable manager”.
A displayable manager is responsible to create (or cache or delete) the rendering pipeline (actor/mapper/filter/…) for each renderwindow associated with the current layout.
Depending on what you try to do, you may want to look into customizing 3D Slicer. If you have more questions, see https://discourse.slicer.org/.
Thank you very much for your quick response. We’ll have a look at the MRML Scene that’s used in Slicer and see whether we could create our own. We currently already have an application much like Slicer (VTK/Qt/OpenGL) so who knows what we can use. What I’m wondering about: Do you know the reason why you implemented an own Scene Graph? And maybe also why this isn’t part of VTK? And why not use a different framework such as OpenSceneGraph? We’re trying to define a list of pros and cons, and we we would love to hear your arguments and experiences.
@RJP I’ll jump in here and @jcfr can also comment. I haven’t looked at how OpenSceneGraph is implemented and don’t know how it would fit with VTK, but the reasons for implementing MRML at the application level included the fact that we wanted 3D Slicer’s data model to exist independent of the rendering, UI, and 3D widget code.
So our MRML scene implementation has ‘mrml nodes’ (vtkMRMLNode and subclasses) which inherit from vtkObject, but are really just data containers. As Jc mentioned, the displayable managers are responsible for listening to events related to changes in state and mapping those into the vtk rendering (and also listening for widget events and mapping those back to mrml state). All of this is done using the same event structure and widgets as VTK itself, but is just a layer on top.
I’m sure some of the MRML-like functionality could be added to VTK proper, but VTK is already big, so it’s good for the MRML code to exist independently. MRML is freely available to use in other apps if people see fit (there’s a set of VTK libraries that don’t depend on the rest of Slicer.) They inherit the coding style and build conventions of VTK without being part of the same repo. If you use something else, like OpenSceneGraph, presumably you would need to have a lot of adapter code to map between different coding and data representation conventions.
Ah that’s good to know. Thanks for all your help. We’ll have a look at MRML and see how and if we’re going to use it. At least we know now that it’s possible to have a Scene Graph in VTK. Just a small last question (out of curiosity): What does MRML stand for? Anyway, thanks for your help guys!
MRML stands for Medical Reality Markup Language (because it serializes to XML).
MRML has a lot of nice functionality but it may or may not be a great fit for other applications. It’s been build specifically to meet the needs of Slicer.