View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002428||Slicer4||Module ModelMaker||public||2012-08-22 11:45||2012-09-20 10:41|
|Target Version||Slicer 4.2.0||Fixed in Version||Slicer 4.2.0|
|Summary||0002428: Model maker creates less models than the number of labels in the input image|
It seems that the first time the Model maker creates models from a labelmap there are no models generated for the last 3 labels.
Win7, 64-bit, nightly release Slicer 4.1.0-2012-08-18
How to reproduce:
*Go to model maker again, click Apply =>All the models are correctly appear
|Tags||No tags attached.|
|related to||0002108||closed||nicole||Crash when deleting a model after deleting its parent hierarchy node|
|related to||0002526||closed||pieper||entering the models module results in crash|
|parent of||0002447||closed||nicole||model maker mixes things up.|
|related to||0002330||closed||nicole||When there is a model in /tmp Model Maker produces that model as output of any execution|
|related to||0002430||closed||finetjul||Models jump around in the MRML tree view when visibility is changed|
|related to||0002096||closed||finetjul||transform node disappears when volume is dropped inside|
|related to||0002482||closed||nicole||Ghost models in the 3D view cannot be deleted|
|related to||0002538||closed||finetjul||slice pipeline causing a crash when restoring scene views with models + slices visible in 3d|
|related to||0002539||closed||finetjul||Update node reference before AddNode to scene|
|related to||0002569||closed||finetjul||GetReferencedSubScene does not work|
If delete the hierarchy in the models module, slicer crashes.
When I didn't delete the temporary files and loaded the .mrml scene file from a fresh start of Slicer, all the models showed up in the 3d view, but in the models module, the first three didn't show up in the Models hierarchy. Digging into the nodes via python, using the mrml id from the Data module, the Models hierarchy had 6 children:
So it's not just the CLI reload, it's something about the generated scene from model maker clashing on load.
svn 20847 fixed the incorrect hierarchy issue
The poly data pointers on the "missing" models' display nodes are incorrect, the display node and the model node should point to the same poly data, but the first missing model has different pointers:
The following makes the first model show up in 3d:
So, my guess is that when the model maker scene is read in, the model display node's reference to the poly data isn't getting re-set when the node id references are being updated to avoid clashes with the model nodes already in the scene.
Further digging, the yellow slice node has it's poly data messed up, on a fresh start they poly data pointers are the same, but after model maker load, they're different:
vtkMRMLSceneImportIDConflictTest is passing, may need to be updated to exercise this behaviour, as the model maker triggers the update by passing in a collection of nodes. Actually, the test just doesn't include poly data, need a new one.
svn 20872 adds a test to show failing behaviour:
In the vtkMRMLSceneImportIDModelHierarchyConflictTest, when the scene is imported from the xml string, the reading of the xml attributes on the model node sets the display node id and that triggers events that lead to the original display node in the scene that is returned on GetNodeByID("vtkMRMLModelDisplayNode1") to have it's poly data set to null.
Old value = (vtkPolyData ) 0x7a8a10
I'm not sure why the MRML Scene is set onto the parser, but more importantly, why is it set to the nodes created by the parser.
Previous changes to the observation of display nodes:
I committed a workaround (revision: 20954) that temporarily sets scene to NULL, kindof as Julien suggested. That fixed the vtkMRMLSceneImportIDModelHierarchyConflictTest test. However the original issue with ModelMaker still remains. I debugged that scenario and found that:
My suspicion is that the intermediate state when two models (slice and MM model) point to the same display node somehow creates problems but I don't know how they manifest.
Loading the model maker results is causing a crash for me now (64 bit linux, debug build). But when I tried again not going through the editor but just loading a label map, it didn't crash. Still not seeing models 1-3 though.
Nicole, could you provide stack trace for the crash? I can revert my change.
In the current design there are two problems that need to be addressed
I (Steve) will take a look too - that way Alex, Nicole, and I can discuss it with Julien when he returns if it hasn't yet been resolved.
I added a new self test that illustrates this issue - you can run it from the Modules->Testing->TestCases->Scene Import menu item and then clicking the Reload and Test button. We make 4 models.
As of revision 20968, If you look in the 3D view and change visibility of Model_4_4 (blue) from the models module you can see that Model_1_1 (green) is coincident with the blue model. This appears to be because multiple model display nodes have the same polydata and model nodes do not have the same polydata as their display nodes.
Note that this test configures the CLI not to delete the intermediate data files. The scene location is printed by the test (In the case of my mac build, the scene below). This scene can be loaded and all four models appear correctly. This indicates something is broken in the scene loading of the CLI.
Here's a sample scene from the model maker (create by the test script):
The scene appears to load correctly in that all the disks appear.
However if you do the following:
Alex and I spent some time debugging this and found that the GetDisplayNode call was triggered in the SliceModelDisplayableManager during scene import. Since the node ids of the displayble node were not yet updated, the polydata of the display nodes was being set to incorrect values.
The scene is no longer being set to nodes in vtkMRMLParser.
Note that now MRML nodes must reimplement vtkMRMLNode::SetSceneReferences()
Tested on Slicer-4.1.0-2012-09-14-win-amd64.exe and it works well. Thanks to all for fixing this!
|2012-08-22 11:45||lassoan||New Issue|
|2012-08-22 11:45||lassoan||Status||new => assigned|
|2012-08-22 11:45||lassoan||Assigned To||=> nicole|
|2012-08-22 11:46||lassoan||Relationship added||related to 0002108|
|2012-08-22 13:41||nicole||Relationship added||related to 0002330|
|2012-08-22 14:01||nicole||Note Added: 0005742|
|2012-08-22 14:01||nicole||Target Version||=> Slicer 4.2.0 - Feature freeze Sept 1st 2012|
|2012-08-22 14:21||nicole||Note Added: 0005744|
|2012-08-23 13:56||nicole||Note Added: 0005768|
|2012-08-24 13:03||nicole||Note Added: 0005778|
|2012-08-24 13:20||nicole||Note Edited: 0005778|
|2012-08-24 13:24||nicole||Note Added: 0005780|
|2012-08-27 07:10||nicole||Note Edited: 0005780|
|2012-08-27 11:26||nicole||Note Added: 0005811|
|2012-08-27 13:16||nicole||Note Added: 0005817|
|2012-08-27 13:20||nicole||Note Edited: 0005817|
|2012-08-28 05:34||finetjul||Note Added: 0005822|
|2012-08-29 08:01||nicole||Note Added: 0005853|
|2012-08-29 13:41||jcfr||Relationship added||related to 0002447|
|2012-08-29 13:42||jcfr||Relationship replaced||parent of 0002447|
|2012-09-02 10:14||finetjul||Relationship added||related to 0002430|
|2012-09-02 10:15||finetjul||Relationship added||related to 0002096|
|2012-09-04 13:23||alexy||Assigned To||nicole => alexy|
|2012-09-07 11:04||alexy||Note Added: 0006009|
|2012-09-07 11:04||alexy||Note Edited: 0006009|
|2012-09-07 12:31||nicole||Note Added: 0006012|
|2012-09-07 12:42||nicole||Note Edited: 0006012|
|2012-09-08 06:04||alexy||Note Added: 0006013|
|2012-09-08 10:01||alexy||Note Added: 0006014|
|2012-09-08 10:01||alexy||Assigned To||alexy => finetjul|
|2012-09-08 12:43||pieper||Note Added: 0006020|
|2012-09-11 04:56||pieper||Note Added: 0006030|
|2012-09-11 05:22||pieper||Note Added: 0006031|
|2012-09-11 08:23||pieper||Note Added: 0006036|
|2012-09-11 13:18||pieper||Note Added: 0006037|
|2012-09-11 13:18||pieper||Status||assigned => resolved|
|2012-09-11 13:18||pieper||Fixed in Version||=> Slicer 4.2.0 - Feature freeze Sept 1st 2012|
|2012-09-11 13:18||pieper||Resolution||open => fixed|
|2012-09-13 02:41||finetjul||Note Added: 0006047|
|2012-09-16 08:11||lassoan||Note Added: 0006100|
|2012-09-16 08:11||lassoan||Status||resolved => closed|
|2012-09-18 12:57||nicole||Relationship added||related to 0002482|
|2012-09-20 10:41||pieper||Relationship added||related to 0002526|
|2012-09-20 11:18||finetjul||Relationship added||related to 0002538|
|2012-09-20 12:37||finetjul||Relationship added||related to 0002539|
|2012-09-26 06:12||finetjul||Relationship added||related to 0002569|
|2012-09-26 06:13||finetjul||Note Edited: 0006047|