Hi
No - I just havn't managed to find the time. I have too many projects and not enough time.....
It is still on my to-do list.
Regards
Andrew
Hi
No - I just havn't managed to find the time. I have too many projects and not enough time.....
It is still on my to-do list.
Regards
Andrew
I am thinking at the moment it might be as fast or faster to write it from scratch.... been resarching the math all week. Right now I can offset lines, arcs and fillet two lines easily enough. Where I am stumped is filleting two arcs or a line and arc combo. I have some pretty robust geometry entit classes with WPF graphics support (for verification). Once the remaining filleting operations are implemented I will be happy to share. Any help is greatly apreciated. .... Back to the math lab
I worked a lot in the 90's trying to write an offset for my Lcam program. I had a basic one but would make loops when the cutter went into some tight places with a lot of small vectors.
I write in Delphi, are you using C+ ?
I figured out now, how to make a perfect offset and how they do it in Corel draw using a thick line to clear the path of any loops and knots. I just don't have the time or mental ambition right now to code it.
There are a lot of tricks to analyze vector chains. I know how to determine path direction, whether one chain is inside an other etc.
Check out my StarCam. Its layout program for CNC that goes in front of my CNC controller. I would like to add a Cutter offset some day and a Fill routine.
http://www.larkencnc.com/dloads/index.shtml
I'm possibly looking for some one to write an offset for it in Delphi
Larry K
Manufacturer of CNC routers and Viper Servo Drives
www.LarkenCNC.com and www.Viperservo.com
any progress on your code? I'm also writing a 2.5d cam program, and offsets have caused a lot of headaches. From a cursory look at libarea, they seem to be breaking the paths into points, and matching lines and circular arcs to the points?
The approach I've gone with is to approximate the path with biarcs and lines, and offsetting the resulting approximation. This makes things a lot simpler because unlike beziers, biarcs and lines have exact offsets.
The problem lies in eliminating self-intersections of the offset path. Right now I'm doing a brute force thing - find all intersections and eliminate segments based on the normal of the offset path, but clearly this is an O(n^2) operation and not optimal.
I wonder how commercial cam packages do it. I've read things about voronoi diagrams and distance maps, but the math is a bit over my head..
I'm also curious about efficient algorithms for computing path winding direction. I know about the point in polygon method, but what if you don't have a point? The method that comes to mind involves calculating the polygonal area and checking whether it's positive or negative. Is there a more efficient approach?
___________________________
http://jack.works
I guess you know some of the tricks.
- First make contours closed.
- Make your contour CW
- Offset the chain of arcs and lines.
- You can Find all intersections using line intersect routines
- create closed contours of all intersection loops
- Bad loops will be CCW (erase them)
Breaking objects to points is not the way to go. Its very slow cam programs don't do it this way.
Here is my intersection procedure (pascal) for lines. I wrote this years ago.
Procedure intersect(xa1,ya1,xa2,ya2,xb1,yb1,xb2,yb2:real;onl ine:boolean);
var xla,xlb,ma,mb,a1,a2,b1,b2,cc1,cc2,det:real;
begin
parallel:=false; linescross:=false;
xla:=xa2-xa1; xlb:=xb2-xb1;
if (xa1-xa2=0) and (ya1-ya2=0) then parallel:=true;
if (xb1-xb2=0) and (yb1-yb2=0) then parallel:=true;
if (xla=0) or (xlb=0) then
begin
if (xla=0) and (xlb=0) then parallel:=true;
if parallel=false then begin
if xla<>0 then
begin
ma:=(ya2-ya1)/(xa2-xa1);
cc1:=ma*xa1-ya1;
yint:=ma*xb1-cc1; xint:=xb1;
end else
begin
mb:=(yb2-yb1)/(xb2-xb1);
cc2:=mb*xb1-yb1;
yint:=mb*xa1-cc2; xint:=xa1;
end;
end;
end
else begin
ma:=(ya2-ya1)/(xa2-xa1); mb:=(yb2-yb1)/(xb2-xb1); b1:=-1; b2:=-1;
if abs(ma-mb)<0.00001 then parallel:=true;
cc1:=-(ma*xa1-ya1); cc2:=-(mb*xb1-yb1);
det:=((ma*b2)-(b1*mb));
if det<>0 then begin
xint:=((cc2*b1)-(cc1*b2))/det;
yint:=((cc1*mb)-(ma*cc2))/det;
end
else parallel:=true;
end;
if (not parallel) and online then {check if intersect is in range of LINE }
begin
if ((xint>=xa1) and (xint<=xa2)) or ((xint>=xa2) and (xint<=xa1))
then if ((yint>=ya1) and (yint<=ya2)) or ((yint>=ya2) and (yint<=ya1))
then if ((xint>=xb1) and (xint<=xb2)) or ((xint>=xb2) and (xint<=xb1))
then if ((yint>=yb1) and (yint<=yb2)) or ((yint>=yb2) and (yint<=yb1))
then begin linescross:=true; end;
end;
end;
Larry K
Manufacturer of CNC routers and Viper Servo Drives
www.LarkenCNC.com and www.Viperservo.com
Hi Andrew,
I am writing a c# program that reads DXF lines and I need to work out how to offset these lines and how to do pocketing of the geometry. Do you have any C# methods or library that you could pass on so that I can just pass through a set of lines/arcs and get a a set of lines/arcs that have been offset?
Also, do you have any other methods that are robust enough to find intersection points of arcs and lines? I keep running into issues when arcs and lines are tangent and other similar issues. Most of the methods I have found out there are for Polygons but they don't work for arcs or circles which is what we have with DXFs.
I know that you worked on this a long time ago so I was hoping you have resolved these issues and might be able to same me a lot of time.