Hi,
I have a simple scene that shows some artefacts, this error is easy to 
reproduce, so I will just describe it :

- I have height field, scaled by <20,5,20>
- I have box sized about 0.03
- I have a point light source, that is outside box, in distance of 0.001 
from box

1. when I'm using 2048x2048 hf, then all shadows have very heacy random 
black pixels instead of shadow. 512x512 HF is ok.

2. when distance from box is 0.01 - it's ok when it's 0.001 - I have random 
spots 

both errors are caused from problems with numbers like 0.001 and smaller 
used togeather with another small shapes (hf triangles - 20/2048)

when I changed scale of HF to <2000,500,2000> - everything is ok

So :
1. I will see is this error only connected with HF or with all shapes
2. how about generate 2 binary distributions of POV - second executable 
file will have extra accuarity (by cost of speed) ?

I have Win98, PovRAY 3.5,  Athlon 1,7


-- 
#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

> 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. Since
it's a floating point accuracy problem, and there are no *approximations*
occuring here, there's no way to sacrifice speed for accuracy.

As you've discovered, uniformly scaling the scene to be larger (thereby
bringing the numbers farther from zero) can sometimes help. (Of course, if
you scale *too* large, the same thing happens the other way around - numbers
too big to be held accurately.)

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"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

On 8 Aug 2002 05:16:04 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> I was thinking abut changing float to double in sources.

POV already use double for calculations.
Float is used for color values only iirc.

> 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.
> so... can someone just re-compile pov with this little change ?

Can someone force you to do it yourself? You have linux and windows, right ?
You have compilers installed, right ? You have C skills, right ? You have time
to make ideas, right ? Then I really don't understand your stiff resistance to
not compile yourself. And please don't write "I don't like to modify source
from other authors" becouse we can simple answer "We don't like to implement
ideas from other authors". Is it laziness in your case ?

ABX

Post a reply to this message

Rafal 'Raf256' Maj wrote:
> 
> [...]
> 
> 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 :
> 

Very funny.  If you had a quick look into the source you would have seen
POV-Ray uses double for all geometry data.  Instead of jumping to quick
conclusions it sometimes helps to look into the matter more deeply.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 03 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Thu, 08 Aug 2002 11:33:43 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Very funny.  If you had a quick look into the source you would have seen
> POV-Ray uses double for all geometry data.

Anyway seems there can be some mistakes made by writers. I imagined there
should be only one instance of keyword 'double' in the whole package:
  #define DBL double
but seems authors left some 'double' in a few more places. Perhaps some of
them should be probably replaced with DBL. The same appear for float.

ABX

Post a reply to this message

ABX <abx### [at] babilonorg> wrote:
> POV already use double for calculations.
> Float is used for color values only iirc.

  POV-Ray uses floats for meshes (which gives me cold shivers... but on the
other hand it saves a huge amount of memory). I haven't checked, but it is
very possible that it also uses floats for heightfields.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Very funny.  If you had a quick look into the source you would have seen
> POV-Ray uses double for all geometry data.

  Look closer to how mesh vertices are stored...

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in 
news:3D523AF7.52E6D391@gmx.de

> Very funny.  If you had a quick look into the source you would have seen
> POV-Ray uses double for all geometry data.  Instead of jumping to quick
> conclusions it sometimes helps to look into the matter more deeply.

after looking deep into sources :

1. mesh use float's

2. my conclusion - low tollerance/epsilon/data precision product error was 
in fact correct - from lighting.cpp :


 * "Small_Tolerance" is just too tight for higher order polynomial 
equations.
 * this value should probably be a variable of some sort, but for now just
 * use a reasonably small value.  If people render real small objects real
 * close to each other then there may be some shading problems.  Otherwise
 * having SHADOW_TOLERANCE as large as this won't affect images.

#define SHADOW_TOLERANCE 1.0e-3

3. so I'm preparing a small unoficial version, with just litte boost-up of 
some variables (lower tolerances, higher max max_trace_levels, 
intersections, etc)



-- 
#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

On 8 Aug 2002 07:47:36 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> after looking deep into sources :
>
> 1. mesh use float's

I can be wrong but I think they are only stored as floats. They are used in
intersection tests as doubles probably. So it is rather that vertices are
"aligned" to grid but still should be accurate the same way.

> 3. so I'm preparing a small unoficial version, with just litte boost-up of 
> some variables (lower tolerances, higher max max_trace_levels, 
> intersections, etc)

I'm really interested in results.

ABX

Post a reply to this message