On 8 Aug 2002 08:26:42 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> any way - http://www.raf256.com/pov/hf_shadow_problem/ is prooving that 
> shadow tollerance is to small, or did I do something wrong ?

It is possible You are doing something wrong. It was pointed you at begining
that it can be floating point accuracy. I think it is possible. Note you used
2048x2048 image so 1 triangle has size about 1/2048 = 0,00048828125. But your
light is at <-30,30,-20>*1e4 and is even further becouse it is area light with
large axes. How many digits is between accuracy of this values ?
As experiment
1. try to remove area_light - is this effect still there ?
2. try to move light closer and wait when effect disappeare.

ABX

Post a reply to this message

ABX <abx### [at] babilonorg> wrote in
news:q6p4lu84dh3dk0ng82bm0lf63s6hid1otq@4ax.com 

> It is possible You are doing something wrong. It was pointed you at
> begining that it can be floating point accuracy. I think it is
> possible. Note you used 2048x2048 image so 1 triangle has size about
> 1/2048 = 0,00048828125. But your light is at <-30,30,-20>*1e4 and is
> even further becouse it is area light with large axes. How many digits
> is between accuracy of this values ? 

yes, I alsow think that this is float/double problem. And there fore using 
more accurate calculations may be useful in some scenes.

Scalning scene up reduce problem, but my scene IS legal, and it should 
produce correct results.

2 things that I will try to change at first - shadow_tolerance, and float 
to double, or double to long double (is shadow tolerance will not help)


-- 
#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 08:44:09 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> yes, I alsow think that this is float/double problem. And there fore using 
> more accurate calculations may be useful in some scenes.

There are accurate calculations. Formulas are accurate :-)
You can use long double but using it will increase memory consumption.

> Scalning scene up reduce problem, but my scene IS legal, and it should 
> produce correct results.

Oh, yes! Writing sphere{0 99e9999999999999999} is legal. Should I say it
should produce correct results ? Floating point accuracy problem never ends.

ABX

Post a reply to this message

ABX <abx### [at] babilonorg> wrote in
news:csp4lusco4pg0qd2k4brinvgdegn08144d@4ax.com 

> Oh, yes! Writing sphere{0 99e9999999999999999} is legal. Should I say
> it should produce correct results ? Floating point accuracy problem
> never ends. 

not 99e99999, not even 1e99 - just 1e6 - is it realy so much to simulate 
sun light ?

-- 
#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 09:01:03 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> not 99e99999, not even 1e99 - just 1e6 - is it realy so much to simulate 
> sun light ?

You don't understand. There is accuracy 1e17! You have to sum floating point
position in both directions. Note that there can be also some inversion
invloved (1/something). I can show you even simpler examples from my
experience. Just use torus in front of orthographic camera.

http://news.povray.org/povray.beta-test.binaries/18705/
http://news.povray.org/povray.beta-test/18702/

ABX

Post a reply to this message

Warp 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...
> 

This does not matter at all, i seriously doubt changing the mesh data to
double would have any practical advantage.

BTW as far as i can see Rafal's observation has nothing to do with
floating point limitations or tolerance values at all, it's simply a 8 bit
heightfield he used.

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 15:12:10 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> BTW as far as i can see Rafal's observation has nothing to do with
> floating point limitations or tolerance values at all, it's simply a 8 bit
> heightfield he used.

Oh yes, it can be either :-)

ABX

Post a reply to this message

On Thu, 08 Aug 2002 13:55:32 +0200, ABX wrote:
> 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.

For a very interesting definition of the word "grid."

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

On 8 Aug 2002 10:00:51 -0400, Ron Parker <ron### [at] povrayorg> wrote:
> > 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.
>
> For a very interesting definition of the word "grid."

You mean it is rather checkered pattern of floating points ? ;-)

ABX

Post a reply to this message

On Thu, 08 Aug 2002 16:10:01 +0200, ABX wrote:
> On 8 Aug 2002 10:00:51 -0400, Ron Parker <ron### [at] povrayorg> wrote:
>> > 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.
>>
>> For a very interesting definition of the word "grid."
> 
> You mean it is rather checkered pattern of floating points ? ;-)

Well, no.  See, the whole mantissa+exponent thing with floating point 
numbers means that what you really have is a bunch of superimposed 
finite-sized lattices at different scales, all (roughly) centered on 
zero.  So, the closer you get to zero the more dense the representable 
points are.  Doubles are the same way; the set just has more - and 
larger - lattices.

Your primary point - that it doesn't matter as long as doubles are used
for the intersection test - is still valid.  It's just not what most 
people would call a "grid" since the representable points aren't all 
spaced evenly.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message