Page MenuHomePhabricator

2D surface mapper cannot handle empty surfaces
Closed, ResolvedPublic

Description

mitk::Surface::Pointer surface = mitk::Surface::New();
mitk::DataNode::Pointer dataNode = mitk::DataNode::New();
dataNode->SetData(surface);
this->GetDataStorage()->Add(dataNode);

vtkCutter and vtkGlyph3D related errors:

15.40 core.io.loggingadapter ERROR: ERROR: In D:\MITK-superbuild\VTK-src\Common\ExecutionModel\vtkDemandDriven
Pipeline.cxx, line 715
vtkCompositeDataPipeline (000000000B5ABD30): Input port 0 of algorithm vtkCutter(000000000DD39960) has 0 conne
ctions but is not optional.
15.43 core.io.loggingadapter ERROR: ERROR: In D:\MITK-superbuild\VTK-src\Common\ExecutionModel\vtkDemandDriven
Pipeline.cxx, line 715
vtkCompositeDataPipeline (000000000B5AAC00): Input port 0 of algorithm vtkGlyph3D(000000000DD397F0) has 0 conn
ections but is not optional.

Event Timeline

The mapper connects the vtkMapper with the vtkActor to early. This should be lazy-initialized during the first valid GenerateDataForRenderer.

Similar, the normal mapper is added to early to the vtkPropAssembly.

User kislinsk has pushed new remote branch:

bug-18674-2DSurfaceMapperFix

Requested core modification flag. Before merging we should discuss this bug during the next bug squashing. I also recognized further issues like way too big normals, or wrong surface representation when activating backface culling (3D mapper).

I think we should add a NULL check in the Update() (e.g. if input->GetVtkPolyData() == NULL) return;), similar like the ImageVtkMapper2D does it. (I assumed there was also one in the surface mapper, but apparently there is not.)

Lazy-initialization will not prevent crashes if the user sets a poly data to NULL via surface->SetVtkPolyData(NULL). We can discuss the details next Wednesday.

[2f9849]: Merge branch 'bug-18674-2DSurfaceMapperFix'

Merged commits:

2015-01-23 14:14:42 Stefan Kislinskiy [accdcd]
Lazy-initialize vtkActor to vtkMapper connection.