vnf_vertex_array styles: when to use which ones (examples), quincunx and concave

[adrianVmariano]

I'm wondering about the styles for vnf_vertex array. Are they all useful? And if so, should we add a concave style? I think we need some examples showing cases where the different VNF styles work best, and how the wrong choice looks bad.

Is there ever a situation where the quincunx style produces a good (desirable) result? Seeing the example with gears where it made things look bad made me aware of this issue: it introduces a new point which is only actually on the polyhedron if the face being split is coplanar. So it seems like we have a situation where if the face is coplanar this is a good choice....but it won't look better than the alternative. If the face is nearly coplanar it should also be a decent choice, but it probably still won't look better. And if the face is far from coplanar it's going to twist the shape in a weird way and the result will be bad. I'm inclined to think that we should remove this style.

A similar question arises for the convex style. Is there some case where it produces the best result and is different than the other results? Presumably this would be for convex shapes? If such an example exists then presumably it can be inverted to require the concave style, so then presumably the concave style should be implemented as well.

So I'm thinking that "quincunx" should go away. And either we add "concave" or we also get rid of "convex".

Whichever styles we keep, there needs to be some examples in the docs showing how the style differ and when the various styles look good/bad.

[revarbat]

"quincunx" was added for the case where the surface flexes both ways, making both the default and "alt" styles incorrect for parts of the same surface. Consider passing function (x,y) sin(x/3) * sin(y/3) to heightfield(). You get places on the surface where it naturally wants to bend against how it gets triangulated.

It preceded "min_edge" and "convex". I'm fairly sure "convex" doesn't make a better look for this case. Nor would a theoretical "concave", which we maybe should implement. Dunno about "min_edge".

[adrianVmariano]

I'm having a hard time figuring out whether quincunx actually looks better for that case. The problem is that it's hard to know how to make a good comparison. I tried doing difference of a high resolution version of your height field and differencing with low res using different styles. By this measure, quincunx performed worse than everything except convex.

Another observation is that quincunx doubles the number of triangles. Presumably it would be better to double the triangles with real data instead of interpolated data. I guess the key observation is that what quincunx is trying to do is make a grid based on triangles instead of quads, by having alternately offset rows of points. And whether it works well or not depends on how good its approximation for the interpolated points actually is. So like perhaps something more sophisticated than linear interpolation would work better?

Now I did identify a case where quincunx clearly works very well: in refined sweeps the refinement is linear which means that quincunx is calculating the exact centerpoint, so you get an extra point added exactly. (Does this mean quincunx should be the default for skin?)

skin([path1,path2], z=[0,5], refine=30, slices=30);
color("red")vnf_wireframe(skin([path1,path2], z=[0,5],  slices=0, style = "quincunx") ,d=.1);

But in the height field example, this is not the case. Though quincunx does produce symmetry.