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

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