We’re running with multi-sampling disabled since it’s problematic when combined with volume rendering on Intel GPUs (GL errors/black screen).
Instead we use FXAA with default settings to at least get some anti-aliasing for our polygonal geometry.
However, thin lines really don’t look that good, especially when drawn at near 45 degree angle.
Example of a line with width 2.0 rendered at near 45 degree angle with FXAA at default settings:
I’ve tried to play around some with the FXAA options based on the blog post at https://blog.kitware.com/new-fxaa-anti-aliasing-option-in-paraviewvtk/ , but haven’t been able to improve the result much.
Is there any way to do volume rendering + nice anti-aliased polygonal geometry (especially thin lines) that works reliably on Intel/NVIDIA cross platform?
FXAA is bad at handling thin lines, but this looks especially wrong. Are you configuring the render window without an alpha channel? The “steps” of the anti-aliased line edge should be dropping off in opacity to give a smooth appearance, but they seem to be maintaining uniform opacity. What is the output of
print(renWin) on python)?
If MSAA and FXAA aren’t working, there’s also
vtkSSAAPass that does super-sampled anti-aliasing. It’s an expensive option, but might work better for you.
At some angles it looks OKish:
It’s certainly better than no AA:
It’s just that at some angles it looks a bit ragged like in my first post.
The render window has an alpha channel for sure, because we’re using transparent polydatas. Here’s the printout:
Modified Time: 2961
Reference Count: 3
Window Name: Visualization Toolkit - OpenGL
Position: (0, 0)
Size: (0, 0)
Double Buffered: 1
TileScale: (1, 1)
TileViewport: (0, 0, 1, 1)
Double Buffer: On
Full Screen: Off
Modified Time: 2964
Reference Count: 1
Registered Events: (none)
Number Of Items: 2
Stereo Capable Window Requested: No
Stereo Render: Off
Point Smoothing: Off
Line Smoothing: Off
Polygon Smoothing: Off
Abort Render: 0
Current Cursor: 0
Desired Update Rate: 0.0001
In Abort Check: 0
Swap Buffers: On
Stereo Type: RedBlue
Number of Layers: 2
AccumulationBuffer Size 0
AnaglyphColorMask: 4 , 3
Not sure why that printout says MultiSamples: 8 BTW. We have the following as the very first thing in our main:
// Default to multi-sampling off.
auto format = QVTKOpenGLWidget::defaultFormat();
And using e.g. 8 there, the volume rendering breaks on at least some Intel GPUs (like the one in my laptop).
We’re using VTK 8.2.0 and vtkOpenGLNativeWidget.
Applying this patch to the Line example to disable multisampling and enable FXAA, and set the line with to 2.0
--- Line.cxx.orig 2019-11-26 10:02:17.617513296 +0100
+++ Line.cxx 2019-11-26 10:00:10.440851355 +0100
@@ -30,13 +30,15 @@
vtkSmartPointer<vtkActor> actor =
vtkSmartPointer<vtkRenderer> renderer =
vtkSmartPointer<vtkRenderWindow> renderWindow =
vtkSmartPointer<vtkRenderWindowInteractor> renderWindowInteractor =
Then rotating the camera a little:
With line width 3:
So it’s possible to reproduce with just plain VTK (no QVTKOpenGLNativeWidget).
Ok, taking a closer look with a screen magnifier, the opacity gradient is present, so it looks like things are working as expected.
We’ll have to just chalk this one up to “FXAA sucks at anti-aliasing lines.” Because of the way the algorithm works, the approximation errors are accentuated when a feature is just a few pixels wide.
Since it looks like these lines are being rendered as an overlay, you may try moving the actor that’s drawing the line to another renderer and configure that one with MSAA.
Ah alright. Yea I guess it’s just a limitation in the FXAA approach.
Hm, multisampling is a render window property though, isn’t it? So even if I moved these actors to a separate renderer, I’d need to activate multisampling on the render window (which breaks the volume rendering). Or is there a way to control multisampling per renderer? (on the bus with my phone, will check when I’m home)
Ack, you’re right. It’s been a while since I worked on our rendering
You could use a separate renderer configured with a
vtkSSAAPass on the lines, that should give a decent result.
@ken-martin may have some other ideas, perhaps there’s a way to enable MSAA on a single FBO that is later blended into the displayed render context?
Alright, will try a new renderer + vtkSSAAPass and see if the performance is OK. I only showed a single line here, but we’re going to do vector field visualization using vtkGlyph3DMapper and may have on the order of 10000 lines.
Will also take some syncing of camera positions since the lines are in the same 3D universe as the volume rendering.
Anyway, thanks for the tip!
Also, ideally these lines would be shown inside the volume, and not as an overlay on top, so this would be a compromise and it may turn out to look too strange.
(If you look closely at my very first screenshot, you’ll see that the line really is inside the volume, it is darkened in some spots by intermediate voxels)