I am one of those people .
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?
You are wrong again.
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.
Here's his explanation that I was trying to find earlier.IMback! wrote: ↑Fri Aug 16, 2019 2:37 pmWell 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.
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.IMback! wrote: ↑Fri Aug 16, 2019 5:20 pmWell, 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.
That's a good point for circles. I'm not sure the list is much longer than that one item though, is it?I agree with this notion in principal, with 2 caveats:
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.
- 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.
- 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.