 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
I have this small problem... I have a very large object
that is very far from the center ( <0,0,0>), but it seems
that pov prunes objects that are not inside <+-1000000,
+-1000000,+-1000000>... Is there a way of settings this?
Best,
S.
--
----------------------------------------------------------
Steven Pigeon Ph. D. Student.
University of Montreal.
pig### [at] iro umontreal ca Topics: data compression,
pig### [at] jsp umontreal ca signal processing,
ste### [at] research att com non stationnary signals
and wavelets.
----------------------------------------------------------
http://www.iro.umontreal.ca/~pigeon
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Steven Pigeon wrote:
> I have this small problem... I have a very large object
> that is very far from the center ( <0,0,0>), but it seems
> that pov prunes objects that are not inside <+-1000000,
> +-1000000,+-1000000>... Is there a way of settings this?
>
> Best,
>
> S.
Oh, yeah, I use version 3.1a for windows.
It seems in fact that the bug is much more perverse...
#declare EarthMoonDistance = 469928448; // Earth-Moon distance
#declare EarthRadius = 6379439.6; // in meters (thus, 1 pov unit =~=
1 m)
#declare MoonRadius = 3476183; // for now
box
{
0, MoonRadius
translate <0,-EarthRadius,0> + EarthMoonDistance*vnormalize(<0,0.5,1>)
pigment { Green }
}
Yields a visible box, but:
sphere
{
0, MoonRadius
translate <0,-EarthRadius,0> + EarthMoonDistance*vnormalize(<0,0.5,1>)
pigment { Green }
}
does not yield a visible sphere... the object doesn't even exist!
suggestions?
Best,
S.
----------------------------------------------------------
Steven Pigeon Ph. D. Student.
University of Montreal.
pig### [at] iro umontreal ca Topics: data compression,
pig### [at] jsp umontreal ca signal processing,
ste### [at] research att com non stationnary signals
and wavelets.
----------------------------------------------------------
http://www.iro.umontreal.ca/~pigeon
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> suggestions?
>
1. Fix the source.
or....
2. Scale your distances to fit within POV's current bounds. If your moon is 100x
closer and
100x smaller, the error in parellax will be well under one pixel.
Dan
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Due to prescion limitations of Float math, Povray is compiled
by default with the following:
Anything below 0.001 is considered 0.0
Anythung beyond +/- 1e7 is non exsistant
Don't try to be 100% accurate. Povray isn;t a physics real
world modeler. its an Artistic Program. As long as it looks
right to you then its accurate =}
"fixing" the source will give prescion errors.
Dan Connelly wrote:
>
> > suggestions?
> >
>
> 1. Fix the source.
>
> or....
>
> 2. Scale your distances to fit within POV's current bounds. If your moon is 100x
closer and
> 100x smaller, the error in parellax will be well under one pixel.
>
> Dan
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Matthew Corey Brown - XenoArch wrote:
>
> Due to prescion limitations of Float math, Povray is compiled
> by default with the following:
>
> Anything below 0.001 is considered 0.0
> Anythung beyond +/- 1e7 is non exsistant
>
> Don't try to be 100% accurate. Povray isn;t a physics real
> world modeler. its an Artistic Program. As long as it looks
> right to you then its accurate =}
>
> "fixing" the source will give prescion errors.
>
POV sets its limits rather conservatively, and in some cases
does calculations in a fashion which make it more susceptible
to precision limits than it needs be.... doing things like taking
squares and squareroots in nonoptimal sequence.
I agree, though -- there often isn't a need to use such large numbers,
as I pointed out.
Dan
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Matthew Corey Brown - XenoArch wrote:
> Due to prescion limitations of Float math, Povray is compiled
> by default with the following:
>
> Anything below 0.001 is considered 0.0
> Anythung beyond +/- 1e7 is non exsistant
Well, pov uses DOUBLEs, and not FLOATs, and the epsilonis 1e-6...
not 1e-3. I've checked the source.
Besides, I could show you a couple of pictures where a difference
of 0.001 is visible as a thin line.
However, after toying with objects, I've discovered that
the bug is related to spheres and ellipsoids. A cube a couple
of thousand miles wide set at a quarter millon miles is visible
(as a pixel, granted, but still visible). A sphere, 6 k miles wide,
(assuming a pov unit is 1 meter) at 292 000 miles is not visible.
Why?
I have not been able to pinpoint the bug in the source. It
seems OK to me... still, it is not. My guess is that the epsilon
is used in an additive way instead of multiplicative way in
the sphere intersection routine (should be something like
eps * dist rather than just eps).
Best,
S.
> Don't try to be 100% accurate. Povray isn;t a physics real
> world modeler. its an Artistic Program. As long as it looks
> right to you then its accurate =}
> > 2. Scale your distances to fit within POV's current bounds. If your moon is 100x
closer and
> > 100x smaller, the error in parellax will be well under one pixel.
That's the best fix, but I dont like it
> >
> > Dan
--
----------------------------------------------------------
Steven Pigeon Ph. D. Student.
University of Montreal.
pig### [at] iro umontreal ca Topics: data compression,
pig### [at] jsp umontreal ca signal processing,
ste### [at] research att com non stationnary signals
and wavelets.
----------------------------------------------------------
http://www.iro.umontreal.ca/~pigeon
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
<snip>
>However, after toying with objects, I've discovered that
>the bug is related to spheres and ellipsoids. A cube a couple
>of thousand miles wide set at a quarter millon miles is visible
>(as a pixel, granted, but still visible). A sphere, 6 k miles wide,
>(assuming a pov unit is 1 meter) at 292 000 miles is not visible.
<snip>
Rather than a bug that only effects these shapes, could it not just be that
a sphere's image is less clear than a squares from the same distance? For
example, looking straight at at, a cube will show up as a solid, pretty much
evenly shaded square. A sphere will however be more of a brighter point
with dimmer edges around it. Perhaps, at these distances, it is the less
visible properties of the sphere that makes POV decide there's not enough
light to plot a pixel - unlike the cube, which may just have enough light
from it's apparently brighter side to appear as one.
Just my 2 pence :)
Matt
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Matthew Bennett wrote:
> <snip>
> >However, after toying with objects, I've discovered that
> >the bug is related to spheres and ellipsoids. A cube a couple
> >of thousand miles wide set at a quarter millon miles is visible
> >(as a pixel, granted, but still visible). A sphere, 6 k miles wide,
> >(assuming a pov unit is 1 meter) at 292 000 miles is not visible.
> <snip>
>
> Rather than a bug that only effects these shapes, could it not just be that
> a sphere's image is less clear than a squares from the same distance? For
> example, looking straight at at, a cube will show up as a solid, pretty much
> evenly shaded square. A sphere will however be more of a brighter point
> with dimmer edges around it. Perhaps, at these distances, it is the less
> visible properties of the sphere that makes POV decide there's not enough
> light to plot a pixel - unlike the cube, which may just have enough light
> from it's apparently brighter side to appear as one.
NO, I _did_ check for that. That was my first thought... then I set
the sphere's color to Yellow*2 on a black background... That should have
been enough...
>
>
> Just my 2 pence :)
>
> Matt
--
----------------------------------------------------------
Steven Pigeon Ph. D. Student.
University of Montreal.
pig### [at] iro umontreal ca Topics: data compression,
pig### [at] jsp umontreal ca signal processing,
ste### [at] research att com non stationnary signals
and wavelets.
----------------------------------------------------------
http://www.iro.umontreal.ca/~pigeon
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Strangely enough, I can confirm this... I started with a sphere at the origin,
which I expanded appropriately as I moved it further out along the z-axis, and
when numbers got into the millions, it disappeared. A box, slightly further
out, remained visible...
-Mark R.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Yep, the scale of things (distance, size) in POV-Ray is not infinite.
Others have brought this up before, one person in particular I can't
recollect since its been a year or more. But I tried my own scale
testing too and apparently the cone primitive is a very sturdy piece of
pov script. The sphere is one of the weakest, it changes size and
disappears altogether rather easily if scaled too large or small. The
box primitive tends to distort quite a bit before suffering the same
fate. This happens regardless of camera being scaled to view objects.
I could put my scale test file at the scene-files.text group if I can
locate it here.
Mark Radosevich wrote:
>
> Strangely enough, I can confirm this... I started with a sphere at the origin,
> which I expanded appropriately as I moved it further out along the z-axis, and
> when numbers got into the millions, it disappeared. A box, slightly further
> out, remained visible...
>
> -Mark R.
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.htm
=Bob
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On Wed, 30 Dec 1998 02:35:58 -0500, Steven Pigeon
<pig### [at] iro umontreal ca> wrote:
>
>
>Matthew Corey Brown - XenoArch wrote:
>
>> Due to prescion limitations of Float math, Povray is compiled
>> by default with the following:
>>
>> Anything below 0.001 is considered 0.0
>> Anythung beyond +/- 1e7 is non exsistant
>
>Well, pov uses DOUBLEs, and not FLOATs, and the epsilonis 1e-6...
>not 1e-3. I've checked the source.
Check the source again. EPSILON varies with the platform. For
example, the Windows source to version 3.1a uses
#define EPSILON 1.0e-5
The default (if not specified in config.h) in frame.h is
#define EPSILON 1.0e-10
Still not 1e-3, I'll admit, but not 1e-6, either.
HOWEVER:
What Matthew said is entirely correct, if the comments in the source
are to be believed. Note this fragment from frame.h. Note too that
it's platform-independent:
/*
* These values determine the minumum and maximum distances
* that qualify as ray-object intersections.
*/
#define Small_Tolerance 0.001
#define Max_Distance 1.0e7
>However, after toying with objects, I've discovered that
>the bug is related to spheres and ellipsoids. A cube a couple
>of thousand miles wide set at a quarter millon miles is visible
>(as a pixel, granted, but still visible). A sphere, 6 k miles wide,
>(assuming a pov unit is 1 meter) at 292 000 miles is not visible.
>
>Why?
>
>I have not been able to pinpoint the bug in the source. It
>seems OK to me... still, it is not. My guess is that the epsilon
>is used in an additive way instead of multiplicative way in
>the sphere intersection routine (should be something like
>eps * dist rather than just eps).
It has been stated before, perhaps in .programming, that the sphere
intersection routine was suboptimal WRT its use of EPSILON. I'd go
look up the exact discussion, but I'm too lazy. :)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>The sphere is one of the weakest, it changes size and
>disappears altogether rather easily if scaled too large or
small. The
>box primitive tends to distort quite a bit before suffering
the same
>fate. This happens regardless of camera being scaled to
view objects.
>I could put my scale test file at the scene-files.text
group if I can
>locate it here.
Yes, the object type matters a lot. I remember some posting
about half a year ago that tried to scale a sphere and a
cylinder down to .... well, almost nothing.
From a certain scale value, the sphere started to shrink
faster than the cylinder.
Julius
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Hmm
I've ben experimenting a bit, and at certain sizes, pov says that a sphere is
infinite...
Why so ? (camera inside the sphere...)
//Spider
Julius Klatte wrote:
>
> >The sphere is one of the weakest, it changes size and
> >disappears altogether rather easily if scaled too large or
> small. The
> >box primitive tends to distort quite a bit before suffering
> the same
> >fate. This happens regardless of camera being scaled to
> view objects.
> >I could put my scale test file at the scene-files.text
> group if I can
> >locate it here.
>
> Yes, the object type matters a lot. I remember some posting
> about half a year ago that tried to scale a sphere and a
> cylinder down to .... well, almost nothing.
> From a certain scale value, the sphere started to shrink
> faster than the cylinder.
>
> Julius
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Spider wrote:
>
> Hmm
> I've ben experimenting a bit, and at certain sizes, pov says that a sphere is
infinite...
> Why so ? (camera inside the sphere...)
>
> //Spider
Because it's always been that way. They call a plane
an infinite object too but it fits inside my screen
with no problem.
--
Ken Tyler
tyl### [at] pacbell net
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>
> Because it's always been that way. They call a plane
> an infinite object too but it fits inside my screen
> with no problem.
Now that isn't the right answer to give *grin*
"because it has always been....." *yuch*
but I see your point, I know it isn't a bug in output, but It got me confused as hell
the
first time, two more planes(infinite) then I had used...
I only wondered why it was done, because of the sizes or something else ???
>
> --
> Ken Tyler
>
> tyl### [at] pacbell net
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Well, I do know the "sky sphere" object is "infinite" in that it remains the same
distance
'away' no matter how much you move stuff around, AND it makes the 'scene' the center
of the
sphere no matter where the cartesian system SAYS the scene is located.
Was unaware that normal spheres did that if you put the camera inside them.... will
have to
experiment.
As for planes, well... they are a finite distance "away" along one axis, but extend
infinitely in the other two. We could also argue that the x, y, and z 'vectors' are
also
infinite, but being one-dimensional, wouldn't do us much good as objects...
(I think i should pick up that old copy of Euclid and see if I can't render a few of
the
proofs... that should keep me safely in the padded cell for months. :)
Spider wrote:
> >
> > Because it's always been that way. They call a plane
> > an infinite object too but it fits inside my screen
> > with no problem.
> Now that isn't the right answer to give *grin*
> "because it has always been....." *yuch*
>
> but I see your point, I know it isn't a bug in output, but It got me confused as
hell the
> first time, two more planes(infinite) then I had used...
>
> I only wondered why it was done, because of the sizes or something else ???
>
> >
> > --
> > Ken Tyler
> >
> > tyl### [at] pacbell net
--
george erhard
microsoft certified system engineer
http://home.pacbell.net/dcnblues
remove "nospam" from domain when replying
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
george erhard wrote:
>
> Well, I do know the "sky sphere" object is "infinite" in that it remains the same
distance
> 'away' no matter how much you move stuff around, AND it makes the 'scene' the center
of the
> sphere no matter where the cartesian system SAYS the scene is located.
>
> Was unaware that normal spheres did that if you put the camera inside them.... will
have to
> experiment.
>
> As for planes, well... they are a finite distance "away" along one axis, but extend
> infinitely in the other two. We could also argue that the x, y, and z 'vectors' are
also
> infinite, but being one-dimensional, wouldn't do us much good as objects...
Well, those are SUPPOSED to be infinite... The sphere was what confused me..
> (I think i should pick up that old copy of Euclid and see if I can't render a few of
the
> proofs... that should keep me safely in the padded cell for months. :)
Show me the results, please..
//Spider
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |