help-3dldf
[Top][All Lists]
Advanced

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

[help-3dldf] Re: Your FEATPOST website


From: Laurence Finston
Subject: [help-3dldf] Re: Your FEATPOST website
Date: Sat, 11 Dec 2004 22:12:18 +0100
User-agent: IMHO/0.98.3+G (Webmail for Roxen)

> Lu\'{\i}s Nobre Gon\c{c}alves wrote:

> 
> Yes, you have my permission. I will also subscribe that list.

Thanks.

> 
> Yes but which ways are these? In FeatPost I sort only by distance from the
> point of view (or "null").

The four ways of sorting objects are:

1. Not sorting them, i.e., outputting MetaPost code for them in the order the
drawing commands appear in the C++ code (in the older versions) or in the
input in the 3DLDF language (new version).  

2.  Sorting them by the z-coordinate of greatest magnitude of all of the
`Points' belonging to each object.  

3.  Sorting them by the z-coordinate of least magnitude.

4.  Sorting them by the mean of the z-coordinates of greatest and least
magnitude.

I explain the details, and why my method _cannot_ work for some cases in the
manual:
http://ftp.gwdg.de/pub/gnu2/3dldf/3DLDF/Surface-Hiding.html#Surface%20Hiding

> > Roughly, I plan to do this by dividing objects until there
> > are none that intersect, removing the ones that are completely covered by
> > other objects, and drawing the rest in order.  This is one reason I'm so
> > interested in intersections.
> 
> This will not be limited to polyhedric objects?
> 

No.  I will do it for as many types of object as possible.  For circles and
ellipses it will be tricky, because if they have to be divided too many times,
I will end up with very short arcs with lots of points.  This is another
reason for implementing NURBs.

> > > The input routine that you are working on accepts plain MetaPost code?
> >
> > Unfortunately not.  It might be possible to set things up so that 3DLDF
can
> > process code written in a subset of the Metafont and MetaPost languages.
> > I originally wanted any valid MF or MP input to be valid in 3DLDF, and
with
> > the same interpretation, but I don't believe it will be possible to
implement
> > this.
> 
> But, for starters, there could be a "brute force" solution like ignoring
> MetaPost code on input and just copying it to the output.

Yes, this would be easy, if marking it were allowed, e.g.:

start_metapost;
%% [...] Raw MetaPost code.
end_metapost;

If you want this, I'll do it.  It shouldn't take long.
I wasn't really expecting you to use my software, seeing as how you have your
own package, but it would, of course, be nice if you did.
Having the parser recognize invalid constructions by itself would not work. 
This topic has come up on the Bison mailing list before.

> Thanks for the references.

You're welcome.  Cundy and Rollet has been one of my favorite books since my
school days.

> 
> Well, I wrote FeatPost in MetaPost because I wanted to keep its machinery
> and you wrote 3DLDF in C++ because you wanted to keep its arithmetic
> power, right?

I wanted to use MetaPost for 3D drawing but I didn't see any way of overcoming
the very strict limits on the magnitude of `numeric' expressions that Knuth
built into Metafont.

> I would really like to have some merging before 3DLDF completely emulates
> the behaviour of MetaPost but I'm willing to wait for a totally vectorial
> 3D graphics machine, whatever its language.

What sort of merging do you have in mind?  We've both put our packages under
the GNU GPL, so we are, of course, free to use each other's work in any way
consistent with that license.
I would be very interested in reading your macros and finding out how they
work. However, I'm still implementing basic functionality and it will be
awhile before
I get to higher-level features such as macros.  I have an idea of how to
implement them, but it won't make it into the next release.  It would,
however, be easy to write parser rules for having 3DLDF write MetaPost code
that accesses your macros, if this was useful.

I like vectors, too.  I think using algebra gives more scope for cleverness,
whereas operating on pixel or voxel data seems to me to be more of a
brute-force approach.  However, many standard methods assume that the data has
been rasterized.

Laurence



reply via email to

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