[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: teardrops plug-in for PCB
> > > Wow! Combine that with the "puller" and the traces will start to
> > > resemble the old hand-drawn boards.
> >
> > Yeah, I need to work out the last of the bugs in the puller (or talk
> > some math major into helping ;).
>
> what are you having trouble with?
http://www.delorie.com/pcb/puller.diff.txt
Of the fixmes listed:
/* FIXME: Things that need to be fixed before this is "perfect".
Add to this list as we find things.
- respect the outline layer.
- don't consider points that are perpendicular to our start_arc.
I.e. when we have busses going around corners, we have a *lot* of
arcs and endpoints that are all in the same direction and all
equally "good", but rounding the arc angles to integers causes
all sorts of tiny differences that result in bumps, reversals,
and other messes.
- Store the X,Y values in our shadow struct so we don't fill up the
undo buffer with all our line reversals.
- at least check the other layers in our layer group.
The second one is the heavy math one. Basically, for each pair of
lines that meet at a point, I form a triangle from those lines. I
scan for "things" within the triangle, and keep track of the one with
the biggest angle away from the far point, for each of the two lines.
I.e. consider you're "at" the end of one line, facing the other
(common) end. The far end of the other line is to your left. So,
find the rightmost of the things that are "in your way" and rotate
your line over so that it's that far over - as far left as you can go
without hitting something. Then we arc around that thing and recurse.
Now consider when the "thing" you're hitting is a line that connects
with an arc, as if you're part of a bus. By definition, the line will
be parallel to you, so both the line's endpoint and the arc's endpoint
are equally "best". Ideally, we want to have just one arc per corner,
but what happens is that since the arcs have *integer* angles, the
intersection isn't mathematically perfect and we end up adding
multiple segments each time, and the count grows as you layer on more
bus lines.
Worse, the truncating to integer thing causes us to see some things
"behind" us (vector-wise), and we end up drawing circles around stub
traces and other humorous things. There needs to be a lot more
vector-based checking at each intersection for these special cases so
that the results end up being "clean".
Apply the above patch (hopefully it still applies) and run it on a
board with a bus (":GlobalPuller()"). If it doesn't crash pcb due to
memory overload, the results look like a two year old drew them with a
crayon.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user