This is a cosmetic bug, however, necessary for smooth kinect integration.
The current version of mitkToFSurfaceVtkMapper3D has the following issues:
- Almost the whole class is copied from mitkSurfaceVtkMapper3D, which should be solved either by inheritance or by re-usage of mitkSurfaceVtkMapper3D and not by just copying code.
- The mitkToFSurfaceVtkMapper3D enhances the mitkSurfaceVtkMapper3D by a texture mapping and the possibility to show scalar values on the surface. This is a generic feature which could be usefull for users who are not interested in ToF at all. We have to decide whether to move this class to another location or even implement everything in the mitkSurfaceVtkMapper3D.
- There are three different ways to map colors on the vertices:
a.Scalars from the vtkScalarToColorTransferFunction
b.Texture from OpenCV
c.Texture from RGB-Image (not implemented in the current master)
a. + b. are spread all over the following classes:
QmitkToFUtil (settings to activate the functions)
mitkToFSurfaceVtkMapper3D (set texture + scalars for the vtkProp)
mitkToFDistanceImageToSurfaceFilter (compute texture coordinates)
> The code is a mess! ;)
Requirements:
-The interface of the new (old) mapper which passes this information to vtk should be kept very simple. The coding effort is very simple in VTK!
-Everything related to this features in QmitkToFUtil and mitkToFDistanceImageToSurfaceFilter should be implemented seperately for the three different ways. I assume b. + c. can be combined, but I'm not sure about the textureScaleCorrection variables used in the mitkToFDistanceImageToSurfaceFilter. I guess they are video-camera dependent and eventually ment for the resolution for Kwongs web-cam?
-The texture coordinates should only be performed once, since any camera does usually not change resolution during.
I can offer to implement this, but I would like to consult Alex if my solution is sufficient for all needs.