Yes, model intersections are turned off on purpose for performance (decided at the last slicer4 tcon). Isaiah is working on a replacement.

Committed, please let me know any issues.

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=18702

Tested using Win32 binary build downloaded here: http://slicer.cdash.org/viewFiles.php?buildid=4838

Screenshot attached: no slice intersections with model on any of the slices.

Error messages in the log:

ERROR: In ....\VTK\Rendering\vtkOpenGLPolyDataMapper2D.cxx, line 69
vtkOpenGLPolyDataMapper2D (1FFA5110): No input!

ERROR: In ....\VTK\Rendering\vtkOpenGLPolyDataMapper2D.cxx, line 69
vtkOpenGLPolyDataMapper2D (200E69A8): No input!

ERROR: In ....\VTK\Rendering\vtkOpenGLPolyDataMapper2D.cxx, line 69
vtkOpenGLPolyDataMapper2D (1FFE32C8): No input!

ERROR: In ....\VTK\Rendering\vtkOpenGLPolyDataMapper2D.cxx, line 69
vtkOpenGLPolyDataMapper2D (1FFA5110): No input!

ERROR: In ....\VTK\Rendering\vtkOpenGLPolyDataMapper2D.cxx, line 69
vtkOpenGLPolyDataMapper2D (1FFA5110): No input!

ERROR: In ....\VTK\Rendering\vtkOpenGLPolyDataMapper2D.cxx, line 69
vtkOpenGLPolyDataMapper2D (1FFA5110): No input!

I guess the scene notifications must work differently on scene import, which is what the modelmaker does. I'll change it to rebuild from MRML in such case. Maybe on NodeAdded, it should be a pretty small performance hit most of the time. except when you have 200 models loaded eg atlas.

Resolved by Nicole's commit for 0001551

The intersections don't seem to update when the model is moved - here are two cases:

1) turn on slice intersections from the crosshair tool bar - they show up in the right place initially, but do not update in response to scroll/pan/zoom of the slices.

2) Put a model or fiber bundle in a transform and it updates in the 3D view but not in the slice intersection.

I checked, and this is still an unresolved issue.

The intersection updates to the correct one only if the slice slider is moved.

In today's nightly build (Slicer 4.1.0-rc1-2012-03-16) the problem is still unresolved.

How to reproduce:

Run this script in the Slicer python console:

sphere = vtk.vtkSphereSource()
sphere.SetCenter( 0,0,0 )
sphere.SetRadius( 50 )
sphere.GetOutput().Update()
displayNode = slicer.vtkMRMLModelDisplayNode()
displayNode = slicer.mrmlScene.AddNode(displayNode)
displayNode.SetModifiedSinceRead(1)
displayNode.SliceIntersectionVisibilityOn()
displayNode.VisibilityOn()
displayNode.SetBackfaceCulling(0)
modelNode = slicer.vtkMRMLModelNode()
modelNode=slicer.mrmlScene.AddNode(modelNode)
modelNode.SetName("modelInteresectionTest")
modelNode.SetAndObservePolyData(sphere.GetOutput())
modelNode.SetModifiedSinceRead(1)
modelNode.SetAndObserveDisplayNodeID(displayNode.GetID())
modelNode.SetHideFromEditors(0)
modelNode.SetSelectable(1)

Show a slice => the slice intersection doesn't appear - ERROR!

Save the model, load the model from file, enable slice intersection => the slice intersection appears - so the model was correct.

Tested with Slicer 4.1 and slice intersections appear correctly.

The only problem is that there is a a very specific order that has to be followed, e.g.,
modelNode->SetAndObserveDisplayNodeID(displayNode->GetID());
must be called before
modelNode->SetAndObservePolyData(roiPoly);
If SetAndObserverPolyData is called first then the slice intersections do not appear.

So, there are still some issues with the update mechanism (notification about changes not always propagated through the entire pipeline), but at least there is now a solution for the problem.

On the mac the intersections do not appear correctly, as of 4-16

Performed more testing with Slicer 4.1 on Windows and the problem still exists in when Slicer is build in debug mode.

Isaiah, you've provided a work-in-progress solution a few weeks ago. What is the status of that fix? Do you need help in code review, testing, ...?

On my Mac build:

Red viewer shows two Slice Intersections.
Yellow viewer shows one Slice Intersection.
Green viewer shows zero Slice Intersections.

Using the Slice scroller, Slice Intersections do not update UNLESS the Slice is visible in the 3D view. (A configure event will also cause the intersections to update to reflect the current slice positions.)

Working on a patch where:

I reordered the calls in SliceLogic::UpdateSliceNodes() so that CreateSliceModel() is called after UpdateSliceNode() and UpdateSliceCompositeNode().

I changed CreateSliceModel() to use the SliceNode->GetLayoutColor().

These changes make it so the slice intersections are colored automatically, including the CompareViews.

Added some debugging messages. These illustrate a call stack where when Slicer is starting

ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode2)
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_1, vtkMRMLModelDisplayNode2
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode3)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode3)
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_2, vtkMRMLModelDisplayNode3
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_2, vtkMRMLModelDisplayNode3

which illustrates that only two unique display nodes are processed by ModelSliceDisplayableManager::OnMRMLSceneNodeAddedEvent(). Should be three unique display nodes.

Also, if you close the scene. The call stacks are different

ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode1)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode1)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode1)
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay, vtkMRMLModelDisplayNode1
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay, vtkMRMLModelDisplayNode1
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay, vtkMRMLModelDisplayNode1
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode2)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode2)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode2)
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_1, vtkMRMLModelDisplayNode2
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_1, vtkMRMLModelDisplayNode2
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_1, vtkMRMLModelDisplayNode2
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode3)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode3)
ModelSliceDisplayableManager::OnMRMLSceneNodeAdded(vtkMRMLModelDisplayNode3)
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_2, vtkMRMLModelDisplayNode3
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_2, vtkMRMLModelDisplayNode3
ModelSliceDisplayableManager::UpdateDisplayNodeRefs()
Delayed display node: ModelDisplay_2, vtkMRMLModelDisplayNode3

where all 3 display nodes are processed. After closing the scene, the slice intersections work better. The appear in all the Slice Viewers. But they are not colored and they still need to have the Slice plane visible in order to update their position in the other viewers.

I am concerned with the trace through the code and how the STL containers are managed. There are cases where a container is being iterated over and function calls on each element can cause other functions which may be trying to modify the container.

We need to be careful with STL because certain operations on a container can invalidate an iterator on that container. Classic example is adding a element to a vector while iterating over the vector. Maps and sets are more robust to edits while being iterated over.

Isaiah sent me a rework of the code for Slice Intersections. Uncertain as to whether it addresses all the issues. But it appeared to fix some of the issues I was observing. I changed how the colors are assigned. There is an issue that if more compare views are created, you need to toggle the Slice Intersections on and off. Probably need to tie into an event in the DisplayableManager.

I have a branch on github with Isaiah's modifications and my changes.

https://github.com/millerjv/Slicer4/tree/IsaiahsSliceIntersections

resolved in r20455

Seems to work, thanks!

Is it possible to make the model intersection lines thicker, or have thickness user-controllable?

Hi Andrey, yes, the old tcl code used SetLineWidth=3 on the actor. I like this for the slice-position lines but I think it's really ugly even at 2 for general models.

This could be generalized for user-selection by making a property on the DisplayNode, ie "SliceIntersectionThickness", which could then be set appropriately thick by slicelogic for the slice models, and default to something thin for other models. I don't want to touch the core nodes so i'll open a feature request for this. After such option is available then it will take 1 line each in the displayable manager and slicelogic to include.

Dear issue reporter,

Good news :) Slicer developers SOLVED the problem you reported - YOU now need to VERIFY and CLOSE this issue.

I still see two issues:

1) when the model is generated in the scene (from Editor or from python console), the outlines in slice intersection do not show up. To reproduce, see Andras' script in this comment: http://www.na-mic.org/Bug/view.php?id=1536#c3885. See screenshot attached tested with Jul 25 nightly.

2) if I load a model with "Add data", the intersection shows up, but slice interactions are very slow (tested with MR Head and threshold-based model).

Tested on Tested on Slicer-4.1.0-2012-09-03-win-amd64.exe and it still does not work (the slice intersection does not appear if the script above (0003885) is executed).

If the following workaround is used then the intersection can be forced to appear, but it's not acceptable in the long term:

1. Call slicer.mrmlScene.InvokeEvent(slicer.mrmlScene.StartBatchProcessEvent) / slicer.mrmlScene.InvokeEvent(slicer.mrmlScene.EndBatchProcessEvent) before/after the script (after this the intersection still does not appear)
2. Move the slice selector slider (after this the intersection appears)

I tried today. slice intersections from a model works for me. Slice intersections from the cross hair toolbar: They display properly, but when I use shift plus mouse movement in the slice viewer to change the slice position, it crashes slicer.

I can confirm the crash reported by Ron. Very easy to replicate using his instructions.

Leads to the stack trace below.

Thread 1, Queue : com.apple.main-thread
#0 0x00000001044dfa1c in vtkIdList::GetNumberOfIds() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Common/vtkIdList.h:38
0000001 0x0000000115997a0e in vtkMergePoints::InsertUniquePoint(double const, long long&) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkMergePoints.cxx:149
0000002 0x0000000115a2a75f in vtkQuad::Contour(double, vtkDataArray, vtkIncrementalPointLocator, vtkCellArray, vtkCellArray, vtkCellArray, vtkPointData, vtkPointData, vtkCellData, long long, vtkCellData) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkQuad.cxx:474
0000003 0x000000011583997b in vtkGenericCell::Contour(double, vtkDataArray, vtkIncrementalPointLocator, vtkCellArray, vtkCellArray, vtkCellArray, vtkPointData, vtkPointData, vtkCellData, long long, vtkCellData) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkGenericCell.cxx:186
0000004 0x00000001135b92b5 in vtkCutter::DataSetCutter(vtkDataSet, vtkPolyData) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Graphics/vtkCutter.cxx:601
0000005 0x00000001135b6513 in vtkCutter::RequestData(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Graphics/vtkCutter.cxx:378
0000006 0x00000001159f2b0a in vtkPolyDataAlgorithm::ProcessRequest(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkPolyDataAlgorithm.cxx:91
0000007 0x00000001135b9f89 in vtkCutter::ProcessRequest(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Graphics/vtkCutter.cxx:1121
0000008 0x0000000115828174 in vtkExecutive::CallAlgorithm(vtkInformation, int, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkExecutive.cxx:747
0000009 0x0000000115808fda in vtkDemandDrivenPipeline::ExecuteData(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkDemandDrivenPipeline.cxx:506
0000010 0x000000011580828b in vtkDemandDrivenPipeline::ProcessRequest(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkDemandDrivenPipeline.cxx:279
0000011 0x0000000115a94242 in vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkStreamingDemandDrivenPipeline.cxx:276
0000012 0x0000000115827c57 in vtkExecutive::ForwardUpstream(vtkInformation) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkExecutive.cxx:646
0000013 0x00000001158081e1 in vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkDemandDrivenPipeline.cxx:265
0000014 0x0000000115a94242 in vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation, vtkInformationVector, vtkInformationVector) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkStreamingDemandDrivenPipeline.cxx:276
0000015 0x0000000115808d03 in vtkDemandDrivenPipeline::UpdateData(int) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkDemandDrivenPipeline.cxx:449
0000016 0x0000000115a94510 in vtkStreamingDemandDrivenPipeline::Update(int) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkStreamingDemandDrivenPipeline.cxx:326
0000017 0x00000001157edf0d in vtkDataObject::Update() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkDataObject.cxx:1030
0000018 0x000000010ad3d562 in vtkOpenGLPolyDataMapper2D::RenderOverlay(vtkViewport, vtkActor2D) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkOpenGLPolyDataMapper2D.cxx:74
0000019 0x0000000115757179 in vtkActor2D::RenderOverlay(vtkViewport) at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Filtering/vtkActor2D.cxx:103
0000020 0x000000010abf6d77 in vtkRenderer::UpdateGeometry() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRenderer.cxx:660
0000021 0x000000010ad4be45 in vtkOpenGLRenderer::DeviceRender() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkOpenGLRenderer.cxx:247
0000022 0x000000010abf5d45 in vtkRenderer::Render() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRenderer.cxx:345
0000023 0x000000010abf3b3b in vtkRendererCollection::Render() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRendererCollection.cxx:51
0000024 0x000000010ac107a8 in vtkRenderWindow::DoStereoRender() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRenderWindow.cxx:723
0000025 0x000000010ac106aa in vtkRenderWindow::DoFDRender() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRenderWindow.cxx:692
0000026 0x000000010ac1009e in vtkRenderWindow::DoAARender() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRenderWindow.cxx:579
0000027 0x000000010ac0f65e in vtkRenderWindow::Render() at /Users/pieper/slicer4/latest/Slicer-superbuild/VTK/Rendering/vtkRenderWindow.cxx:392
0000028 0x0000000101b28cde in ctkVTKAbstractView::forceRender() at /Users/pieper/slicer4/latest/Slicer-superbuild/CTK/Libs/Visualization/VTK/Widgets/ctkVTKAbstractView.cpp:226
0000029 0x0000000101b4c915 in ctkVTKAbstractView::qt_static_metacall(QObject*, QMetaObject::Call, int, void) at /Users/pieper/slicer4/latest/Slicer-superbuild/CTK-build/CTK-build/Libs/Visualization/VTK/Widgets/moc_ctkVTKAbstractView.cxx:90
0000030 0x000000010c1f8851 in QMetaObject::activate(QObject, QMetaObject const, int, void*) ()
0000031 0x000000010c1f78d9 in QObject::event(QEvent) ()
0000032 0x000000010b4f09a8 in QApplicationPrivate::notify_helper(QObject, QEvent) ()
0000033 0x000000010b4f0c29 in QApplication::notify(QObject, QEvent) ()
0000034 0x000000010c1e3a26 in QCoreApplication::notifyInternal(QObject, QEvent) ()
0000035 0x000000010b4f013a in qt_sendSpontaneousEvent(QObject, QEvent) ()
0000036 0x000000010b4ab041 in QEventDispatcherMacPrivate::activateTimer(CFRunLoopTimer, void) ()
0000037 0x00007fff8689ada4 in CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION ()
0000038 0x00007fff8689a8bd in CFRunLoopDoTimer ()
0000039 0x00007fff86880099 in __CFRunLoopRun ()
0000040 0x00007fff8687f6b2 in CFRunLoopRunSpecific ()
0000041 0x00007fff8329b0a4 in RunCurrentEventLoopInMode ()
0000042 0x00007fff8329ae42 in ReceiveNextEventCommon ()
0000043 0x00007fff8329acd3 in BlockUntilNextEventMatchingListInMode ()
0000044 0x00007fff841d3613 in _DPSNextEvent ()
0000045 0x00007fff841d2ed2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
0000046 0x00007fff841ca283 in -[NSApplication run] ()
0000047 0x000000010b4ac5b0 in QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
0000048 0x000000010c1e0e88 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
0000049 0x000000010c1e415b in QCoreApplication::exec() ()
0000050 0x00000001006910aa in SlicerAppMain at /Users/pieper/slicer4/latest/Slicer/Applications/SlicerApp/Main.cxx:365
0000051 0x000000010068ffe2 in main at /Users/pieper/slicer4/latest/Slicer/Applications/SlicerApp/Main.cxx:397
0000052 0x00007fff863977e1 in start ()

Hi Isaiah - I showed this to Alex and he said he could look at it if you don't have time or run out of options.

-Steve

Added vtkPolyData->Modified() as a workaround for crash in vtkCutter in order to update bounds of the locator.
revision: 21148

The slice intersections of the added model nodes do not appear, and the only thing that makes them appear is to show/hide a model hierarchy.

I used the code Andras wrote in the comment 0003885.

Can someone please take a look at it? Thank you!

I found that the difference was made by calling
this->mrmlScene()->StartState(vtkMRMLScene::BatchProcessState);
and the corresponding EndState in qMRMLTreeView::toggleVisibility.

Still, it would be nice if I wouldn't have to call it explicitly.

To clarify:

• The code using which the intersection doesn't appear:
  sphere = vtk.vtkSphereSource()
  sphere.SetCenter( 0,0,0 )
  sphere.SetRadius( 50 )
  displayNode = slicer.vtkMRMLModelDisplayNode()
  displayNode = slicer.mrmlScene.AddNode(displayNode)
  displayNode.SliceIntersectionVisibilityOn()
  modelNode = slicer.vtkMRMLModelNode()
  modelNode=slicer.mrmlScene.AddNode(modelNode)
  modelNode.SetName("modelInteresectionTest")
  modelNode.SetAndObservePolyData(sphere.GetOutput())
  modelNode.SetAndObserveDisplayNodeID(displayNode.GetID())

• The code using which it appears:
  slicer.mrmlScene.StartState(slicer.vtkMRMLScene.BatchProcessState)
  sphere = vtk.vtkSphereSource()
  sphere.SetCenter( 80,0,0 )
  sphere.SetRadius( 50 )
  displayNode = slicer.vtkMRMLModelDisplayNode()
  displayNode = slicer.mrmlScene.AddNode(displayNode)
  displayNode.SliceIntersectionVisibilityOn()
  modelNode = slicer.vtkMRMLModelNode()
  modelNode=slicer.mrmlScene.AddNode(modelNode)
  modelNode.SetName("modelInteresectionTest")
  modelNode.SetAndObservePolyData(sphere.GetOutput())
  modelNode.SetAndObserveDisplayNodeID(displayNode.GetID())
  slicer.mrmlScene.EndState(slicer.vtkMRMLScene.BatchProcessState)

I tested it on revisions 21301 (Nov 1) and 21321 (Nov 7).

Adding models in GUI and enabling slice intersection seems to work ok.
Fixed the python test: request renderer even if it's in the scene batch process.

http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21412

Would it make more send to move the call to:

this->SetUpdateFromMRMLRequested(1);

after

// Escape if the scene a scene is being closed, imported or connected
if (this->GetMRMLScene()->IsBatchProcessing())
{
return;
}

this->AddDisplayableNode(vtkMRMLDisplayableNode::SafeDownCast(node));

I would like to make sure the root cause of the issue is fixed and not as a side effect of modified event on the displayable manager ...

Jc, no, your suggestion does not make sense to me. When node is added I want to request update from mrml whether in batch mode or not. This is same logic as in vtkMRMLModelDisplayableManager::OnMRMLSceneNodeAdded which you made originally I believe.

Hi Alex,

For your subsequent commit, it would be great to write down what motivates a given change. In this case, you could mention you inspired from what was done in vtkMRMLModelDisplayableManager and then it appear to solve the problem.

All of that said, I still didn't understand the root cause of the change. Indeed, the two displayable managers are different.

Within vtkMRMLModelDisplayableManager at the end of the batch processing the event EndBatchProcessingEvent is invoked. Then the function "UpdateFromMRMLScene" is called
See https://github.com/Slicer/Slicer/blob/master/Libs/MRML/Logic/vtkMRMLAbstractLogic.cxx#L434-437

Considering that the function "UpdateFromMRMLScene" is overwritten in "vtkMRMLModelDisplayableManager" so that RequestRender is called, it all makes sens.
See https://github.com/Slicer/Slicer/blob/master/Libs/MRML/DisplayableManager/vtkMRMLModelDisplayableManager.cxx#L548-556

In case of the vtkMRMLModelSliceDisplayableManager, the function UpdateFromMRMLScene is not overwritten .. and i didn't understand what was triggering the rendering.

// ------
I then asked J2 to have a look since he originally created the vtkMRMLModelSliceDisplayableManager, and you will find below his analysis:

Here is what happens:

this->SetUpdateFromMRMLRequested(1);

// Escape if the scene a scene is being closed, imported or connected
if (this->GetMRMLScene()->IsBatchProcessing())
{
return;
}

this->AddDisplayableNode(vtkMRMLDisplayableNode::SafeDownCast(node));
//this->RequestRender(); which consists of the following:

// Content of RequestRender

if (this->Internal->UpdateFromMRMLRequested)
{
//this->UpdateFromMRML(); which consists of the following:

// Content of UpdateFromMRML
654 this->SetUpdateFromMRMLRequested(0);
655 vtkMRMLScene scene = this->GetMRMLScene();
656 if (!scene)
657 {
658 vtkDebugMacro( "vtkMRMLModelSliceDisplayableManager->UpdateFromMRML: Scene is not set.")
659 return;
660 }
661 this->Internal->ClearDisplayableNodes();
662
663 vtkMRMLDisplayableNode mNode = NULL;
664 std::vector<vtkMRMLNode *> mNodes;
665 int nnodes = scene ? scene->GetNodesByClass("vtkMRMLDisplayableNode", mNodes) : 0;
666 for (int i=0; i<nnodes; i++)
667 {
668 mNode = vtkMRMLDisplayableNode::SafeDownCast(mNodes[i]);
669 if (mNode)
670 {
671 this->AddDisplayableNode(mNode);
672 }
673 }
674 this->RequestRender();
// END of UpdateFromMRML
}
this->InvokeEvent(vtkCommand::UpdateEvent);
if (this->Internal->DisplayableManagerGroup)
{
this->Internal->DisplayableManagerGroup->RequestRender();
}
// END of RequestRender

So it means that this->UpdateFromMRML() is doing something that OnMRMLNodeAdded is not doing. Could it be the check on the node type ?
Or maybe it's because OnMRMLNodeAdded is called before the model node has a display node (therefore the display node is not added). And then when the display node is added, it is not caught by the displayable manager.

Anyway, I think I solved that issue here: https://github.com/finetjul/Slicer/commit/522471e0d006dde98a852445e9308bd4834a8c5f
I'm quite confident that it will solve the issue Alex is trying to fix (without the performance overhead).

Good catch !

// ---------------------

He also mentioned that in OnMRMLSceneNodeAdded, the following code should be changed:

564 if ( !node->IsA("vtkMRMLModelNode") )
565 {
566 return;
567 }

into

if ( !this->Internal->UseDisplayableNode(node) )
{
return;
}

See https://github.com/Slicer/Slicer/blob/master/Libs/MRML/DisplayableManager/vtkMRMLModelSliceDisplayableManager.cxx#L564-567

// ------------------

Alex> Please, review J2 patch and suggestion and integrate :)
Let me know if you have any questions.

Looking at the problem with a fresh eye, I will report below my observations:

1) The patch proposed by Julien is indeed not for "vtkMRMLModelDisplayableManager" or "vtkMRMLModelSliceDisplayableManager" but for "vtkMRMLVolumeGlyphSliceDisplayableManager".

2) The patch you proposed will impact performance. Everything will be cleared and recreated each time a node is added.

3) The work Julien did for "vtkMRMLVolumeGlyphSliceDisplayableManager" should serve as a basis for both the Slice Model displayable manager and the Model Displayable Manager. See https://github.com/finetjul/Slicer/compare/b3a33043b43fcf9b95d34d0a6f4eae305de17445...2374-glyph-slice-display-node

4) I created other issues to illustrate the fact the displayable managers should be refactored. See 0002766 and 0002769

JC, sorry to say but your comments still do not make sense to me.

• Why are you talking about vtkMRMLModelDisplayableManager when I made changes to vtkMRMLModelSliceDisplayableManager
• The code in your git link is identical to my change.
• There is no performance impact from my change. All I changed is moved
  SetUpdateFromMRMLRequested(1) outside of the return in case of batch processing. It still going to return in that case.

Why you keep changing the status from fixed? The functionality works and the code is checked in.

I update the note 7276 to clarify.

We should probably discuss it during next hangout with Julien :)

Ps: I changed the status ones from Resolved to Feedback, and an other time to "assigned. Now there is two new issues to track the fact the Model and Slice Model displayable manager should be re-factored. This issue can be closed.

@alexy:
The functionality does not work. I tried the two pieces of code I added here (0007110), and it works the same way when I reported the problem. The batch processing is still needed for the model to appear in the slice viewers.

Yes, it seems to be broken again. It was working few days ago.

Given the current state:

• The associated commit won't be backported to 4.2
• Commit r21412 will be reverted from trunk.

@Alex: You should consider adding a cpp unit test similar to the python code of Csaba.

Fixed showing of slice intersections, made it more efficient. Full vtkMRMLModelSliceDisplayableManager::UpdateFromMRML() is only called when batch processing is done.

svn at revision: 21461

Model/slice intersections visible on 2d slice do not show up in the slice in 3d view (see screenshot).

Regarding Andrey's comment 7596, that makes sense - the overlay is done as a vtkActor2D poly line in the slice renderer so it's not expected to show up in the 3D view. If this is desired or required or expected, we should open a child issue as a feature request (this issue is already pretty long!).

Steve, I agree. But I cannot close the bug because it has unresolved children.

The core issue is resolved, but some related issues are still outstanding.