visit-dav / visit

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data
https://visit.llnl.gov
BSD 3-Clause "New" or "Revised" License
438 stars 116 forks source link

Not rendering 2D non-convex quads properly #5365

Open brugger1 opened 3 years ago

brugger1 commented 3 years ago

Matt Obrien reported that VisIt isn't rendering 2D non-convex quads properly. In particular he has some boomerang quads in his mesh and those are being rendered with the convex portion filled in. I have a sample file on the RZ and some images of the bug, but this should be easy to create a sample dataset for.

We should probably just handle this properly. We can do it in a staged manner. First by adding an operator that splits the bad quads, next by adding an option to check for degenerate quads and splitting them if necessary. This splitting could be done ahead of doing the rendering, although this causes an issue with structured grids turning into unstructured grids or doing it directly in the rendering routines. Doing it in the rendering routines potentially requires touching more code, but some code sharing could be done.

We have the SubdivideQuads operator that could be used in the short term. That would handle the cases where the center point is within the quad.

markcmiller86 commented 3 years ago

We have issues with big quads (#2903) that similarly require breaking them into triangles. In both cases, one challenge is picking the right diagonal to split a quad on. For non-convex quads, the mesh geometry itself tells us which diagonal. For correct contouring (#2903) the correct diagonal can depend on the variable being contoured over the quads. Of course, you can have all these cases conspiring within the same plot too. Obviously, mesh requirements trump everything else but once satisfied its concievable another set of considerations need to be included to fully split all quads appropriately. IMHO, SubdivideQuads (which is certainly the best short term work-around) doesn't really fix the big quads problem...it just makes it less noticeable.

I wonder if we should maybe take a slightly different tack here? Maybe we should select a different default behavior and just be smart about this to begin with and always inspect and appropriately split each quad (always suffering whatever performance implications that has but then always getting a good image) with an option to somehow control or disable the quad splitting logic as a fall back.