Rotated holes result in different sized Helix tool paths.

Here's the place for discussion related to CAM/CNC and the development of the Path module.
chrisb
Posts: 16935
Joined: Tue Mar 17, 2015 9:14 am

Re: Rotated holes result in different sized Helix tool paths.

Postby chrisb » Thu Aug 15, 2019 11:42 pm

I am one of those people :oops: .
Besides Path and visualization the only thing I know being affected by the deviation and angular deflection parameters is the export tesselation e.g. for STLs. What else is controlled by them?
IMback!
Posts: 68
Joined: Sat Jul 13, 2019 9:40 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby IMback! » Fri Aug 16, 2019 8:36 am

GeneFC wrote:
Thu Aug 15, 2019 11:16 pm
OCC does real computations based on those settings, not just display.
You are wrong again.

We in path have accuracy settings for tesselation, distinct from the viewport. These are in preferances->path->job preferances. (only shows up in path workbench)

Freecad also has settings to control the tessellated output accuracy (like STL), These are in preferances->inprt-export->mesh formats. again these are distinct and independent from the visualization (only shown while in mesh wb, but always used)

Same thing in the FEM workbench.

The tesselation settings for the viewport are in preferances->part design->shape view. shape view! greping though the code for the proparies set by these spinboxes, i can find no use of them, ever, except for the viewport.

Calculating things basted on the vieport tesselation is not done, and is only acceptable if you are the viewport or only need the coarsest of accuracys. Anyways OCC does very little with the tessellated shapes, it cant because tesselation is a one way street and subsequent operations cant be performed if the internal representation where tessellated.
Last edited by IMback! on Fri Aug 16, 2019 8:49 am, edited 1 time in total.
chrisb
Posts: 16935
Joined: Tue Mar 17, 2015 9:14 am

Re: Rotated holes result in different sized Helix tool paths.

Postby chrisb » Fri Aug 16, 2019 8:49 am

Can you tell us something about where the BoundBox is used?
IMback!
Posts: 68
Joined: Sat Jul 13, 2019 9:40 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby IMback! » Fri Aug 16, 2019 11:29 am

Sure. Note this is not exhaustive, i just searched though some of freecads workbenches

In PartDesign:
  • Used in the view provider (makes sense)
  • nowhere else
In Part:
  • Used in the view provider
  • Used in the sections algorithm (for display, not accuracy critical)
  • nowhere else
In Arch:
  • Used for nesting
  • Used for sectioning (just to speed up the algorithm, things clearly outside of the section area are discarded via bound box every thing else is then determined accurately)
  • Used in various arch elements to test if things could collide (AFAIK not accuracy critical)
In FEM:
  • Used only once after tessellating at fem accuracy
  • Comes with this comment: "BoundBox is possible too, but is BB calculations robust?!"
In Path:
  • Used in the circularHoleBase (this topic)
  • Used to determine size of stock (not accuracy critical)
  • Used in various places to determine operation start and stop heights (this happens to always be accurate for 2.5D shapes but might bite us in the ass when more 3d operations are performed)
  • Used in Path adaptive for vaious intersections tests (just to speed up the algorithm, things clearly outside of the intersection are discarded via bound box every thing else is then determined accurately)
  • Used in Path adaptive in one potentially scary way in GetBoundedClearedPaths
  • Note that in places where the objects are tessellated at Path preference accuracy for some unrelated algorithum the bound box will be accurate to the degree set in the path preferences, this is the case in some places in the code.
Serching for the boundbox classes over all of freecad shows path as its most intensive user, as the authors of path seam to have been very fond of this function, maybe assuming it to be accurate and robust. The fact that OpenCASCADE uses the tesselation to determine the boundbox baffles me anyways. Calculating the boundbox from a mathematically defined surface is pretty easy, and solving boundbox equations via numerical integration will converge much faster than tessellating at high accuracy. The OpenCASCADE devs probably only intended the boundbox to be used for visualization and assumed that a tesselation would always be calculated already anyways making the BB very fast, there is evidence for this in OpenCASCADE documentation.
User avatar
sliptonic
Posts: 1552
Joined: Tue Oct 25, 2011 10:46 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby sliptonic » Fri Aug 16, 2019 2:08 pm

I haven't commented yet because other things in my life have been eating up my time and because my math skillz probably aren't up to the task. But I've been following along the best I can.

After chatting with mlampert, I think we should merge this PR.

Reading through this, I'm reminded of some comments made by JulianTodd last year and they sound prophetic now. He advised that Path should work exclusively with tessellated models and avoid trying to calculate tool paths directly from the 'real' geometry.

I can't find all the examples but here's one place where it came up.
IMback!
Posts: 68
Joined: Sat Jul 13, 2019 9:40 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby IMback! » Fri Aug 16, 2019 2:37 pm

sliptonic wrote:
Fri Aug 16, 2019 2:08 pm
Reading through this, I'm reminded of some comments made by JulianTodd last year and they sound prophetic now. He advised that Path should work exclusively with tessellated models and avoid trying to calculate tool paths directly from the 'real' geometry.
Well i would be interested in hearing his reasoning for this, being able to run CAM calculations offline dose not ring true to me as a reason to only use tessellated shapes, as one can easily save and transfer the mathematical volume model to an external process.

Tessellating and then curve fitting retroactively to avoid mathematical singularities in the path acceleration seams needlessly round about and error prone, as JulianTodd correctly states in the linked post about curve smoothing. I have a hunch that he meant this in the context of an adaptive clear operation, where due to the nature of the generated path the volume model would not be of much use to the path generator.

It is true that commercial CAM systems sometimes use tessellated shapes at some point in the calculation path, but this is due to the fact that off the shelf algorithms use tessellated shapes, which AFAIK in turn is because there is no single accepted binary representation of mathematical volumes.

Regardless of the above we need to tesselate at the tesselation accuracy set in path preferences when tessellating for some path generating algorithm, and not just use the viewport tesselation. There are other instances that this is done incorrectly in freecad path.
User avatar
sliptonic
Posts: 1552
Joined: Tue Oct 25, 2011 10:46 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby sliptonic » Fri Aug 16, 2019 3:43 pm

IMback! wrote:
Fri Aug 16, 2019 2:37 pm
sliptonic wrote:
Fri Aug 16, 2019 2:08 pm
Reading through this, I'm reminded of some comments made by JulianTodd last year and they sound prophetic now. He advised that Path should work exclusively with tessellated models and avoid trying to calculate tool paths directly from the 'real' geometry.
Well i would be interested in hearing his reasoning for this, being able to run CAM calculations offline dose not ring true to me as a reason to only use tessellated shapes, as one can easily save and transfer the mathematical volume model to an external process.

Tessellating and then curve fitting retroactively to avoid mathematical singularities in the path acceleration seams needlessly round about and error prone, as JulianTodd correctly states in the linked post about curve smoothing. I have a hunch that he meant this in the context of an adaptive clear operation, where due to the nature of the generated path the volume model would not be of much use to the path generator.

It is true that commercial CAM systems sometimes use tessellated shapes at some point in the calculation path, but this is due to the fact that off the shelf algorithms use tessellated shapes, which AFAIK in turn is because there is no single accepted binary representation of mathematical volumes.

Regardless of the above we need to tesselate at the tesselation accuracy set in path preferences when tessellating for some path generating algorithm, and not just use the viewport tesselation. There are other instances that this is done incorrectly in freecad path.
Here's his explanation that I was trying to find earlier.
IMback!
Posts: 68
Joined: Sat Jul 13, 2019 9:40 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby IMback! » Fri Aug 16, 2019 5:20 pm

Well, it seams that Mr. Todd is of the opinion that when implementing an algorithm on the mathematical volumes/surfaces is hard and doing so on the tesselation is significantly easier its best to not bother with the slight increase in accuracy afforded by the mathematical volumes/surfaces.

I agree with this notion in principal, with 2 caveats:
  1. The assumption that an algorithm is always easier to develop for the tesselation is not universally true. Where this assumption is not true the extra effort in making the algorithm work with the tesselation is just silly.
  2. JulianTodd appears to be of the opinion that this is an either a or b black and white choice, this is not really true. If both of the representations are available one can, for instance implement the algorithm for tessellated shapes first, making it universal and later add special cases for mathematical shapes where doing so is simple.
In addition to the problem of using the wrong tesselation, Point 2 is exactly what is happening here, we are adding a case for circular surfaces to the hole diameter algorithm. Which is a trivial thing to do and since circular surfaces is what is normally processed by the drilling operations it is very worth while.
User avatar
sliptonic
Posts: 1552
Joined: Tue Oct 25, 2011 10:46 pm

Re: Rotated holes result in different sized Helix tool paths.

Postby sliptonic » Fri Aug 16, 2019 7:28 pm

IMback! wrote:
Fri Aug 16, 2019 5:20 pm
Well, it seams that Mr. Todd is of the opinion that when implementing an algorithm on the mathematical volumes/surfaces is hard and doing so on the tesselation is significantly easier its best to not bother with the slight increase in accuracy afforded by the mathematical volumes/surfaces.
If anyone is nervous about words like 'slight increase in accuracy'. Don't be. Julian make the point that you can tessellate to any degree of accuracy you want, well below the physical capabilities of the machine so the required accuracy is easily controlled.
I agree with this notion in principal, with 2 caveats:
  1. The assumption that an algorithm is always easier to develop for the tesselation is not universally true. Where this assumption is not true the extra effort in making the algorithm work with the tesselation is just silly.
  2. JulianTodd appears to be of the opinion that this is an either a or b black and white choice, this is not really true. If both of the representations are available one can, for instance implement the algorithm for tessellated shapes first, making it universal and later add special cases for mathematical shapes where doing so is simple.
In addition to the problem of using the wrong tesselation, Point 2 is exactly what is happening here, we are adding a case for circular surfaces to the hole diameter algorithm. Which is a trivial thing to do and since circular surfaces is what is normally processed by the drilling operations it is very worth while.
That's a good point for circles. I'm not sure the list is much longer than that one item though, is it?
RatonLaveur
Posts: 186
Joined: Wed Mar 27, 2019 10:45 am

Re: Rotated holes result in different sized Helix tool paths.

Postby RatonLaveur » Fri Aug 16, 2019 7:42 pm

In echo to sliptonic's accurate statement I'd add that most commercial CAM software i know of uses tesselated models as their base for toolpathing. Never seemed to bother the likes of Autodesk or Dassault...if it's good enough for a watch movement or a fighter plane...it should be good enough for Freecad lovely community :)