|
 |
I am using numbers with solar-system sized values eg. 2x10^8.
I have just noticed what seems to be a bug with some solids
(code attached).
I have a sphere at the origin and a differenced cylinder
bracketing it. When the camera moves from a distance of
10 million to 11 million units the sphere disappears, but the
cylinder remains.
Additionally a torus at 152 million units disappears, whilst another
differentiated cylinder further out is visible in the same view,
in fact in another view the torus suddenly ends for no apparent
reason.
I would like to know if others who run this code see the same
issues, or if it is just platform specific...
The following code illustrates this bug, change the camera
statement from camera1 to camera2 to see the first bug,
set it at camera4 to see the second bug.
I am running PoV3.5 under windows95 with a P4 1.2GHz and
512Mb of memory.
If the items uniformly disappeared I would think it was a
floating overflow or something, however only certain items
seem to disappear, and not necessarily the furthest.
On my machine the system seems to have about 17 digits
of precision for floats as I am only using 9 this should not be
an issue (I determined this by doubling a float in a loop and
printing the results and marking where the least significant
digit started to become in error):
#declare cnt=0;
#declare value=1;
#while (cnt < 70)
#declare value=value*2;
#debug concat("Value is:",str(cnt,0,-1)," total is
",str(value,0,-1),"\n")
#declare cnt=cnt+1;
#end
-Dan
----- Problem pov file ------
// Disappearing item bug
#include "colors.inc"
#declare camera1=camera { // sun not visible
location <100,1000000,-11000000>
look_at <0,0,0>
angle 35
}
#declare camera2=camera { // sun visible
location <100,1000000,-10000000>
look_at <0,0,0>
angle 35
}
#declare camera4=camera {
location < 0, 1200000, -153568000>
look_at <10000000, -100000, -151000000>
angle 35
}
#declare camera7=camera { // Top View
location < 0,500000000,0>
look_at <0,0,0>
angle 45
}
camera {camera1}
sphere { //sun
<0,0,0>, 679948
pigment {Yellow}
finish {ambient .7} }
light_source { <0,0,-156000000> colour White }
object { // Sun indicator
difference {
cylinder { <0,35000000,0>, <0,-35000000,0>, 900000 }
cylinder { <0,800000,0>, <0,-800000,0>, 910000 }
}
pigment { colour Blue }
finish { ambient 1 }
}
object {
torus { 152000000, 400000 }
pigment { colour Green }
finish { ambient 1 }
}
object { // Ring
difference {
cylinder { <0,-1000000,0>, <0,1000000,0>, 153570000 }
cylinder { <0,-1000001,0>, <0,1000001,0>, 153567000 }
}
pigment { colour White }
finish { ambient .7 }
}
Post a reply to this message
|
|
|
|
wrote:
> I am using numbers with solar-system sized values eg. 2x10^8.
Please don't.
--
#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
|
|
|
|
On 30-Nov-2002, "Thorsten Froehlich" <tho### [at] trf de> wrote:
> > But if the max intersection distance (which is 10^7 according to
> > frame.h)
> > would be the issue here shouldn't all objects dissapear at the same
> > distance then?
>
> Not really, the issue is a bit more complex. To simplify it, think of it
> as
> if there is just no guarantee made that any object placed more than 10^7
> away from the camera will behave as expected.
So I moved the decimal place over 3 locations (I was using 1unit=1Km) and
the problem with disappering items goes away. This hard-coded limitation
should defintely be described somewhere. (I know the documentation does
not talk about computational limits, as they would be machine specific).
The whole Idea behind floats is that the magnitude is really irrelevant,
only
the number of digits of accuracy should be a constraint, I am still getting
artifacting at the 7th digit of accuracy and that just seems to be a
limitation
of the system and is not good, but can be managed.
So searching for other hard-coded limits in the program I downloading the
source.
There I notice a value "small tolerance" of 0.001 is this another limit of
the program
that people have to be aware of?
If I have scene do I have to keep all my values above this number as well?
I also see that someone has defined pi to 22 digits of accuracy obviously
all of
these digits are not used.
Bounding boxes only use single floats rather than double I can't imagine
why this is so, or what effects this will have on code.
Also the mesh functions seem to use singles, I don't know if this would
cause
issues depending on the size/accuracy of the scene objects, perhaps someone
more knowledgable could comment on this.
All of these need to be definitely documented somewhere in the help files /
FAQ.
My problem is that I wanted to create an animation zooming in from
extra-solar
system to close earth orbit, so I will have to probably break it up into
several parts
with increasing accuracy in each source file in order to get PoV to perform
this task.
-Dan
Post a reply to this message
|
|
