POV-Ray : Newsgroups : povray.binaries.images : Mesh lathe Server Time
16 Aug 2024 12:29:37 EDT (-0400)
  Mesh lathe (Message 11 to 14 of 14)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Lutz-Peter Hooge
Subject: Re: Mesh lathe
Date: 24 Feb 2002 17:43:41
Message: <MPG.16e38b2bf2188b49896e3@news.povray.org>
In article <chr### [at] netplexaussieorg>, 
chr### [at] maccom says...

> Better would be to make it dependant on the distance along the 
> spline...

Yes, but thats not as easy to calculate. And it will be alway bigger or 
equal to distance between the points, so there isn't the danger of 
accidently taking a too large epsilon.

> Not really. Patches are converted to triangles for intersection testing, 
> but they can do adaptive subdivision on the fly,

I thought the subdivision is only perfomed once, when generating the 
triangles (unless type 0 is used)

> It is harder to connect them  smoothly, as well.

This may be true in general, but for just building a lathe shape it isn't 
a problem.

Lutz-Peter


Post a reply to this message

From:
Subject: Re: Mesh lathe
Date: 25 Feb 2002 00:27:29
Message: <3c79cb41@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c7940df@news.povray.org...

> > I remember from my Numerical Analysis courses, that some authors
recommend
> > the optimal size for the epsilon as sqrt(EPS) where EPS is the distance
from
> > 1.0 to the next largest floating point number. In a traditional PC, I
> > believe EPS is approx 2.2e-16, so the optimal epsilon is approximately
> > 1.4e-8
>
>   Note that we are not using an epsilon value for making comparisons, but
> for making vector math which should be as accurate as possible.
>   The smaller the epsilon value we use for approximating the tangent of
the
> spline, the more error-prone it will become (due to inaccuracies with very
> small values).

Exactly, there are two type of errors:
* As the epsilon becomes larger, the approximation of the derivative will be
less accurate.
* As the epsilon becomes smaller, the errors due to the floating-point
arithmetic will worsen.

But both errors will affect directly the accuracy of the approximation.

That's why it's important to have a good size for the epsilon. However, for
your particular application, I think you don't need a very high accuracy for
the derivatives, so practically any reasonably small epsilon (1e-4?) will be
ok.

I searched for my Numerical Analysis notebook and didn't find it. But, I
just found a paper
(http://www.nek.uu.se/Utbildning/Foskarutbildning/MEnotes1.pdf) where the
optimal size for your epsilon, using central derivatives, is found out and
it is:

epsilon*  = (3*EPS / M)^(1/3)

Where M is the highest value of the second derivative (in absolute value) of
the function in the interval (x-epsilon, x+epsilon) and it is often not
known and it is replaced by some estimate.

So, if you use a traditional PC, then EPS is approx. 2.2e1-6,
and if you ignore M, then you'll have:

epsilon* = (3*2.2e-16)^(1/3) = 8.7e-6

which is almost 1e-5, so I think 1e-5 is a pretty good size for your
epsilon.

I hope you can make some experiments and comment us your results.

Fernando.


Post a reply to this message

From: Mike Williams
Subject: Re: Mesh lathe
Date: 25 Feb 2002 13:01:39
Message: <m5WOhMAoZie8Ew$0@econym.demon.co.uk>
Wasn't it Warp who wrote:
>  I was experimenting with a small macro which creates a mesh shaped like
>a lathe from a spline. (The advantage of meshes over lathes is speed. Another
>one is that with lathes you sometimes get artifacts which you don't get with
>meshes.)

An alternative would be to consider that a spline function can also be
used in an isosurface. I've put a little example of this about halfway
down this page <http://www.econym.demon.co.uk/IsoTut/splines.htm>.

As it happens, this ends up being a ridiculously slow parametric
isosurface, so I use Ingo's macro to convert it to a mesh2 for the
actual rendering, so we end up doing the same thing.

This offers a little bit more flexibility. You can easily arrange for
the cross section to be something other than a circle and the axis to be
something other than a straight line as seen on that page. You can also
add other functions to the isosurface to achieve displacements.


#macro MakeEvenSplinePoints(Points)
  #local Amnt = dimension_size(Points, 1)-1;
  #local Ind = 0;
  #while(Ind <= Amnt)
    Ind/Amnt, Points[Ind]
    #local Ind = Ind+1;
  #end
#end

#declare Points = array[18]
{ <0,.1>,<1,0>,<1.2,.05>,<1,.1>,<.2,.3>,
  <.25,.4>,<.1,.9>,<.1,2.5>,<.3,2.8>,<.3,3.1>,
  <1,3.25>,<1.25,4>,<1,5>,<.9,5>,<1.1,4.5>,
  <1.15,3.8>,<1,3.4>,<0,3.2>
}

#declare Spline = function {spline { cubic_spline
MakeEvenSplinePoints(Points) }}

camera { location -z*14 look_at 0 angle 35 orthographic translate y*2.5
}
light_source { <100,200,-300>, 1 }
light_source { <-100,20,-30>, <1,.5,0>*.5 }
plane { -z,0 pigment { checker rgb 1, rgb .5 } }



#declare Fx = function(x,y) {(Spline(u).x * sin(v))}
#declare Fy = function(x,y) {Spline(u).y}
#declare Fz = function(x,y) {(Spline(u).x * cos(v))}
#declare Umin =  0;
#declare Umax =  1;
#declare Vmin =  -pi;
#declare Vmax =  1.001*pi;
#declare Iter_U = 80;
#declare Iter_V = 20;

#include "param.inc"
Parametric()

object {Surface
  no_shadow
  pigment { rgb 1 } finish { specular .5 }
}


Post a reply to this message

From: David Fontaine
Subject: Re: Mesh lathe
Date: 26 Feb 2002 23:45:01
Message: <3C7C6567.57663355@faricy.net>
Warp wrote:
> 
>   The only concern I have about it is that it uses the "trick" to calculate
> the normal of the spline with the Spline(T+Epsilon)-Spline(T-Epsilon)
> formula. What I'm not sure about is the value for 'Epsilon'. I used 1e-5,
> but that might sometimes be either too big or too small (due to floating
> point number inaccuracies).

No problem, just write a symbolic manipulation include that does
derivation and have it find the exact slope... ;)

-- 
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.