"Slime" <slm### [at] slimelandcom> wrote in news:3d51cdd2$1@news.povray.org

>> 2. how about generate 2 binary distributions of POV - second
>> executable file will have extra accuarity (by cost of speed) ?
> What you've described sounds to me like a floating point accuracy
> issue. This is likely not a cause of speedups, but rather the fact
> that at some point a number becomes too small to be held in whatever
> data type they're holding numbers in, so it gets rounded to zero,
> which causes problems. 

yes,

> Since it's a floating point accuracy problem,
> and there are no *approximations* occuring here, there's no way to
> sacrifice speed for accuracy. 

I was thinking abut changing float to double in sources.
In fact, this is tryvial to modify sources that way, best - change all 
"float" into "tMath" and then add some precision.h to each file :

#if version_precision=0
  typedef tMath float;
#end
#if version_precision=1
  typedef tMath double;
#end
#if version_precision=2
  typedef tMath long double;
#end

1 - standart using

2 - using with small objects (when user is to lazy to scale up scene), or 
with final render of realy complex images

3 - for very special usage, like huge scene - i.e. Earth, with model of 
human, and animation of i.e. Spaceship - it starts on earth looking at 
human 0.1 units, and ends on orbit looking on 1e6 sphere 

so... can someone just re-compile pov with this little change ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message