 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d525862@news.povray.org>, Warp <war### [at] tag povrayorg>
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
|
|
| |
| |
|
|
|
|
| |
|
|
