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

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

ok, but patch will be ready probalby not ready before next 2..4 weeks.
I'll announce in it .patches and here
wish me luck :)

and - this (not mesh as float's) is the problem - an it easy to explain.
heightfield scaled by <20,5,20> with 4096^2 bitmap has triangles as small 
as 20/4096 - with get close to shadow tollerance, especialy in this parts 
of map that has to low gradient, as on this images :

http://www.raf256.com/pov/hf_shadow_problem/ (in 30 min on server)

-- 
#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:02:13 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> ok, but patch will be ready probalby not ready before next 2..4 weeks.
> I'll announce in it .patches and here
> wish me luck :)

I'm happy I forced you to code :-)

> and - this (not mesh as float's) is the problem - an it easy to explain.
> heightfield scaled by <20,5,20> with 4096^2 bitmap has triangles as small 
> as 20/4096

No! It has the triangles as small as 1/4096. Scale is stored in transformation
structure AFAIK.

ABX

Post a reply to this message

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

>> ok, but patch will be ready probalby not ready before next 2..4
>> weeks. I'll announce in it .patches and here
>> wish me luck :)
> I'm happy I forced you to code :-)

:)

>> and - this (not mesh as float's) is the problem - an it easy to
>> explain. heightfield scaled by <20,5,20> with 4096^2 bitmap has
>> triangles as small as 20/4096
> No! It has the triangles as small as 1/4096. Scale is stored in
> transformation structure AFAIK.

any way - http://www.raf256.com/pov/hf_shadow_problem/ is prooving that 
shadow tollerance is to small, or did I do something wrong ?


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

probably, becouse there is a lot of php errors there :-(

ABX

Post a reply to this message

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

>> any way - http://www.raf256.com/pov/hf_shadow_problem/ is prooving
>> that shadow tollerance is to small, or did I do something wrong ?
> probably, becouse there is a lot of php errors there :-(

page is being _now_ uploading - wait a second ;)

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