It seems to me that ANGLE_COS_EPS the more logical variable to use but it is used in only one place (exactly for checking 90 degrees) and LENGTH_EPS is used in 152 places, and the values are the same. What do you think?

The "random" split directions are technically OK because they happen on flat quads. This is much nicer looking though.

On the top surface there is a missing triangle in the lower left. You can tell the edge has a vertex there because the vertical surface triangles connect to it, but the top do not. That seems suspicious. Not related to the PR of course.

Ofc the problem is exist, but should be solved in a different way. One of the solutions is check distance from centre of two edge variants to actual surface and take variant with minimal distance

This approach will probably solve #489

And probably we should apply this to whole surface triangulation instead of quads.

@Evil-Spirit Thanks for your input. Maybe I merged this too soon. The goal here was to eliminate the randomness in triangles by using a tiny value other than zero. @ruevs and @whitequark to that end it didn't matter which small constant was used. Better to use the common one rather than allow people to thing the one that is hardly used is somehow more important than it is.

I like the idea of checking the distance of the 2 possible midpoints to the surface. It seems like more calculation and may not make a better mesh - your test results and PR are certainly welcome! It will not fix the stair-step effect because that is due to helix-axis line not getting subdivided enough. It might do something useful for the other issue of extra silhouette line, but those are also needed near one end but not across the entire "quad" which is twisted - they are too long, which AFAICT can only be fixed by more subdividing the surface along the radial axis - another problem where the edge being a straight line prevents more subdivision.

This is all very interesting to me BTW and I welcome the discussion!

@phkahler
Look at my new comment at #489. I mean, we will solve the problem with thorus and so on.
The helicoid surface which produced by line, not needs to get more subdivisions. The only problem is what we should turn edges not only inside quads but also quad border edges to get better (more precise) surface approximation. This is not an easy task, so the other way to solve - is choose the better parametrization for u and v, ofc if it is bad. I mean there is an issue about circles. By some reason, circle is split into 4 peices, but actually it can be exactly presented by only one rational bezier segment. The reason why it is split is because good parametrization for t is not performed (the problem is described e.g. here https://fjorgedigital.com/insights/blog/can-bezier-curves-be-quickly-parameterized-by-arc-length/)

I said about circle which can be exactly presented by NURBS. But helicoid surface, unfortunately, can be only approximated by NURBS.

On the top surface there is a missing triangle in the lower left. You can tell the edge has a vertex there because the vertical surface triangles connect to it, but the top do not. That seems suspicious. Not related to the PR of course.

I noticed it as well - it is suspicious - but I though I should look at it a bit closer and create a simpler test case before opening an issue.

It is not missing. Just small and... strange.

@ruevs Oh. I'm curious why that happens, but wouldn't worry about it too much. The best solution is to use Delaunay triangulation. Not that it's an easy thing to do, but eventually SS really should have it ;-)

I have no idea why it happens, debugging it would be...interesting... :-)

Previous discussions of Delaunay triangulation
Here:
#175 (comment)
Here:
Evil-Spirit@51616bc

Was looking at the triangulation code. That was probably just a fluke because it's an ear. I'm thinking the bridge to the hole is near there too. Really getting to understand how it's done, the code is actually very readable. Except maybe when this made me laugh:

if(l[ear].ear == EarType::EAR) {