We have recently migrated from vtk8.1 to vtk8.2. We immediately noticed some z-fighting going on between 3d geometries and 2d regions that are “attached” to the surfaces (each polydata has a separate actor). In vtk8.1, we were able to resolve this by just moving the points of the 2d region away from the surface (in the normal direction) by a small amount (5E-02). When we switched to vtk8.2 this was no longer the case. Even moving the 2d region outward by as much as a whole unit was not enough to eliminate z fighting. This is too much, as the offset becomes noticeable to the user. We do a decent job of setting znear and zfar, and that code hasn’t changed, so I’m not sure what is making the z fighting so pronounced. Another strange thing was that zooming the view (in parallel mode, so just setting the scale actually) caused changes in the z fighting, even though znear and zfar didn’t change.
I tried turning on vtkMapper::SetResolveCoincidentTopologyToPolygonOffset, and to my surprise, simply calling this and changing nothing else made these problems disappear. However, another problem then surfaced: We have backfaces turned on with a brown color. Along certain corner edges of the geometries, the brown backface would show through the surface, as if the z buffer had decided the backface was in front, which it clearly was not.
I’m wondering if anyone might have any ideas of anything I could try to fix this. We got some nice improvements in picking performance from 8.2 and really don’t want to roll back!
The best remedy I know for Z-figthing is indeed adjusting your near and far planes (z-near and z-far) so z-near is the furthest possible and z-far is closest possible. Maybe your current z-near/-far setting criteria are not good enough for 8.2. Just my two cents, since you didn’t post any code nor images of the artifacts.
Thanks for the reply. I’ve attached 2 images to illustrate the problem. These are in parallel not perspective mode ( though similar problems exist in perspective). In the first image, we are calling vtkCamera::setClippingRange with a range of 921.45, 1525.28 The parallel scale is 122.075. The second image is zoomed in, with the same clipping range and a parallel scale of 8.465. Do those range values seem reasonable to you? I’ve tried hard coding them to tighter values (1300,1400) but it seems to change nothing.
The brown areas are where the backfaces are showing through. These meshes are “watertight” and there should be nothing showing through. I’ve checked them in ParaView and they look fine there.
If there is something in the code you’d like to see that can help me make sense of this, I’ll upload it if I can. It’s a big program and it’s not easy to just upload a working sample…
Your clipping planes range are quite good. Z-fighting is not supposed to happen with a quite small difference in the hundreds.
Good images. That’s odd indeed. Please, do a search in the code for a SetUseExplicitProjectionTransformMatrix( [ true | variable_with_true ] ) or UseExplicitProjectionTransformMatrixOn(). These two calls disable the clipping planes setting. If this is difficult, or your camera settings is in a library whose code you don’t have access to, you can query the camera for whether it is using a custom projection matrix with GetUseExplicitProjectionTransformMatrix ().
Thank you @Paulo_Carvalho. I will check those things out. I wanted to share one other thing I have learned. If I instead use vtkMapper::SetResolveCoincidentTopologyToShiftZBuffer , I have neither of the problems. Again without setting any of the mapper-specific parameters, just calling the global. I am only a year into doing 3D stuff and I still feel like a monkey but slowly making progress. Thank you for your help!
