[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[help-3dldf] Re: [metafont] Re: button-hole problem

From: Laurence Finston
Subject: [help-3dldf] Re: [metafont] Re: button-hole problem
Date: Tue, 26 Apr 2005 23:41:13 +0200
User-agent: IMHO/0.98.3+G (Webmail for Roxen)

From: Dan Luecking <address@hidden> 

> At 02:17 PM 4/25/2005, you wrote:
> >However, I'm still a bit at sea about the problem of finding equations
> >(implicit and/or parametric) for the projections
> You have not made it clear what the input data is (i.e., how a particular
> conic section is to be described). 

In order to explain this, I must explain a little about the C++ implementation
of the GNU 3DLDF interpreter.  Most data types in the 3DLDF language
correspond to classes in the C++ code, e.g., `point' corresponds to `class
Point', `path' to `class Path', etc.  `class Ellipse' is derived from `class
Path', so an `ellipse' is a kind of `path'.  `Paths' contain a
`vector<Point*>' and a `vector<string>' for the connectors.  The only
connectors that currently make sense in 3DLDF are `..', `...', `--', and
`---'.  It doesn't make sense to implement `tension' until I've made more
progress on `class Nurb'.  In addition to the vectors, `Ellipses' contain the
following data members:

Point focus0
Point focus1
real linear_eccentricity
real numerical_eccentricity
real axis_h
real axis_v

Declarations in 3DLDF are analogous to those in Metafont, so the result of the

ellipse e;

is an "unknown ellipse".  `ellipses' can be "made known" by assigning from
`unit_ellipse', which is a predefined `ellipse variable', or by using a `set'
command, of which this is the syntax:

set_command: SET ellipse_variable with_center_optional with_axis_h_optional
with_axis_v_optional with_point_count_optional with_normal_optional

So if I set `e' as follows:

set e with_point_count 32;

it will have its center at the origin, its horizontal and vertical axes will
both be 1.0, it will have 32 points, and it's normal will be (0, 1, 0).  It's
foci, linear eccentricity and numerical eccentricity will be calculated by the
`Ellipse::set()', which is called in the action for this parser rule.

The `Ellipse' constructors and setting functions use the parametric equation
for an ellipse to find the desired numbered of points in the x-z plane, using
the origin as the center.  Subsequently, the `Ellipse', i.e., the center,
foci, and the points representing the perimeter, are rotated about the x, y,
and z-axes, in that order, by the amounts specified by `real' arguments to the
function, if any of them is non-null.  Unlike the `set_command', the `Ellipse'
constructors and setting functions do not take a `Point' argument for a normal
vector yet, so this information must be extracted from the normal `Point' used
in the `set' rule, if any.

Incidentally, I use the explicit equation (correct term?) for the ellipse for
finding the intersection of an ellipse with a line, i.e.,
$x^2/a^2 + y^2/b^2 = 1$ where $a$ is half the horizontal axis
and $b$ is half the vertical axis, so one representation doesn't seem to be
enough for all purposes.

Each of the `Points' pointed to by a pointer on the `vector<Point*>
has its own `transform' data element, of type `class Transform'.  I've been
thinking about changing this, but I think it would be very handy to be able to
transform the individual `Points' on `ellipses', `circles', `polygons', etc.,
rather than only being able to transform the whole object at once.  I may
replace `Transform Point::transform' with `Transform* Point::transform', and
only allocate memory for a `Transform' when needed, but making this change
will require 
great care.

> Perhaps you can get something out of the 
> following:

It's very helpful, thank you very much.

> >and finding the intersections
> >of conic sections.
> I guess here you mean solving two simultaneous equations, each of which is
> a quadratic in x and y. 


> I'm sure there are well know numerical recipes for
> that sort of thing. I don't believe there are any directly usable formulas
> for the intersection points.

I was afraid of that.  I currently use binary search to find the intersections
of two `Ellipses', but it's a bit slow.  I've implemented an algebraic
solution for two `Circles', since this is so easy.  Martijn van Manen has
given me some material about finding the intersections of two ellipes
algebraically, but he uses some mathematical concepts that I don't understand.
 I'm working on it.

Thanks again, as always, for your help.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]