[help-3dldf] Re: Rotations

[Hans Aberg]

At 00:36 +0200 2004/08/17, Laurence Finston wrote:
>> You have some conflicting requirements, exactitude and speed. My
>> guess is
>> that speed will be the most important in graphics, and thus, you will be
>> stuck with using 64-bit floats.
>
>It will depend on the particular task being done at a given time.   If it
>happens to be real-time rendering, then (expressed loosely) speed will be more
>important than precision.  However, one of my particular mathematical
>interests is intersections (at the level at which I am able to pursue
>mathematics), and I'd like to implement functions in 3DLDF for finding the
>intersections of various curves and other geometric figures.
>So if this is the task, then precision will be more important than speed.

My hunch is that this, finding exact intersections, is not a topic for a
graphics program, but a wholly independent set of programs, belonging
currently to the area of symbolic math and specialty programs for algebraic
geometry. The reason for this is that one then has to work with essentially
real or complex numbers (perhaps restricted to algebraic ones), and there
is no good computer representation for those. Check in the newsgroups
sci.math.symbolic and sci.math. (There is also a newsgroup
sci.math.num-analysis.)

So for the exact intersection problem, I think that one will have to work
it out in other programs, and then, when that work is finished, one exports
it to a graphics program. Computers and computer software technology is
probably not mature enough to integrate it.

>> An idea to find such an epsilon might be as follows: Your graphics will be
>> printed by at most 2400 points/inch, and of largest size 10 inches, so this
>> gives perhaps about 10^4 points in your graphics, say 10^5 to be sure. How
>> many components will your graphics have? Probably not more than 10^5. Then
>> your epsilon will be around 10^(-10) in relative error. Then 64-bit floats
>> have an accuracy of 15-16 decimals, giving room for about 10^5-10^6
>> floating point operations. So this should be enough even in heavy computing.
>>
>
>The number of points and  components, and the size of the graphics could be
>very much greater than what you suggest.  Reflections, in particular, can
>cause the number of points and components to increase exponentially, so I'll
>have to limit the "depth" of reflection, i.e., the number of times reflections
>are reflected.

I do not see why you get so many points: I just thing of the points
defining the curves in say a NURBS model. These should be fairly few. These
are ones want to agree. Then, once this geometric object has been modelled,
the rendering only takes place within what is possible on the output device.

>For both `float' and `double', I use values of epsilon that seem to work, but
>I've never had a chance to test them.  I've mentioned this in the manual and
>asked for feedback about this, but I haven't gotten any.

The only other alternative would be to use a multiprecision package as GMP,
but then I think speed will take a heavy beating. GMP is otherwisefairly
easy to use.

  Hans Aberg