Page MenuHomePhabricator

Nodes with equal layer value and "fixed layer" property = true are not loaded during reading of project files.
Closed, WontfixPublic


we just found a bug in mitkSceneReaderV1::LoadScene(...).

To reproduce:
Create a scene with two (2) or more data nodes with the same parent and the following properties:
"fixed layer" = true
"layer" = 100 (above 10, so not set in Property plugin)

Then store as .mitk project.

When reading in the project mitkSceneReaderV1 will add the apropriate number of entries into local variable "DataNodes" but when building up member variable m_OrderedNodePairs the amount of entries will differ. The reason is that the information about the sourceUID of each node is inserted into this list by the key "layer" and as this layer is not distinct, there will be a double entry for the layer number (->example 100). ->m_OrderedNodePairs contains at [0] 100 on pair first (layer) and on second a list of with entries containing the same OBJECT_<timestamp> value.

The effect is that in the console the warning: "Encountered node that is not part of a directed graph structure. Will be added to DataStorage without parents" with following errors stating that the reading process caused errors...

In the DataManager the second data node of the pair of equal properties (fixed layer and layer value) is not present and the children of this node are hung into toplevel hierachy the the DataManager.

Perhaps this bug is gone with the new IO mechanism?

I haven't found a similar bug description so far, so I thing this but yet was not found.

The reason for us to use fixed layering is to control the rendering order of several meshes that lie very close to one another an thus proper visualization is dependent on the order of rendering.

Keep up the great work! ;)

P.S. I will provide a project file to reproduce...

Event Timeline

mitk project to show the bug

mitk project showing proper importing due to non double layer property

Added two mitk project files. The one is howing the bug, the other one without hitting the bug. The difference between both is that layer property of child22 is set to a different value than child 11 and thus it works. The file with the bug shows double entry in OrderedNodePairs so size is 4 instead of 5. Item with layer = 101 contains two entries.

As it was not that straightforward to decide how to fix this I didn't work on the solution. It seemed to me as if this section evolved over the time as well as there are unused variabled as well.

But tell me if I can help.
Best Regards,

Okay, did a code review in mitkSceneReaderV1. TL;DR the code soup is quite a mess. Must be rewritten in a relaxed moment to be seriously fixed instead of adding more and more code which tries to fit into the mess. :)

Keno what is the status of this bug?

Nothing happened here. We need to rewrite the reader to really do an inverse write. At the moment, wrong assumptions are made in the reader about how things should work (e.g. it is assumed that there cannot be more than one object per layer, as far as I remember). Unfortunately things are stored in maps and maps of maps that use the layer as identifier. Obviously there's a conflict. This is not an easy going bug squashing session as we need to change very import core behavior here without breaking anything.

I would propose to fix this bug in a sprint, not in bug squashing. By a core team member (probably me then...).

kislinsk lowered the priority of this task from High to Low.Jun 22 2018, 11:55 AM
kislinsk removed a project: Request for Discussion.
kislinsk added a project: Auto-closed.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs