[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[help-3dldf] Re: Helices.
From: |
Laurence Finston |
Subject: |
[help-3dldf] Re: Helices. |
Date: |
Sun, 29 May 2005 17:44:32 +0200 |
User-agent: |
IMHO/0.98.3+G (Webmail for Roxen) |
-------------------
> On 5/28/05, Laurence Finston <address@hidden> wrote:
> > You might want to take a look at
> > L. Nobre G.'s FEATPOST package He [...]
> > may have implemented helices.
>
> Well, thanks but not really.
> The first example in
> http://matagalatlante.org/nobre/featpost/doc/featexamples.html
> is a double closed helical path but besides being cyclic each path is
> defined by a specific parametric equation.
> The examples
> inductionbob.mp
> and
> parafuso.mp
> contain open helical paths but these are not automatically hidden-lined.
> So, in fact, I have not implemented generic open-paths, much less
> recursive path definitions...
>
> Greetings
> --
> L. Nobre G. - http://matagalatlante.org/nobre/WebRing.html
Oh well, it was just a thought. However, it demonstrates that it's
possible using MetaPost, and anything that's possible with MP is
by definition possible with 3DLDF --- either because I've implemented
it or via the 'verbatim_metapost' command.
It would also be possible, and perhaps even desirable, to have 3DLDF write MP
code using FEATPOST's macros, but I'll probably never get around to working on
this myself. My stack of notes for features I want to implement, going back 3
years, is just too thick.
Once helices were defined, I'm pretty sure that defining multi-level helical
structures would be a snap. It would probably be better to do this in C++,
but it might work with macros. I myself will probably not implement many
features as macros, because it's just as easy for me to implement them as
primitives and they're more efficient. I'm also more concerned with basic
functionality than higher level features that, in my opinion, should be
implemented as macros. For example, I think the tesselation and epicycloid
patterns from 1.1.5.1 should be implemented as macros.
The real problem will be surface-hiding, but that's a problem for all
geometric figures. I will certainly try to solve it for convex plane
polyhedra, circles, ellipses, cuboids, and spheres before I try to solve it
for helices. Solving it requires two things: 1. being able to determine
whether an object of a given type is still of the shape indicated by the type
name, i.e., whether a 'circle' is really circular and 2. being able to find
the intersections of two geometric figures. Depending on the figures, the
intersections might be points, lines, planes, curves, or surfaces. If I ever
implement n-dimensional figures for n > 3, intersections could also be figures
of dimension >= 3. Point 1 is also a bit more complicated. For example,
since a 'circle' could have become elliptical by means of a transformation,
the intersections with another figure could be found by treating it as an
ellipse. The obvious way of defining helices is by means of a parametric
equation, and unlike implicit equations, these are not suited to finding
intersections by means of substitution. So at present, I don't know how to go
about doing it. In my opinion, this is a research project rather than an
exercise.
One possibility would be to have 3DLDF write OpenGL code rather than (or in
addition to) MetaPost code. Denis Roegel has recently published a paper about
doing this in his own package (another 3D package involving MP). I've looked
into this, but decided that if I work on this at all, I'd rather have 3DLDF
write code for a ray-tracer than for an OpenGL or Renderman renderer. Even
under more favorable circumstances, this isn't something I plan to work on
soon. There are many features that I consider more important, and especially
vector-based surface-hiding that will work with MP output.
Laurence