Rotated holes result in different sized Helix tool paths.

[rainharvester]

Having a user modify defaults is not a good solution. A user should not need to know underlying behaviour/quirkiness to have a model be precise.

IMBack showed code that works with correct radius, for other cases. Why not fix all locations to use correct radius?
To an end user, it doesn't matter what kernel FC is based upon. If there are other cases that need fixing, then fix those too.

Basing a radius on a tesselated circle's bounding box is FUNDAMENTALLY incorrect regardless of default precision. Tesselation isn't the same category as rounding error / truncation. If code is based on tesselation like this, it will fail in the future.

One might actually WORSEN the default Precision (set it to 10mm!) then use freecad to find/debug all the bad occurrences of using a tessellated circle's radius.

[GeneFC]

You will have a rough time succeeding with FreeCAD if you insist on sticking with the default parameters. Don't forget that many, if not most, FreeCAD users are interested in topics like architecture. One millimeter is probably good enough for those cases.

User parameters are "adjustable" because different users have different needs. If "one size fits all" was the case then the adjustment would not be needed

Gene

[bill]

First of all, I dont call this a bug.
It is just the way "Hole-Detection" was implemented at the time (now, we know better from testing), and Ive seen it as a long term problem that had to be acknowledged and compensated for through the user "awareness".

Shifted geometries need to be dealt with as best as possible; since they are asymptotic approximations with acceptable error.

Here we have a very-simple P.R. (that could be backed out with relatively no effort), effective, more gracefull implementation for dealing with this situation which needs to be merged.

You are doing development here, arent you, not production.

Suggestion:
With one modification/code test: If the bound box is resolved to be square, use older return value (to maintain max accuracy); if bound box is resolved to be non-square, return PR solution return value.

Continuously changing default settings is for the birds!

Just a thought!

[rainharvester]

I'm not going to have a rough time because I can afford to spend 4 hours to figure out what is wrong. But new users? Maybe they won't.

[chrisb]

Tesselation isn't the same category as rounding error / truncation.

We often see here in the forum questions about transforming STL files to FreeCAD models. NormandC used to say that the STL is crap because it is tesselated - where he is right - as opposed to FreeCAD's representation of perfect mathematical objects - where he is almost right, the limiting factor being the computational precision of the hardware.

This "mathematical precision" is probably far away from what we need for paths, where not many machines are able to position better than 1/1000mm, but it seems that using the bounding box is too coarse. If it is possible to use the FreeCAD mathematical object instead - fine, let's do it. If this is not possible for some reason such as an external library, then this is well possible, because the generated G-code is only an output format. But in that case let's use the precision parameter for paths which can be configured in the Path preferences. Let's not use some other parameter which is supposed to control only the visual representation of objects.

Decreasing these display values may result in significant performance issues in rendering complex models.

[IMback!]

Just to drive the point home further that this is a problem, here is what happens when i change the viewport settings to 10% deviation and 80 degree deflection (not absurd for huge models), this is without rotating the object at all:

[IMback!]

And same thing again with PR and part:

[chrisb]

These two images just show that these two properties affect the display of models, which is what they were made for.
It is better to show examples where the model itself or the generated G-code is wrong.

[IMback!]

no. hint: the diameter from the helix operation is shown, the fact that the visualization accuracy is poor is of course as intended

[GeneFC]

Some people seem to be missing the point. It is NOT just "visualization" that is controlled by the tessellation parameters. OCC does real computations based on those settings, not just display.

If you want to make a special case for every conceivable shape and every operation in order to get around the computation imprecision I suppose that is OK. It just seems a lot better to improve the computation precision for all cases by adjusting a single setting.

Gene