Surface mesh with opacity different of 1 is not rendering properly when changing the Zoom of the 3D view
When changing this line of code in QVTKWidget.cpp, Ln 242:
//if(isVisible())
{
this->mRenWin->Start();...
Then it works
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T9898 Metabug: Revise MITK Surface Rendering | ||
| Wontfix | None | T3345 Surface mesh opacity problems |
Event Timeline
Comment Actions
Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.
Comment Actions
we fixed another bug related to transparency by using a depth sorted polydata. This special rendermode can be enabled by setting the bool property "Surface Rendering.Depth Sort".
Maybe this fixes also your rendering bug, xplanes?
You can check out this branch "bug-3345-meshopacity" to test it.
Comment Actions
I wrote the core change request. Anja will provide a screenshot of the depth sorted surface.
Comment Actions
We figured out that depth peeling is disabled by default. As a result, there is no connection between the bug and depth peeling.
We also implemented a small example in VTK (without MITK) reproducing the bug on my machine. We have to test this on other OS and hardware.
Comment Actions
We tested the "stl causing the issue" STL surface on the following systems with MITK and a simple VTK example application (see comment above - ReadSTL). Our results so far are:
- On Ubuntu 11.04 and 11.10 the surface looks awful in both applications.
- On Mac it looks awful in the VTK example but nice in MITK.
- On Windows it looks nice in the MITK application. The VTK example has not been tested yet on Windows.
Comment Actions
We tested again. Under windows everything is fine. Needs to tested again under Mac and Ubuntu.
Comment Actions
It is still awful in ubuntu 12.04..
We should decide whether we want to investigate more here or keep this as known issues caused by VTK only on linux.