Re: 3DLDF

[Hans Aberg]

At 22:41 +0200 2004/08/13, Laurence Finston wrote:
>> I am inclined to think that you should skip all attempts to make it similar
>> to the MetaFont language, and merely make it efficient to describe
>> geometric shapes as you can see fit. Then you can use that geometric
>> language as object code of another language that might then be similar to
>> the MetaFont language if you so wish.
>>
>
>The whole point of the GNU 3DLDF project is to implement a free  (in the sense
>of the GNU General Public License) Metafont-like language for creating 3D
>graphics.  I do plan to implement a machine-like language for fast-loading
>format files, analogous to the languages used in the TeX and Metafont format
>files created by INITEX and INIMF, respectively.  If I (or another member of
>the project) ever gets around to implementing a GUI, I intend that it pass
>binary code in this machine-like language to the 3DLDF program proper.  I
>suppose I could call the latter an "engine" in this context.  I think this
>machine-like language would be better suited as the basis for implementing the
>kind of generality you're talking about.  At the moment, I'm more concerned
>with the forthcoming release.

The intermediate language I think of would merely be efficient in picking
together the C++ objects, which later are used to produce the output.

>> Sorry, I do not know what NURBS is. And what do you mean by "projectively
>> affine"?
>>
>
>NURBS are non-rational uniform b-splines.

And b-splines are (as opposed to splines or Bexier curves)? And what
non-rational and uniform mean here?


>  I don't have my books on 3D
>graphics handy, so please excuse any lack of rigor in the following
>definition.  "Projectively affine" means that if I have a spline curve P
>determined by a set of key points p_0, p_1, ... p_n in 3-dimensional space,
>and I project these points onto a two-dimensional surface using a non-affine
>projection, such as the perspective projection, the spline curve Q determined
>by the projections of p_0, p_1, ... p_n, namely q_0, q_1, .. q_n,
>is identical to the curve generated by performing the same projection on all
>of the points on P.

OK. This is something that I thought you meant: If is of course clear that
(in general) polynomial degree is not preserved when mapping under
non-linear mappings, and polynomiality is not preserved under
non-polynomial mappings. But on the other hand, higher degree (>3)
polynomials are supposed to not be so useful in modelling. So it might be
better to find some good approximations.

>> It clearly so that in some computer language paradigms, the word "real" is
>> used instead of the mathematically correct term "float". C/C++, however, do
>> it correctly.
>
>The kinds of numbers I'm familiar with from mathematics are natural, whole,
>rational, real, complex, and imaginary.  I'm only familiar with the terms
>fixed point and floating point in the context of discrete mathematics and the
>representation of real numbers in computers.

The mathematical real numbers can be represented in computers, in theorem
provers and to some extent, symbolic algebra programs. But when
approximated by floats, it is not an exact representation of mathematical
real numbers anymore. So that is why I do not like the notions to be mixed
up in computers. But this is not an important matter.

>I wanted to make it possible for users to decide whether they'd rather have
>greater precision or lower memory requirements.  One reason for needing
>greater precision is the inaccuracy resulting from the use of the
>trigonometric functions for rotations.

It sounds as you are making a program for archaic computers :-): Most
computers, PC and up, have a FPU which computes with 64-bit IEEE floats
(typically a "double" in C on a 32-bit computer), and memory is not anymore
an issue in normal use. And one is now shifting to genuinely 64-bit CPU's
on the PC level (as the Mac G5).

So it seems best, on a 32-bit architecture, to merely use double's for
floats. This will give the accuracy. If you want speed, you might want to
look at the GNU GMP, which has assembler code for certain basic operators.
Also, I know there has been discussions in comp.lang.c++.moderated about
graphics packages, which should optimize the things you want to optimize.
You may want to check out those.

>  I've started looking into quaternions
>in hopes that they may help me solve the problem.

The quaternions were created in order to describe 3D-rotations, but the
underlying math will be the same as if you work with matrices. So I am not
sure you want to get out there. And quaternions do not work in dimensions >
3. (There is an analogue in 7 dimensions; its 8-dimensional Cayley algebra
is not associative. But there is no analogue in other, higher dimensions.)

  Hans Aberg