search

SlicerRt / SlicerRT

Open-source toolkit for radiation therapy research, an extension of 3D Slicer. Features include DICOM-RT import/export, dose volume histogram, dose accumulation, external beam planning (TPS), structure comparison and morphology, isodose line/surface generation, etc.
https://slicerrt.org
127 stars 60 forks source link

Strange behavior of beam model with "Models" module #121

Closed MichaelColonel closed 4 years ago

MichaelColonel commented 4 years ago

While testing MLC data i have found a strange bug:

  1. Load dicom data with RT plan and beam information.
  2. Go to "Models" module.
  3. Click on RTPlan node and beam poly data direction (or orientation) becomes incorrect.

In doesn't matter if MLC information is present or not.

Correct representation BeamPolydataBugBefore

Wrong representation BeamPolydataBugAfter

cpinter commented 4 years ago

Possibly a Modified event is invoked on the item you are clicking, and it triggers an incorrect re-generation of the poly data.

I'd put a breakpoint in the poly data generator function and also the one that calculates the beam transform (IEC logic I think) and then click the item and see where it performs the problematic update. I can take a look at this, but not in the next week for sure. Let me know.

MichaelColonel commented 4 years ago

There is no rush in this task at all!

I just don't know any other way how change beam polydata color. Even the color of a beam have been changed (e.g. white), the color reset to green when modified event is invoked for a beam node.

Anyway i will try to debug myself.

MichaelColonel commented 4 years ago

After some tests i have found out:

  1. Correct representation could be restored by clicking "Edit properties..." action on RTPlanNode. Several GUI elements from EBP module widget invoke vtkMRMLRTBeamNode::BeamTransformModified events that restore beams orientation, basically it is https://github.com/SlicerRt/SlicerRT/blob/4c282faefba6202bbc4c562fe9f634f865034776/ExternalBeamPlanning/qSlicerExternalBeamPlanningModuleWidget.cxx#L516-#L525

  2. I think the problem because RTPlanNode is derived from vtkMRMLNode not vtkMRMLModelNode, but i don't know for sure.

cpinter commented 4 years ago
  1. BeamTransformModified only triggers an update of the parent transform of the beam, so it shouldn't affect the beam model node itself. The other event, BeamGeometryModified is called when the jaws etc (MLC change should trigger it too, not sure if it's been added), and it does recalculate the points of the polydata.
  2. The plan node should not be a subclass of the model node, as the plan has no model. It only references the beams, which have their own models, and that's why those subclass the model node.
MichaelColonel commented 4 years ago

After some experiments i found that only vtkMRMLRTBeamNode::BeamTransformModified event restores correct beam orientation, in any case polydata stays the same.

For MLC the observer has been added to vtkSlicerBeamsModuleLogic. When cell data in MLC position table node is changed the beam polydata will be updated, and it doesn't affect the beam polydata orientation. OnMRMLSceneNodeAdded ProcessMRMLNodesEvents

I thick it's not a bug anymore, because the solution is easy, and this issue could be closed. It was just annoying, when i misclicked, and a scene became a mess.