See attached Exodus file comprised of quadratic hexahedral elements (Hex27). Whenever a non-zero
Nonlinear Subdivision Level is used, to show the curved elements, “speckles” appear on the surfaces and the surface edges become “dashed”. The default setting for NSL is 1, so by default these meshes look… unprofessional (i.e. not suitable for publication). Is there a setting that I need to activate in order to properly visualize higher-order meshes in ParaView? This isn’t the first issue I’ve seen with higher-order meshes.
I’m seeing this behavior in ParaView 5.8.1 and ParaView 5.9.0-RC2, Windows 10, NVIDIA 2060 SUPER
FLEX-4.g (1.4 MB)
NSL = 0
NSL = 1
NSL = 2
NSL = 3
NSL = 4
The speckling is not an artifact of the JPEG/PNG compression… that is what it actually looks like in ParaView. If I change from
Surface with Edges to just
Surface mode it all goes away:
As it does if I turn
Nonlinear Subdivision Levels to 0:
And it’s a bit easier to see what’s going on if you make the line-width large and turn down opacity (i.e. make transparent) and zoom in:
And here’s with opacity = 1.0
Here’s that same view, but with line width = 1 – see the “speckling” on the faces?
Definitely consistently reproducible. @martink, any ideas on how to resolve this?
With a line with of 10 and subdivision of 2, we notice how the line tip is rendered differently.
A workaround for now is to add a pass through filter like Calculator or AddFieldArrays and then render that as wireframe while rendering the original dataset as surface.
Thanks for looking at this @utkarsh.ayachit . Your workaround works for my immediate “regular” rendering needs. I took a stab at testing your workaround when doing ray-tracing… here’s my same mesh as above, rendering the
AddFieldsArray pass-through as a wireframe with
Nonlinear Subdivision Level set to 4 and a very small line width (0.025):
Zooming in, and adding the un-refined mesh in red:
We can see that it looks like the ray-tracer is rendering all facets edges when it should look something like this (note - turned NSL to 0 to show layout):
If you set NSL to 4 and leave linewidth at default of 1 you get:
Pretty sure raytracing does not differentiate between refinement polydata edges and real cell edges. Looks like there’s already an open issue that you’ve reported: https://gitlab.kitware.com/paraview/paraview/-/issues/20245
Agreed. Shouldn’t be too hard to do edges correctly.
A longer term but much cooler possibility is to render the non linear cells directly without tesselation. Would make a good Google summer of code project.
Thanks @utkarsh.ayachit for that explanation.
I wasn’t sure whether these were related, but thought they might be.
We (Coreform) would be happy to provide any letters of support for such an effort, whether GSoC or SBIR.
FWIW, I finally found the word I was searching for with “speckled”. I think I’m seeing Moire patterns:
FWIW, I tried this in an older version of ParaView (5.7.0) and this is not an issue:
Is this the high frequency artifact of screen space antialiasing (SSAA) with rasterization? You could check by turning it off in settings with 5.8/9, or on with 5.7.
It is a known issue (discussed before merging) that can’t be easily resolved with the approach we use to my knowledge. Part of why we suggest limiting line width to smaller values. The cut outs at the end of the line are due to the other triangle of the quad (recall quads are actually rendered as triangles) not drawing that small section of the line which is contained inside it.
Tested this, appears to have no effect in any of these versions.
Thought I’d just bump this since a recent GitLab issue was raised.
Is there a status update regarding this issue rendering high-order meshes in ParaView? We are aware of a 3rd-party presentation happening this week that will talk about “High-order support in VTK/ParaView” and this doesn’t appear to be on the docket to be fixed in 5.10, 5.11, or 5.12.
Related GitLab issue:
Related Discourse post:
cc-ing @martink. Any thoughts on how we can fix this issue? This definitely won’t make it in 5.10.
It is impossible to fix using the approach we are currently using. Extract the wireframe and render it as tubes or lines as you suggested earlier.