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

Ron Parker wrote:
> 
> [...]
> 
> ... a bunch of superimposed finite-sized lattices ...

Now that's a cool term. I have to remember and use it on occasion...

;-)

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

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> Scalning scene up reduce problem, but my scene IS legal, and it should 
> produce correct results.

  The fact that a scene is legal in a syntactical and logical sense does
not mean that you can't hit the pysical boundaries of the processor (eg.
floating point accuracy).

  Also this scene is perfectly legal by all means, but it renders horribly
due to limited floating point accuracy:

camera { location -z*2e5 look_at 0 angle .001 }
light_source { <100,200,-300>, 1 }
sphere { 0,1 pigment { rgb 1 } }


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

Warp <war### [at] tagpovrayorg> wrote in news:3d528c52@news.povray.org:

> Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> Scalning scene up reduce problem, but my scene IS legal, and it
>> should produce correct results.
> 
>   The fact that a scene is legal in a syntactical and logical sense
>   does 
> not mean that you can't hit the pysical boundaries of the processor
> (eg. floating point accuracy).
> 
>   Also this scene is perfectly legal by all means, but it renders
>   horribly 
> due to limited floating point accuracy:
> 
> camera { location -z*2e5 look_at 0 angle .001 }
> light_source { <100,200,-300>, 1 }
> sphere { 0,1 pigment { rgb 1 } }

Woah, very nice texture :-)

See also http://www.povray.org/download/3.5-bugs.php "Bugs inherited from 
POV-Ray 3.1 and older versions".

Now, it would be nice if somebody give a patch to correct some of these 
bugs, without affecting the regular behavior (speed, rendering)...

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

Philippe Lhoste <Phi### [at] GMXnet> wrote in
news:Xns### [at] 204213191226 

>> Also this scene is perfectly legal by all means, but it renders
>> horribly 
>> due to limited floating point accuracy:
>> camera { location -z*2e5 look_at 0 angle .001 }
>> light_source { <100,200,-300>, 1 }
>> sphere { 0,1 pigment { rgb 1 } }

> Woah, very nice texture :-)

:)


> See also http://www.povray.org/download/3.5-bugs.php "Bugs inherited
> from POV-Ray 3.1 and older versions".
> Now, it would be nice if somebody give a patch to correct some of
> these bugs, without affecting the regular behavior (speed,
> rendering)... 

I'm trying to do this, but it will affect render speed :/ but there would 
be some options to choose beetween standart or extra accurate version, and 
maybe to set some tolerance options



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

Philippe Lhoste <Phi### [at] gmxnet> wrote:
> Now, it would be nice if somebody give a patch to correct some of these 
> bugs, without affecting the regular behavior (speed, rendering)...

  The example scene I posted does not show any bug. It simply shows that
floating point calculations have limited accuracy. A bug is a programming
mistake, and limited floating point accuracy is not a programming mistake.

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