Page MenuHomePhabricator

2D Normals inverted
Closed, WontfixPublic

Description

If the 2D normals (property) are rendered the front normals are rendered as the back normals and vice versa.

Event Timeline

I cannot reproduce this in Linux with ball.stl from MITK-data.

The bug might be restricted to open meshes and meshes with multiple components. I attached a test mesh. Please try it again.

Ok, I see it now. But how does anyone determine the "front" of an open mesh? To a human it's clear, but to the algorithm ... :) ?

I think it is not a big issue, since we already have the option to "invert normals" in case they are wrong.

In case a mesh has no stored normal it is indeed not trivial to find out its direction, but when a mesh already has stored normal they should be used of course.

The same problem is present when loading meshes with more than one component, even all components are closed sub-meshes.

Furthermore, the normals in the 3D view are correct. So we should synchronize behavior regarding normal calculation/usage.

We have the following options:

  • remove front and back color properties. The names are inappopriate anyway because it is misinterpreted as surface colors.
  • property description (temporary solution)
  • correct calculation of normals maybe the normals are incorrect interpolated

Current release is finished. Reseting target milestone...

I think this would be solved if we re-write the 2D polydata mapper to use VTK instead of OpenGL.

Will be fixed when porting to VTK.

kislinsk claimed this task.
This task was automatically closed because it wasn't updated at least since July 2016 (over 2 years). Please re-open this task if you think that it is still relevant. This most probably means that you will resolve it.