-
-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring,Optimize, more comments #1251
Conversation
- Refactor and remove unsused variables - Finally reverse best path to give better human interpretation - Considering all case of the curve AA-AB-BA-BB
Well done, it looks very promising! Today is electronics day, I have some projects to finish with atmega and other junk. I'll find a moment to try the new version of the algorithm.
All the filling is done via G1, even that the "Inset" mode. |
From a quick test I believe that the problem, which I see, with the reversal of the paths, is still there. I honestly do not really understand the cause, but if I use the code in master, where I have disabled the inversion, and that of this commit, here's what comes with the diagonal grid filling: 2021-01-06.12-19-49.mp4 |
As you can see there is a lot of red (non tracing) moves, which are not in the master version. |
Keep in mind that when I generate the vector grid (be it horizontal, vertical or diagonal) I take care a priori of reversing the direction between even and odd lines of generated segments, so it is in the natural order of things that near the end of a segment there is the start of a subsequent segment. |
As the curve is flipped it always the AB-AA case to be consider
Probably using Diagonal Cross Fill was not a good choice for test.. actually I was already flipping the curve so messing with cases.
I've try to use the OptimizeFillingPaths with the RAS sample, but still I can't reproduce the crazy G2/G3 behavior you show: Only missing a sector in the inside of the A hole ( still to investigate) |
Did you switch on "Smoothing" flag? I think that Potrace is not producing arcs without "smoothing" flag. |
A final consideration: every time there is a change of direction, grbl has to decelerate the movement to zero speed, for obvious physical reasons, then it can restart in the new direction with an acceleration ramp up to the target speed. In the real world this often causes that, the advantage given by looking for the nearest segment, compared to continuing in the same direction but with a further segment, is not as high. In fact, sometimes performance can even decrease. Obviously this phenomenon is quite complex to take into account, largely depending on how fast or not the deceleration can be (machine configuration) as well as the "rapid movement" speed (other machine configuration) and the distance to travel on the rapid movement. |
Taking a simply approach based on specific ouput of potrace
Seems like a typical Rabbit Hole 😄 , and probably a simply approach is better. Please check with your case if everything is producing valid results. |
My fault, i forget that potrace gives bezier as output. Well... I see that the last code you commit does not invert: in my opinion it is the best thing (and no problem with the bezier).
Well, I've done some tests and it seems to me that everything is almost ok. I saw that there was a list inversion in the GCODE export function, and a list inversion in the optimize function. Maybe two inversions are useless ... better none, or just one inversion in the right place (assuming it serves).
I like digging in rabbit hole, so I try to put an optimization that can take into account the direction change. In any case it is not easy to calibrate this "weight" because a lot depends on the distance between the filling lines, which is tightened by increasing the resolution of the filling, while the distance between segments "on the same direction" is always the same and depends on how the image is made. As already mentioned, the goodness of this optimization it also depends on acceleration and speed. |
if you want to test the "direction change" weight the line of code is
|
Hi @HomineLudens Am I right with my assumptions in last post? |
I think the mechanical considerations are plausible. |
Method is quite long now and maybe It could benefit of some support functions.
I didn't' measure performance and I can't obtain some G2/G3 curve from the potrace output (is there any option to activate that?) to verify the Arc problem.
2021-01-06.11-32-45.mp4