Tek wrote:
>This is the first test of an idea for the Force Of Nature round of the IRTC.
>This is a meteor's view of it hitting a planet. There's a couple of obvious
>bugs: it flies through a couple of hills, and you can see the level of detail
>change from a smooth surface to an isosurface. There's also something really
>wierd at the start of the animation, where it looks like the planet appears
>through an imaginary plane. I've modelled everything to a scale of 1 pov unit =
>1 metre, the planet has a radius of 6,000,000 units, so maybe it's just hitting
>the limit of POV's accuracy.
>
>What do you think? Any comments, suggestions, etc.?
I agree with the other comments, but it would be interesting if you can see
the result from orbit.  Also, it might be better to slow the metor down so
we could see some nice land detail.

Post a reply to this message

Well both those points can be explained by the fact that this is a -very- early
wip :)

The camera is "in" the meteor, because when I rendered that I had no meteor for
the camera to look at. I plan to have the camera following the meteor from just
behind, even though that's a very unrealistic camera angle, because I love the
view we get of the planet during the descent. I'm now working on some nice
re-entry effects which I'll post the results of sometime.

Also the "angle selected" could better be described as a very simple curve. I've
really not done anything clever with the motion, I just picked something that
looked vaguely okay. I'm going to try to write a simple bit of physics to work
out how the meteor should move, then I'll base the animation on that.

Thanks for your comments.

--
Tek
http://www.evilsuperbrain.com


Jim Kress <nos### [at] kressworkscom> wrote in message
news:3d5863a9@news.povray.org...
> Why is the camera in/on the meteor?  Wouldn't it be better from a different
> observation point?
>
> Also, at the angle selected, there would be no impact.  The meteor would
> probably bounce off the atmosphere and back into space.  You need a steeper
> angle of descent.
>
> Jim
>
>

Post a reply to this message

At the moment the meteor's "speed" is just determined by how many frames I
render. I wanted to make it go slower, but it took 20 hours just to render this,
and I can't afford to spend that long just to render a WIP :)

Maybe next time I'll compress it at a lower frame rate.

--
Tek
http://www.evilsuperbrain.com


=RAY= <ray### [at] yahoocom> wrote in message
news:web.3d5930b060a0b574264908380@news.povray.org...
> Tek wrote:
> >This is the first test of an idea for the Force Of Nature round of the IRTC.
> >This is a meteor's view of it hitting a planet. There's a couple of obvious
> >bugs: it flies through a couple of hills, and you can see the level of detail
> >change from a smooth surface to an isosurface. There's also something really
> >wierd at the start of the animation, where it looks like the planet appears
> >through an imaginary plane. I've modelled everything to a scale of 1 pov unit
=
> >1 metre, the planet has a radius of 6,000,000 units, so maybe it's just
hitting
> >the limit of POV's accuracy.
> >
> >What do you think? Any comments, suggestions, etc.?
> I agree with the other comments, but it would be interesting if you can see
> the result from orbit.  Also, it might be better to slow the metor down so
> we could see some nice land detail.
>

Post a reply to this message

Tek wrote:
>This is the first test of an idea for the Force Of Nature round of the IRTC.
>This is a meteor's view of it hitting a planet. There's a couple of obvious
>bugs: it flies through a couple of hills, and you can see the level of detail
>change from a smooth surface to an isosurface. There's also something really
>wierd at the start of the animation, where it looks like the planet appears
>through an imaginary plane. I've modelled everything to a scale of 1 pov unit =
>1 metre, the planet has a radius of 6,000,000 units, so maybe it's just hitting
>the limit of POV's accuracy.
>
>What do you think? Any comments, suggestions, etc.?
>
>--
>Tek
>http://www.evilsuperbrain.com
>
I don't think you've reached the limit of POV's accuracy at just 6000 km,
Tek.

At http://www.freecherrypy.org/johnc I use POV to simulate the Earth, Moon
and Sun in order to create animations of solar eclipses.

The radius of the Earth's orbit is 149,600,000 km, and my results don't
suggest any problems with POVray.

Of course the animations are relatively tiny, but I can zoom in to see the
track of the total eclipse in detail -- no problems.

Pavium (aka John Cherry).

Post a reply to this message

"pavium" <joh### [at] engineercom> wrote in message
news:web.3de4594660a0b574a4545d010@news.povray.org...
> Tek wrote:
> >I've modelled everything to a scale of 1 pov unit =
> >1 metre, the planet has a radius of 6,000,000 units, so maybe it's just
hitting
> >the limit of POV's accuracy.
> >
> I don't think you've reached the limit of POV's accuracy at just 6000 km,
> Tek.
>
> At http://www.freecherrypy.org/johnc I use POV to simulate the Earth, Moon
> and Sun in order to create animations of solar eclipses.
>
> The radius of the Earth's orbit is 149,600,000 km, and my results don't
> suggest any problems with POVray.
>
> Of course the animations are relatively tiny, but I can zoom in to see the
> track of the total eclipse in detail -- no problems.

But are you modelling to a scale of 1 pov unit = 1 metre? I managed to fix
the problem using 1 pov unit = 10 metres, and I'd guess that you've got 1
pov unit = 1km, so you should run into similar problems when you get up to
around 20,000,000 km.

It seems that there's a maximum value that pov won't trace beyond.

--
Tek
http://www.evilsuperbrain.com

Post a reply to this message

Tek wrote:

> It seems that there's a maximum value that pov won't trace beyond.

Yep, from frame.h I found the Max_Distance constant, whose value is 1e7. 
Apparently it is used in all intersection calculations as an upper limit; 
intersections found farther away are just ignored.

Post a reply to this message

Johannes Dahlstrom wrote:

> intersection
> intersections

Ray-object-intersections, that is, not the CSG ones ;)

Post a reply to this message

Johannes Dahlstrom <sad### [at] tkukoulufi> wrote in message
news:3de4c9e2@news.povray.org...
> Johannes Dahlstrom wrote:
>
> > intersection
> > intersections
>
> Ray-object-intersections, that is, not the CSG ones ;)
>

:) Yeah I realised what you meant.

Speaking as a programmer this sounds like rather shoddy coding! Okay I'm sure
values near the limits of floating point numbers would cause problems, but the
limit is around 1e38, so I'd expect it could get much bigger than 1e7 without
any problems. Ah well, I'll just use a global scale in all my big scenes...

BTW, does anyone know if there's a similar lower accuracy limit? i.e. the
shortest distance below which two surfaces will be judged to be in the same
place?

--
Tek
http://www.evilsuperbrain.com

Post a reply to this message

On Wed, 27 Nov 2002 18:56:13 -0000, "Tek" <tek### [at] evilsuperbraincom>
wrote:

>Speaking as a programmer this sounds like rather shoddy coding! Okay I'm sure
>values near the limits of floating point numbers would cause problems, but the
>limit is around 1e38, so I'd expect it could get much bigger than 1e7 without
>any problems.

Don't forget that some shapes require solving polynomials of a very
high degree, and large values, even though way below the theoretical
fp limit, can easily cause considerable problems for the root solver
when used in high powers.

>BTW, does anyone know if there's a similar lower accuracy limit? i.e. the
>shortest distance below which two surfaces will be judged to be in the same
>place?

Yes, there is. Any intersection closer than EPSILON to the current one
is ignored. The reason is simple - it can easily be the same
intersection :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Tek wrote:

> Speaking as a programmer this sounds like rather shoddy coding! Okay I'm
> sure values near the limits of floating point numbers would cause
> problems, but the limit is around 1e38, so I'd expect it could get much
> bigger than 1e7 without any problems. Ah well, I'll just use a global
> scale in all my big scenes...

Hmm... It might have something to do with the nature of floating point 
numbers - that a number's accuracy decreases as the magnitude increases 
("the dot is shifted", so to say). Thus, a unit-radius sphere a billion 
units away could be prone to artifacts - but what's the point of using that 
small objects that far away anyway?-)


> BTW, does anyone know if there's a similar lower accuracy limit? i.e. the
> shortest distance below which two surfaces will be judged to be in the
> same place?

There seem to be several different constants to be used with different 
calculations. Particularly, each object type has its own "depth_tolerance" 
value for ignoring intersection points too close to the ray origin. For a 
sphere it is 1e-6, but for a blob as much as 1e-2.

Post a reply to this message