Handing of coloring and cliping for cells is incorrect

I am looking at how ParaView paints and clips cells. Lets start with paint.

If we paint by cell data, we are flat shading. I’m not sure if flat or smooth shading is the correct thing to do. I am sure that flat shading doesn’t look as good as smooth shading. EnSight smooth shades. VisIt flat shades. I would like to propose we change to smooth shading, with the option in the properties tab to flat shade. To see this issue, open can.exo. Go to timestep 2. Paint by EQPS. Screenshot attached.

Next, I think we are doing the wrong thing with regards to clip by scalar. Again, we need cell data, so use can.exo and EQPS as above. Clip/ Scalar/ EQPS/ Reset using current data ranges/ Uncheck Invert. Apply. This gives us the same thing as Threshold - cells are thrown in or out. But, for Clip by Scalar, it should be smooth. In other words, if clip and slice create a smooth surface cutting through each cell, Clip by scalar should also, no matter what the data type. Visit produces a smooth surface for isoVolume. EnSight creates a smooth surface for isoVolume. See attached screenshot. On the left is what we current have, on the right is what we should have.

If everyone agrees, I will write up feature requests.

@cory.quammen @dcthomp @Kenneth_Moreland @mwestphal

A cell scalar in VTK represents a single, constant value taken on over the entire cell, with disconuities at any cell boundaries whose neighbors take on a different value. It should be drawn with this discontinuity. If you clip by cell scalars, that should be equivalent to thresholding cells since the field is constant over the cell.

It is important to distinguish between shading (determining the interaction of light with the surface (and/or interior)) and coloring (determining the nature of the material with which the light interacts). If a surface is smooth but the scalars are constant over the cell, the lightness/darkness should vary smoothly (e.g., by using interpolated point normals to shade fragments) but the color reflected/transmitted by the surface should be discontinuous at cell boundaries. I don’t recall if the polydata fragment shader can handle point normals and cell scalars simultaneously, but that is a valid feature request if not.

If an engineer wants to render a smoothed approximation to a discontinuous function, he should run the cell-data-to-point-data filter. I would argue against that as the default, although I am not opposed to adding a preference to ParaView (and accompanying setting for each representation) that does this averaging so users don’t continually have to run a filter.

This soulds like two completely different issue @wascott .

To get smooth shading, One needs to compute normals on the surface, which you can easily do with GenerateSurfaceNormals.

IsoVolume is its own filter in ParaView, so I’m not sure what is the question here but is similar to ClipByScalars. In any case, you cant have smooth results with cell data as there is no interpolation.
As you already figured out, you need PointDataToCellData, no reason to do it for the user, the user adds it if needed.

Correct, these are two different issues, caused by the same underlying way cells are represented. David correctly mentions that VTK holds a single constant value across a whole cell. This is the issue driving how we display data to users.

Also, as usual, David correctly points out I am being sloppy with wording. I am discussing coloring, not shading.

IsoVolume is a link to Clip by Scalar (the original implementation) Let me ponder what has been said for clip by scalar/ isoVolume, and will then reply.

David, I agree with everything you say. Lets focus on isoVolume. There are 2 issues that I see with consequences of our implementation. First, again what you say is correct about how isoVolume should treat cells as Threshold does. The problem is that isn’t what users frequently expect. They frequently expect the result to be smooth. The second problem is that many users don’t understand the nuance of why their isoVolume is blocky, and/or don’t know about the cell data to point data filter. Thus, we have a correct, but user unfriendly system.

On isoVolume I would propose that we add a “Smooth Clip for Cell Data” option, default off, default Properties tab. Let’s at least make it obvious and trivial how to change to a smooth surface without having to run the cell data to point data filter explicitly.

On the Properties tab, Scalar Coloring section, I would propose we add a Smooth Coloring for Cell Data" option, default off, default Properties tab. Again, let’s at least make it obvious and trivial how to change to a smooth surface without having to run the cell data to point data filter explicitly.

Thoughts?

Such an option already exist, it is a setting called: “AutoConvertProperties” and always provide a point data for any cell data, amongst other things.

However, your experience of ParaView may vary when using this setting.

I’m late to the party, but I agree with most of what @dcthomp and @mwestphal have already said. I would argue that ParaView’s behavior is correct. I would point out, though, that the auto convert properties feature does not help in this case because fields are not automatically converted if the filter handles both field associations, which is the case for Clip.

That said, does anyone know exactly what VisIt is doing for isovolumes on cell data? Is it doing a simple cell-to-point conversion (i.e., averaging cell data to points)? If so, then I would argue that ParaView should not do that (by default). But perhaps it is doing something more clever to find a representation better than either approach.

2 Likes

Echoing what Ken says below, AutoConvertProperties is not the correct answer. This automagically applies to all filters, which we don’t want. My issue is specifically with an IsoVolume.

From Eric Brugger (VisIt project manager): VisIt is averaging the cell values to the nodes. We do the same with contouring of cell data.

Conversion from point to cell data to point data and vice versa is done only on demand by filters, so it is not a huge resource burden to turn this option on. The bigger problem is as Ken points out, if your filter handles cell data named EQPS then it doesn’t provide the option to use cell-to-point data to get a point-associated EQPS. We could potentially expose cell data arrays as point data arrays in this case (and vice versa). If we did that, you would only need to know that you need to clip by the point data array and not the cell data array and you have what you are looking for.

I am firmly against turning on cell-to-point data for specific filters. Users should be aware of their dataset characteristics and why they don’t get a smooth result by default. They should also know how to change their data (and they are changing their data) to get a smooth result if that is what they are after. I don’t want to lie about the data ParaView displays by doing implicit conversions.

I generally disfavor adding options to enable/disable that behavior because of the combinatoric explosion in testing required to ensure options work as expected and resulting increased maintenance burden.

1 Like

Let me discuss with my users. Thanks everyone for a very enlightening and open discussion.

Discussed with user. He agrees that we should not change ParaView. I showed him how to make clean iso Volumes (Cell to Point filter).

1 Like