High!

Meanwhile, I improved the 8bit grayscale "heightfields" of Deimos and 
Phobos by using HLA to convert them into POV-Ray 16bit images and 
blurred them slightly to get rid of the "greebled" look... then I 
rendered both moons again and noticed portions being vertically cut off 
(see attachments)! It can hardly be a matter of not enough RAM, as I 
just recently installed another 1 GB, so that I now have 1536 MB (and 
according to POV-Ray, the maximum memory used is about 650 MB)...
See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download 'deimos000.png' (59 KB) Download 'phobos004.png' (56 KB)

Preview of image 'deimos000.png'

Preview of image 'phobos004.png'

From the 'straight line' appearance of the cutoff, it looks so much like a
bounding-box problem; but your asteroid code has no explicit bounding box, so
that's a mystery. Have you tried rotating the asteroid to see if that straight
line is actually a flat 'plane' (or else a big hole?) The other possibility
that comes to mind is this: Since you reworked the image map, could the problem
again be related to the needed fix that Clipka mentioned in your previous post?

Is eval() 'seeing' the entire image map?

KW

Post a reply to this message

Where is the moon, and how big is it, in POV-Ray co-ordinates?

Post a reply to this message

High!

Kenneth wrote:
 > >From the 'straight line' appearance of the cutoff, it looks so much 
like a
 > bounding-box problem; but your asteroid code has no explicit bounding 
box, so
 > that's a mystery.
Perhaps I should look up the manual sections on bounding...
 >  Have you tried rotating the asteroid to see if that straight
 > line is actually a flat 'plane' (or else a big hole?).

Yes, I have... it seems to be a hole rather than a plane!
 >  The other possibility
 > that comes to mind is this: Since you reworked the image map, could 
the problem
 > again be related to the needed fix that Clipka mentioned in your 
previous post?
No, I did not touch the code since!
 > Is eval() 'seeing' the entire image map?
Yes, it does, as the image_map extends from <0, 0, 0> to <1, 1, 0>, 
eval_pigment() goes from
<(0.5+0)*(1/800), (0.5+0)*(1/400), 0> to <(0.5+799)*(1/800), 
(0.5+399)*(1/400), 0>!

See you in Khyberspace!

Yadgar

Now playing: My Key To The World (Heaven 17)

Post a reply to this message

=?ISO-8859-1?Q?J=F6rg_=27Yadgar=27_Bleimann?= <yaz### [at] gmxde> wrote:
> Yes, I have... it seems to be a hole rather than a plane!

Can you make a shot of the hole from more sideways?

If you rotate the camera, does the shape of the hole change?

If you rotate the asteroid, does the shape of the hole change?

If you move the asteroid slightly (by, say, 1/10 of its total dimensions), does
the shape of the hole change?

Post a reply to this message

High!

clipka wrote:
> Where is the moon, and how big is it, in POV-Ray co-ordinates?

Originally, my Phobos has radii of about 13.4 x 11.2 x 9.2 POV units, as 
the sun sits at the origin, Phobos' orbit together with Mars is about 
227900000 POV units wide. Knowing that most objects at such distances 
won't render correct, I introduced a scaling divisor and set it to 13347 
- probably this is too high for small objects like asteroids and 
irregular moons. I decreased it to 13 (!) - and then, the clipping 
disappeared!

See you in Khyberspace!

Yadgar

Post a reply to this message

=?ISO-8859-1?Q?J=F6rg_=27Yadgar=27_Bleimann?= <yaz### [at] gmxde> wrote:
> Originally, my Phobos has radii of about 13.4 x 11.2 x 9.2 POV units, as
> the sun sits at the origin, Phobos' orbit together with Mars is about
> 227900000 POV units wide. Knowing that most objects at such distances
> won't render correct, I introduced a scaling divisor and set it to 13347
> - probably this is too high for small objects like asteroids and
> irregular moons. I decreased it to 13 (!) - and then, the clipping
> disappeared!

You have a bounding box problem. And your divisor won't solve it.

For memory efficiency, POV-Ray uses single-precision floating point numbers for
bounding boxes. Those are precise to about 7 digits.

So at a position 227900000 whatever-units away from the co-ordinate origin,
bounding boxes have a "resolution" of 100 whatever-units. Dividing all
dimensions will not help you: It's the relative size that kills here. You may
find divisors that *happen* to be ok for where the moon sits right now, but
things will go awry again as soon as you move the moon around.

What you really need to do is turn off bounding boxes altogehter. It's not as
bad as it sounds: You probably just have spheres and meshes. As long as you
generate the meshes near the origin, their internal bounding mechanism will
kick in, and do a good job on it. And those few spheres are quickly checked for
intersections - or you may want to manually bound them, maybe together with
their moons.

Or, even better yet:

Instead of centering your universe on the sun, center it to the camera. And make
sure you use as few "moves" for your moons as possible: I'm not sure ATM how
bounding boxes react to being translated to millions of POV-Units away, only to
be pushed back again shortly after; I guess they're just modified, not re-built
from scratch.

To this end, you may need to set up your transformations first (using the
transform{} statement) - "stacking" all the translations and rotations into a
single transform{} variable per moon, and then apply them in one go.

Post a reply to this message

"clipka" <nomail@nomail> wrote:

> You have a bounding box problem. And your divisor won't solve it.
>
> For memory efficiency, POV-Ray uses single-precision floating point numbers
> for bounding boxes. Those are precise to about 7 digits.

Hmm, this could also be the reason why unions of simple objects show 'strange'
visual behavior, when they are scaled down way below 1 unit. (I've since taken
to making sure that I avoid 'small' scaling of objects--by boosting the scale
of *everything* in a scene; I think I've read something about this in the
newsgroups as well.)

> What you really need to do is turn off bounding boxes altogehter. It's not as
> bad as it sounds: You probably just have spheres and meshes. As long as you
> generate the meshes near the origin, their internal bounding mechanism will
> kick in, and do a good job on it. And those few spheres are quickly checked
> for intersections...
>

Does that apply only to the 'new' bounding method in the 3.7 betas?  Or to 3.6.1
as well?

So do I take it that by turning Bounding=off, there's still an 'internal'
bounding mechanism at play (at least with meshes)? That's new to me; didn't
know that.

KW

Post a reply to this message

High!

clipka wrote:

> What you really need to do is turn off bounding boxes altogehter.

That was pretty easy, just -MB in the command line... here we go!

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download '2009-04-20 phobos, take 6.jpg' (13 KB)

Preview of image '2009-04-20 phobos, take 6.jpg'

"Kenneth" <kdw### [at] earthlinknet> wrote:
> > For memory efficiency, POV-Ray uses single-precision floating point numbers
> > for bounding boxes. Those are precise to about 7 digits.
>
> Hmm, this could also be the reason why unions of simple objects show 'strange'
> visual behavior, when they are scaled down way below 1 unit. (I've since taken
> to making sure that I avoid 'small' scaling of objects--by boosting the scale
> of *everything* in a scene; I think I've read something about this in the
> newsgroups as well.)

No, that's yet another precision issue ;)

The bounding box thing happens irrespectible of object size, and solely depends
on the ratio between object size and object position.

> > What you really need to do is turn off bounding boxes altogehter. It's not as
> > bad as it sounds: You probably just have spheres and meshes. As long as you
> > generate the meshes near the origin, their internal bounding mechanism will
> > kick in, and do a good job on it. And those few spheres are quickly checked
> > for intersections...
>
> Does that apply only to the 'new' bounding method in the 3.7 betas?  Or to 3.6.1
> as well?

Um... I must confess I'm not sure. I only have the 3.7 code here "ready to dive
into"; I never actually bothered to look too deep into 3.6 code - except for
radiosity of course. I am convinced that reading the old 3.6 code is bad for
your eyes :)

> So do I take it that by turning Bounding=off, there's still an 'internal'
> bounding mechanism at play (at least with meshes)? That's new to me; didn't
> know that.

At least with 3.7 there is. I think with 3.6 it's in place, too. But no
guarantee.

This "internal bounding" applies to meshes and blobs, if I'm not mistaken.
Height fields probably as well.

Post a reply to this message