I'm using POV-Ray v. 3.1d.msvc.win32 [Pentium II optimized] with an
AMD-K6-3D 350 Mhz and an Asus P5-B AT Motherboard and fairly
enought Memory (192 MBytes).

Following POV-Ray commands cause a simple sphere to be some-
how clipped around it's border:



#declare cameraorig=< 0,0,0>;
#declare cameratarget=< 740000000,-19000000, 130000000>;
#declare camerapos=cameratarget+vnormalize(cameraorig-cameratarget)*50;
camera{
  location camerapos
  look_at cameratarget
}
light_source
{
  0
  color rgb <1,1,1>
  looks_like {sphere {0, 700000}}
}
sphere {0, 18
        texture {
            pigment {color <0.8,0.8,0.8>}
        }
        translate < 740000000,-19000000, 130000000>
       }
sphere {0, 20
        translate < 750000000,-13000000, 100000000>}

It's clear that the size of the spheres and their position in space cover
several order of magnitudes.
So maybe this problem is somehow related to internal precision of variables.
But if one inserts
the keyword orthographic in the camera section, the sphere renders fine. One
can also try to
remove the second sphere and the problem will disappear (this is also the
fact if one removes
the looks_like statement in the light-source section).
Overall this is a very strange behaviour and it looks like a bug inside
POV-Ray.

Greetings,

    Rainer

Post a reply to this message

Attachments:
Download 'bug.bmp.dat' (57 KB)

In article <37391633.0@news.povray.org> , "Rainer Minixhofer" 
<min### [at] sboxtu-grazacat> wrote:

> I'm using POV-Ray v. 3.1d.msvc.win32 [Pentium II optimized] with an
> AMD-K6-3D 350 Mhz and an Asus P5-B AT Motherboard and fairly
> enought Memory (192 MBytes).
>
> Following POV-Ray commands cause a simple sphere to be some-
> how clipped around it's border:
>
>
>
> #declare cameraorig=< 0,0,0>;
> #declare cameratarget=< 740000000,-19000000, 130000000>;
> #declare camerapos=cameratarget+vnormalize(cameraorig-cameratarget)*50;
> camera{
>   location camerapos
>   look_at cameratarget
> }
> light_source
> {
>   0
>   color rgb <1,1,1>
>   looks_like {sphere {0, 700000}}
> }
> sphere {0, 18
>         texture {
>             pigment {color <0.8,0.8,0.8>}
>         }
>         translate < 740000000,-19000000, 130000000>
>        }
> sphere {0, 20
>         translate < 750000000,-13000000, 100000000>}
>
> It's clear that the size of the spheres and their position in space cover
> several order of magnitudes.
> So maybe this problem is somehow related to internal precision of variables.
> But if one inserts
> the keyword orthographic in the camera section, the sphere renders fine. One
> can also try to
> remove the second sphere and the problem will disappear (this is also the
> fact if one removes
> the looks_like statement in the light-source section).
> Overall this is a very strange behaviour and it looks like a bug inside
> POV-Ray.


No, inside your scene: You values are to large and go outside the limits of
precision. Simply write 74000.0000,-1900.0000, 13000.0000 etc and there
won't be any problems - anyway, maybe a wraning about these limits wouldn't
be such a bad idea...



     Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
>- anyway, maybe a wraning about these limits wouldn't
> be such a bad idea...

  This comes up every time someone tries to model the solar system
using real world values for distance. I have seen this reported
4 or 5 times this year already and there were at least 10 or more
mentions of this problem last year on this server and on c.g.r.r..

  It probably would be a good idea to make a visible warning about
this somewhere even if it is a mention in the known problems document
or even a non fatal error message from the parser itself.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Thorsten Froehlich wrote:
:>- anyway, maybe a wraning about these limits wouldn't
:> be such a bad idea...

:   It probably would be a good idea to make a visible warning about
: this somewhere even if it is a mention in the known problems document
: or even a non fatal error message from the parser itself.

  How do you achieve this with ANSI-C?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote in message <373af850.0@news.povray.org>...
>Ken <tyl### [at] pacbellnet> wrote:
>: Thorsten Froehlich wrote:
>:>- anyway, maybe a wraning about these limits wouldn't
>:> be such a bad idea...
>
>:   It probably would be a good idea to make a visible warning about
>: this somewhere even if it is a mention in the known problems document
>: or even a non fatal error message from the parser itself.
>
>  How do you achieve this with ANSI-C?
>
>--
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Oh, the limits he is seeing are not those of C (or FPU precision), they
are set by some macros in frame.h...


      Thorsten Froehlich

(Yes, it is me - I am just not sending from my own computer...)

Post a reply to this message

"tf" <tf> wrote:
: Oh, the limits he is seeing are not those of C (or FPU precision), they
: are set by some macros in frame.h...

  Ah, ok. Then the warning could be possible.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message