I was too wordy, probably, too long winded in my original post. The issue :
you run into problems when you start to sphere { <0,0,0>,FrickenHugeRadius
}, or you start to translate <0,0,GiganticAmountOfZee>. It is stated in the
FAQ (online and offline, in the .CHM) that there is a problem when using or
working with BigNumbers (especially, according to the FAQ " ... when mixing
large and small numbers ... " (???))

What I need to know is, *generally*, what are the maximum safe numbers to
use in X,Y,Z, translates, and rad-ee-eye?

By the way (Alain): sky-sphere = not an option (for my use) - I don't want
to use it because you cannot use the no_reflection keyword in it. Yes, I
have reason why I don't want the sky-sphere to be reflected on anything.
Yes, I could just define a big "mask" - a VeryLargeSphere with a "bite"
taken out of it pointed at the camera view vector, thus "masking" the
sky_sphere such as to suppress reflections on any reflecting objects... but
then I may as well just generate a BigSphere.

Over the past couple of days, when I wasn't throwing up from the U.S.
elections (OOPS! there I go again...), I experimented with the "many random
small triangles, discs or spheres" method of generating starfields. NOT an
option for the computer I am currently stuck with (old IBM 350, Pentium
166, 128 Mb RAM, 860 Mb Hard Drive, NO 3d Card, just a 16 bit SVGA chip).
This method is too slow with this CPU / RAM.

So... the only acceptable option is to use a Huge Sphere, either textured
with a pigment map or an image map (which I haven't tried yet, but I might
check out the Fractint -> PlasmaType -> Starfield -> GIF thing... ).

Since I am modeling star *systems* (and everything they contain) I need to
know what my *safe* boundries are. Thus I need to know what a *safe* Huge
is as in sphere { <0,0,0>, Huge }.

Post a reply to this message

Jeff wrote:

> Since I am modeling star *systems* (and everything they contain) I need to
> know what my *safe* boundries are. Thus I need to know what a *safe* Huge
> is as in sphere { <0,0,0>, Huge }.

Taking into consideration that POVRay uses double precision floating 
point values (at least as built on intel platforms, others may vary) 
there are 52 mantissa bits. In normalised form, this yeilds actually 53 
bits of precision (the first bit is implied to be 1) which gives a 
maximum representable whole number of: 9,007,199,254,740,992

Depending on how many digits to the right of the decimal point you'll 
need, You'll have to move that decimal to the left a bit. (Keeping in 
mind what POVRay needs is dependant on what type of object you are 
attempting to trace. I'd at least cut the number of digits in half. 
90,071,992 would probably be a safe bet, but really it depends on 
whether or not there's enough headroom for the root-solver.

-- 
~Mike

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> Taking into consideration that POVRay uses double precision floating 
> point values (at least as built on intel platforms, others may vary) 
> there are 52 mantissa bits. In normalised form, this yeilds actually 53 
> bits of precision (the first bit is implied to be 1) which gives a 
> maximum representable whole number of: 9,007,199,254,740,992

  POV-Ray uses an internal limit which is much lower than that.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:

> 
>   POV-Ray uses an internal limit which is much lower than that.
> 

Having not taken time to look at the POV source code, I'm making a wild 
guess that it does not have a hardcoded limit, per se, but rather a 
limitation imposed by the calculations.

I also did specify whole number. :)

-- 
~Mike

Post a reply to this message

Warp / Mike : (acknowledged, nod, understood);

I am in a big "collecting" mode right now (searching for and downloading
..inc, macros, tutorials - catching up here, I used to be quite proficient
thru PoV 3.1g) and not rendering and experimenting as fast as I need to
(slow computer + waiting for answers for a couple of things, including
*this* issue - also doing some interim research)... but in a couple of days
I will start aggressive experiments to determine the (*approximate) answer
to this question... UNLESS someone can make it easy for me and give me
definite details about the inner workings of PoV (3.6.1) (on *this* issue).
I need someone who progammed PoV to stop by....

Warp: (nod) Yes, that seems to be the case ( " ... artificial limits IMPOSED
.... ") (I just need to know what those limits are, what conditions, what
parameters, "hidden gotcha's", etc.).

I have a couple of clues:

sphere { <0,0,0>,9999999 texture {MyStarField scale x.xx}}
 *OR*
sphere { <0,0,0>,1 texture {MyStarField scale x.xx} scale 9999999}
// size of "Star Sphere" is 9,999,999

.... seems to render properly (if the camera is at <0,0,0> looking at
<0,0,1>). However increase the radius by one to 10,000,000 and the texture
below the x-z plane fails to render (everything below the horizon is
black). Start EXCEEDING 10,000,000 and the texture fails completely.

And I don't know at this time if, when I start to move my camera or change
my angle xx.x, whether 9,999,999 will still work (I will have to check it,
haven't experimented yet).

I tried the "generate lots of objects" method for starfield generation
(actually gave up when just generating 50 "stars" took too long, in a
*restricted* range, *only visible in the camera* I.E. all 50 were on the
screen...); using big triangles as stars, they start to fail to render at
*less than* 9,999,999 (I forget exactly where). Discs (angled, facing the
camera via generating / defining a big disc at <0,0,0>, then translating to
<0,0,9999990>, then adding random X and Y angles via rotate <RandXAngle,
RandYAngle,0>) are okay thru 9,999,990 but fail to show up at 9,999,991.
Spheres are have more tolerance than triangles. Again, change my camera and
that limit of 9,999,990 MIGHT be different.

Again, the main reason for this is "Outer Space" scenes. The focus will be
on objects (spacecraft, space stations, smaller asteroids, other stuff) -
scaled in meters, and my unit expressed in PoV will be in meters. But if my
limit is 9,999,999 meters / 9999.9 kilometers (because of the apparant
MAXIMUM size of StarSpheres - the most distant object) then my room to
"play around in" is limited. I can't model star systems (Stars, Planets,
Big Asteroids, Asteroid Fields) accurately, I have to use tricks (make big
objects smaller and closer than they should be). Consider that a *typical*
star (as I am defining it) : using The Sun as an example, has a radius of
695,500 Km. A typical planet, earth-sized, is Earth 6378 Km.

I supposed I could express as 1 PoV unit = 1 Km to make things "better", but
then spacecraft would be modelled in thousands of kiliometers - hehehe
kinda dumb.

So - what I need to know are details about those "internal numvber limits".

Anybody know the PoV programmers?

Post a reply to this message

"Jeff" <nomail@nomail> wrote:
Pardon my spelling and typos - too much coffee lately;
> (snip)

> I supposed I could express as 1 PoV unit = 1 Km to make things "better", but
> then spacecraft would be modelled in thousands of kiliometers - hehehe
> kinda dumb.

Of course I mean " ... spacecraft will be modeled in THOUSANTHS of
kilometers."

Post a reply to this message

Jeff wrote:

>>I supposed I could express as 1 PoV unit = 1 Km to make things "better", but
>>then spacecraft would be modelled in thousands of kiliometers - hehehe
>>kinda dumb.
> 
> 
> Of course I mean " ... spacecraft will be modeled in THOUSANTHS of
> kilometers."

I have a set of real-world units macros, iirc I did set it up so you 
could determine how many units represented one CM.. i.e. 1/10000u = 1CM 
would give you the 1KM/Unit you desire.

-- 
~Mike

Post a reply to this message