2011/7/17 DJ Delorie :
>
>> What is the transform between the numbers in the .pcb file and the
>> actual representation on the board?
>
> Angle first, then stretch.
There must be something more to it.
Attached are two hand edited drawings where the first one has no stretching,
e.g Radius=Width=Hei
On Sat, 2011-07-16 at 19:16 +0200, Karl Hammar wrote:
> Stefan Salewski:
> > http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf
>
> It seems a little too general and it is a 35MB download [1].
> Their code seems to be in
>
> LibMathematics/Intersection/Wm5IntrEllipse2Ellips
> What is the transform between the numbers in the .pcb file and the
> actual representation on the board?
Angle first, then stretch.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
2011/7/16 DJ Delorie :
>
>> It would be good if someone could tell me how the arc parameters
>> are created and how they are used.
>
> Edit the *.pcb file manually.
OK, but that means I need to understand how the drawing
mechanism interprets ther numbers.
Currently with the stretched arcs you pres
> It would be good if someone could tell me how the arc parameters
> are created and how they are used.
Edit the *.pcb file manually.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
2011/7/16 DJ Delorie :
>
> My quick take on this:
>
> Do the math based on a zero-thickness arc, then offset the resulting
> distance by the arc half-thickness.
>
> I think this is more in line with how we *draw* the arcs.
I have not yet investigated on how the arcs are draw nor how
they are beein
Stefan Salewski:
> http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf
It seems a little too general and it is a 35MB download [1].
Their code seems to be in
LibMathematics/Intersection/Wm5IntrEllipse2Ellipse2.cpp
and at a quick glance it seems to be a lot of calculations.
My quick take on this:
Do the math based on a zero-thickness arc, then offset the resulting
distance by the arc half-thickness.
I think this is more in line with how we *draw* the arcs.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.s
On Sat, 2011-07-16 at 00:18 -0700, Andrew Poelstra wrote:
>
> There is a fairly informative discussion of this problem on SO:
> http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle
>
Or you may look at
http://www.geometrictools.com/Documentati
2011/7/16 Karl Hammar :
> Because of false assumptions about the "inner" and "outer" arcs, see
> below.
Ahhaaa, I stand corrected, assumptions is never ever good and it should
have been obvious when making the thickness large, e.g if as large as the
short axis it would generate a inner 'not ellips
Igor Lopez:
> 2011/7/16 Andrew Poelstra :
> > There is a fairly informative discussion of this problem on SO:
> > http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle
>
> I had a look and found one algebraic solution close to the one I have
> pro
2011/7/16 Andrew Poelstra :
> There is a fairly informative discussion of this problem on SO:
> http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle
I had a look and found one algebraic solution close to the one I have proposed.
> The correct met
On Fri, Jul 15, 2011 at 09:45:42PM +0200, Karl Hammar wrote:
> Andrew Poelstra:
> > I am using the polar form of the ellipse given at:
> >
> > http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center
> >
> > with theta the angle of the point we are checking. (Those cos
> > and sin calcu
Andrew Poelstra:
> I am using the polar form of the ellipse given at:
>
> http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center
>
> with theta the angle of the point we are checking. (Those cos
> and sin calculations are easy, just delta-x/len and delta-y/len.)
> With that I can calc
I am using the polar form of the ellipse given at:
http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center
with theta the angle of the point we are checking. (Those cos
and sin calculations are easy, just delta-x/len and delta-y/len.)
With that I can calculate the distance from the po
Ethan Swint:
> On 07/14/2011 11:23 PM, Andrew Poelstra wrote:
...
> > To do either one analytically looks like a 4th order
> > equation must be solved. So I am looking for cheap
> > iterative solutions, or approximations, instead.
>
> If the point is within the arc's bounding box, transform the poi
Andrew Poelstra:
> On Thu, Jul 14, 2011 at 08:29:53PM +0200, Karl Hammar wrote:
...
> > Why not just give a warning if width and height is not equal, saying
> > that we don't really support ellipses for the moment, and be done with
> > it.
> I could, I suppose, but as you mentioned in another post,
On 07/14/2011 11:23 PM, Andrew Poelstra wrote:
On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote:
Check if point px,py is on rotaded elliptic arc:
1) Translate point to use ellipse center as origin,
Px = px-x
Py = py-y
2) Insert Px, Py in Eq1
lval equal 0 -> point is exactly on arc
On Jul 14, 2011, at 1:09 PM, DJ Delorie wrote:
>
>> The linear "stretching" transformation (x', y') = (a*x, b*y) applied
>> to a circle yields an ellipse whose axes are parallel to the
>> coordinate axes.
>
> Yes, *unless* you're including the start/end angles in that
> transformation, instead
Igor:
> 2011/7/14 Karl Hammar :
> > Looking at pcb.pdf, page 64, section 8.8.1 Arc...
...
> > And there is no way to specify a "slanted" ellipse in the file format
> > either, so if we really want ellipses, the file format is incomplete
> > and should be changed.
> >
> > Why not just give a warning
> The linear "stretching" transformation (x', y') = (a*x, b*y) applied
> to a circle yields an ellipse whose axes are parallel to the
> coordinate axes.
Yes, *unless* you're including the start/end angles in that
transformation, instead of applying them afterwards.
http://www.delorie.com/pcb/tmp
On Jul 14, 2011, at 12:00 PM, DJ Delorie wrote:
> Technically, what we have is *not* an ellipse - it's a stretched arc.
?
The linear "stretching" transformation (x', y') = (a*x, b*y) applied to a
circle yields an ellipse whose axes are parallel to the coordinate axes.
John Doty N
> According to the manual ( I just checked) Arc is just a quarter
> circle even though it is overspecified in terms of parameters.
> Ellipses are not mentioned.
Technically, what we have is *not* an ellipse - it's a stretched arc.
___
geda-user mailin
2011/7/14 Karl Hammar :
> Looking at pcb.pdf, page 64, section 8.8.1 Arc...
>
> Andrew Poelstra:
> ...
>> If you have a full ellipse, then Width and Height are exactly
>> what they sound like -- the full length from one side of the
>> ellipse to the other.
>
> The file format specifies it as:
>
>
On Thu, Jul 14, 2011 at 08:29:53PM +0200, Karl Hammar wrote:
> Looking at pcb.pdf, page 64, section 8.8.1 Arc...
>
> Andrew Poelstra:
> ...
> > If you have a full ellipse, then Width and Height are exactly
> > what they sound like -- the full length from one side of the
> > ellipse to the other.
>
Looking at pcb.pdf, page 64, section 8.8.1 Arc...
Andrew Poelstra:
...
> If you have a full ellipse, then Width and Height are exactly
> what they sound like -- the full length from one side of the
> ellipse to the other.
The file format specifies it as:
Width Height
The width and height, f
2011/7/15 Andrew Poelstra :
> On Thu, Jul 14, 2011 at 03:48:24PM +0200, Igor Lopez wrote:
>> I had a quick look at the routine and must say that I did not grasp
>> the code. It is probably due to some heavy optimizations.
>>
>
> Heavy optimizations, perhap, but also because it is wrong.
>
>
> If yo
On Thu, Jul 14, 2011 at 03:48:24PM +0200, Igor Lopez wrote:
> I had a quick look at the routine and must say that I did not grasp
> the code. It is probably due to some heavy optimizations.
>
Heavy optimizations, perhap, but also because it is wrong.
If you have a full ellipse, then Width and
2011/7/15 Andrew Poelstra :
> On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote:
>>
>> Check if point px,py is on rotaded elliptic arc:
>> 1) Translate point to use ellipse center as origin,
>> Px = px-x
>> Py = py-y
>> 2) Insert Px, Py in Eq1
>> lval equal 0 -> point is exactly on arc
>>
On Thu, Jul 14, 2011 at 01:24:45PM +0200, Karl Hammar wrote:
> Andrew Poelstra:
> > On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> > > Mark Rages wrote:
> > > > Stretched arcs are a misfeature. Can they be deprecated?
> ...
> > The reason I bring this up is that the IsPointOnA
On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote:
>
> Check if point px,py is on rotaded elliptic arc:
> 1) Translate point to use ellipse center as origin,
> Px = px-x
> Py = py-y
> 2) Insert Px, Py in Eq1
> lval equal 0 -> point is exactly on arc
> lval above zero -> point is inside
I had a quick look at the routine and must say that I did not grasp the code.
It is probably due to some heavy optimizations.
My approach had been more in the line of:
// Assumption done on ArcType in that the StartAngle attribute is the
// arcs CCW rotation with zero meaning that attribute Width
Andrew Poelstra:
> On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> > Mark Rages wrote:
> > > Stretched arcs are a misfeature. Can they be deprecated?
...
> The reason I bring this up is that the IsPointOnArc() in search.c
> assumes a circular arc right now. ("Distance from elli
2011/7/14 Andrew Poelstra :
> On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
>> On Wed, 13 Jul 2011 10:02:28 -0600
>> Mark Rages wrote:
>>
>> > Stretched arcs are a misfeature. Can they be deprecated?
>> >
>> > Otherwise, they are just another object that cannot be rotated at
>>
On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> On Wed, 13 Jul 2011 10:02:28 -0600
> Mark Rages wrote:
>
> > Stretched arcs are a misfeature. Can they be deprecated?
> >
> > Otherwise, they are just another object that cannot be rotated at
> > arbitrary angles.
>
> There is
On Wed, 13 Jul 2011 10:02:28 -0600
Mark Rages wrote:
> Stretched arcs are a misfeature. Can they be deprecated?
>
> Otherwise, they are just another object that cannot be rotated at
> arbitrary angles.
There is no inherent reason elliptical arcs cannot be rotated
arbitrarily. Any restriction
On Wed, Jul 13, 2011 at 10:02:28AM -0600, Mark Rages wrote:
>
> Stretched arcs are a misfeature. Can they be deprecated?
>
Why are they a misfeature?
> Otherwise, they are just another object that cannot be rotated at
> arbitrary angles.
>
That's a separate problem.
--
Andrew Poelstra
Emai
On Wed, Jul 13, 2011 at 5:46 AM, Kai-Martin Knaak wrote:
> Andrew Poelstra wrote:
>
>> Arc[18 15 10 15 5 2000 90 90 "clearline"]
>>
>> will show the arc as a quarter-circle with GL enabled, even
>> though it is actually taller than it is wide.
>
> confirm.
>
> PCB v20100929-2
Andrew Poelstra wrote:
> Arc[18 15 10 15 5 2000 90 90 "clearline"]
>
> will show the arc as a quarter-circle with GL enabled, even
> though it is actually taller than it is wide.
confirm.
PCB v20100929-2 as delivered by debian renders the stretched arc
correctly.
---<)kai
Peter,
Not sure if you are aware, but latest pcb with gl enabled
does not render stretched arcs properly. For example, a
pcb with
Arc[18 15 10 15 5 2000 90 90 "clearline"]
will show the arc as a quarter-circle with GL enabled, even
though it is actually taller than it is
40 matches
Mail list logo
