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

In article <3d525862@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

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

Only for storage, the intersection calculations use double precision. 
Single precision isn't a problem for the vertex information. The height 
field code looks like it uses double precision as well, I didn't see 
anything else but integers.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

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

It *seems* like a bug, though. Would it be possible/wise to make POV-Ray 
report when rounding errors like these occur, so that the user won't 
tear his hair out looking for bugs in POV-Ray or his scene?

-Xplo

Post a reply to this message

On Thu, 08 Aug 2002 12:50:59 -0700, Xplo Eristotle wrote:
> It *seems* like a bug, though. Would it be possible/wise to make POV-Ray 
> report when rounding errors like these occur, so that the user won't 
> tear his hair out looking for bugs in POV-Ray or his scene?

How do you propose to detect them?

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

Xplo Eristotle <xpl### [at] infomagicnet> wrote in
news:3d52cb38@news.povray.org: 

> Warp wrote:
>> 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. 
> 
> It *seems* like a bug, though. Would it be possible/wise to make
> POV-Ray report when rounding errors like these occur, so that the user
> won't tear his hair out looking for bugs in POV-Ray or his scene?

That's what I, and the POV team meant, I think.
It seems like a bug, because it doesn't give the expected result.
That doesn't mean there is a way to correct them, only workarounds.

Well, perhaps there is a way, for the glutons for punishment :-)
There are a number of unlimited precision floating point libraries out 
there. So if you don't care for speed and memory consumption, you can 
rewrite POV-Ray to use them, at least for critical sections, instead of 
the standard floating point routines (relying on the fast FPU...).

I doubt it will worth the effort, though.

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
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:
> I doubt it will worth the effort, though.

  I completely agree.

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