I'm modelling the solar system, using the scale 1meter=1 povray unit.
However, I'm having trouble with objects disappearing when they're located
too far from the camera. I haven't found the exact distance, but it's
somewhere between 11000000.0 units and 10000000.0 units in distance.

So; the question I'm asking is this:
Is there a way to increase the distance to the "far clipping plane" of the
camera in povray?
Of course I can scale everything down, that works as a workaround, but I'm a
curious guy, and it would be interesting to learn why povray works in this
way.

David Ahlard, Stockholm, Sweden

Post a reply to this message

bardland wrote:

> So; the question I'm asking is this:
> Is there a way to increase the distance to the "far clipping plane" of the
> camera in povray?

No, it is hard coded into the program.

> Of course I can scale everything down, that works as a workaround, but I'm a
> curious guy, and it would be interesting to learn why povray works in this
> way.

Floating point accuracy. There is a set epsilon values used to avoid mathematical
inaccuracies. Very large values, such as those used in astromonical distances,
exceed the set epsilon value.

-- 
Ken Tyler

Post a reply to this message

Thank you for the answer. I'm scaling everything down. Another thing that
turned up to be a problem was the 50 kilometer atmosphere of earth.
Everything turned blue. :)

David Ahlard, Sweden

Ken wrote:
>
>bardland wrote:
>
>> So; the question I'm asking is this:
>> Is there a way to increase the distance to the "far clipping plane" of the
>> camera in povray?
>
>No, it is hard coded into the program.
>
>> Of course I can scale everything down, that works as a workaround, but I'm a
>> curious guy, and it would be interesting to learn why povray works in this
>> way.
>
>Floating point accuracy. There is a set epsilon values used to avoid mathematical
>inaccuracies. Very large values, such as those used in astromonical distances,
>exceed the set epsilon value.
>
>Ken Tyler
>

Post a reply to this message

Actually I think that the imposed maximum value for distances is much
smaller than would be possible with 64-bit floating point numbers (which
POV-Ray uses) at a good precision, but I suppose that the principle
has been "better safe than sorry", which might be a good idea.
  I think that this maximum distance is easily modifiable in one of
the source code files (and then you could recompile a custom version
with a much higher limit).

-- 
#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:
>   Actually I think that the imposed maximum value for distances is much
> smaller than would be possible with 64-bit floating point numbers (which
> POV-Ray uses) at a good precision

  Well, a small correction: This is subjective.
  It's rather easy to reach floating point accuracy limits even with
the current limitations.
  In regular scenes you will probably never find any artifacts due to
inaccuracy, but this simple scene shows that you don't even need very
extreme values to get artifacts. In this case the artifacts are produced
because of an unusually small 'angle' value of the camera:


camera { location -z*1e5 look_at 0 angle .002 }
light_source { <10,20,-30>, 1 }
sphere { 0,1 pigment { rgb 1 } }


  There's no "fix" for this possible. (Well, the only fix would be using
floating point numbers with many more bits, eg. 128 bits long or larger,
but with current hardware that's not possible.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

>   Actually I think that the imposed maximum value for distances is much
> smaller than would be possible with 64-bit floating point numbers (which
> POV-Ray uses) at a good precision, but I suppose that the principle
> has been "better safe than sorry", which might be a good idea.
>   I think that this maximum distance is easily modifiable in one of
> the source code files (and then you could recompile a custom version
> with a much higher limit).

IMHO this dis cussion or detail does not belong here at all. This is
povray.newusers and your reply only adds to the confusion of a new user
rather than helping at all.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> IMHO this dis cussion or detail does not belong here at all. This is
> povray.newusers and your reply only adds to the confusion of a new user
> rather than helping at all.

  I apologize.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message