Menu
▾
▴
#33 Fundamental Bug with "ModelID"
Second, when I create models with the ModelMaker or
TetraMesh module, I get errors in the Measure module.
I tracked the error and discovered the following problem:
When ModelHierachies were added to the slicer, they
were added as something special to models. That is,
there are now exceptions all over Base/tcl/tcl-main/*
that are peculiar to models. In this case, vtkModelNode
now have something called "ModelID". It exists so that
you can give a particular ModelID to a model and be
able to reference it in the MRML file. (Note that
ModelID is different from the ID of the MrmlModelNode).
The idea of having a "Model ID" would be fine as long
as the exceptions were hidden away in tcl-main where
most people don't need to look. However, I found a
problem: the correct way to add a Model, Volume,
TetraMesh, etc. to the slicer is to do the following:
set n [MainMrmlAddNode Model]
and then fill in the data for the MrmlNode. This works
for everything. That is, if you call MainMrmlAddNode,
you are guaranteed to be able to add data to the Mrml
Tree in a consistent way. But, not anymore. For models,
you have to set the model ID, something like:
set n [MainMrmlAddNode Model]
$n SetModelID "M[$n GetID]
and then fill in the data if you want. Of course,
neither TetraMesh or ModelMaker do this.
Now, I could just fix these two modules. However, I
find this idea
to be horrible because:
1) Models are now different from all other MrmlNodes.
2) The API is effectively broken, because it is up
to the
programmer to set this variable correctly.
3) I'm not convinced that the above code is correct.
The first 2 bother me a lot. It is OK for the core of
the slicer
to have exceptions for different models. It is not OK
for the average
programmer to have to know about those exceptions.
It is (3) that bothers me most. Consider a MRML file
with Model ID's set in the MRML file. Let's say it sets
the Model id to "M3", even though the ID of the
MrmlModelNode might be 1. Well, after we create 2
models, the ID will be 3, and we will create a ModelID
of "M3" which already exists! In other words, under the
current code, it is easy to create non-unique
ModelID's. This would defeat the point of having them.
In conclusion, as far as I can tell, the
implementation of ModelID in the slicer is very flawed.
Beware. As for the bugs I have found due to this
problem, of which I have only reported one, I recommend
they remain until we decide how to re-write the model
heirarchy part of the slicer.
-- Samson
_