This scene file isn't getting any younger! By that I mean it doesn't work with
current version of MegaPOV (1.2.1) and I don't know how to correct for that yet.

Posting this anyhow since I couldn't locate another SDL of it here at the
newsgroups, and in response to animation of something very similar done almost
17 years ago:

http://news.povray.org/povray.binaries.animations/thread/%3Cweb.589bbb51d99c5e6b9c5d6c810%40news.povray.org%3E/

Bob

Post a reply to this message

Attachments:
Download 'rmf-mountains-lakes-2001.pov.txt' (26 KB)

On 9-2-2017 2:02, omniverse wrote:
> This scene file isn't getting any younger! By that I mean it doesn't work with
> current version of MegaPOV (1.2.1) and I don't know how to correct for that yet.
>
> Posting this anyhow since I couldn't locate another SDL of it here at the
> newsgroups, and in response to animation of something very similar done almost
> 17 years ago:
>
>
http://news.povray.org/povray.binaries.animations/thread/%3Cweb.589bbb51d99c5e6b9c5d6c810%40news.povray.org%3E/
>
> Bob
>

Could this attached file help? It is from Bob Hugues (2003). It is not 
an animation but I think the scene's purpose is identical.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (6 KB)

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 9-2-2017 2:02, omniverse wrote:
>
> Could this attached file help? It is from Bob Hughes (2003). It is not
> an animation but I think the scene's purpose is identical.

Wow Thomas! Another oldie (also from me BTW).
Maybe too slow for animation, I was surprised how long it took when trying it
here. Maybe it's that radiosity, easily skipped.

I was able to get that old MegaPOV animation to render. What was stopping me
before was the old style slope pattern, only needed newer syntax.

And the animation started below the landscape so I changed the noise type
(actually didn't have one before) for the isosurface f_ridged_mf function.

That modified scene file is attached here, despite needing much more done to it.

Bob

Post a reply to this message

Attachments:
Download 'rmf-mountains_lakes_2001-2017.pov.txt' (27 KB)

In my rush to post that 3.7-renderable file I neglected to notice the viewpoint
changes abruptly during animation. Apparently made to be like camera changes or
a look right and left, so not just ahead in flight path. Very confusing in a
very short animation.
Not only that, but the clocked splines are cubic and don't seem to have correct
beginning or ends. Of course I can only guess what was originally done without a
long time going over it again.

Suffice to say, replacing with the following seems better than it was, if you
would like to try this:

#declare CamSpos=
spline {
        cubic_spline
        -0.1,<.05,.1,-9.5>*CamDist // added
        0,<.1,.167,-9>*CamDist
        .1,<.15,.29,-8.75>*CamDist
        .175,<.225,.33,-8.5>*CamDist
        .225,<.5,.425,-8.125>*CamDist
        .5,<0,.4125,-7>*CamDist
        .775,<-.5,.425,-6>*CamDist
        .875,<-.2,.3,-5.5>*CamDist
        .925,<-.125,.125,-5.25>*CamDist
        1,<-.05,.02,-5>*CamDist
        //1.1,<-.025,0,-4.5>*CamDist // added, not used
}

#declare CamSpnt=
spline {
        cubic_spline
        -0.1,<0,.1,-9> // added
        0,<.1,.2,-8.5>
        .1,<.15,.35,-8>
        .225,<.475,.275,-7.5>
        .33,<.225,.225,-7>
        .5,<0,.25,-6.75>
        .775,<-.475,.275,-5.5>
        .9,<-.133,.2,-5>
        .95,<-.1,.125,-4.75>
        1,<-.05,.02,-4.5>
       // 1.1,<-.025,0,-4> // added, not used
}

And I haven't tried anything with the flying car portion. I think Part=2 was
supposed to be for that. Not sure.

Bob

Post a reply to this message

On 9-2-2017 14:40, omniverse wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 9-2-2017 2:02, omniverse wrote:
>>
>> Could this attached file help? It is from Bob Hughes (2003). It is not
>> an animation but I think the scene's purpose is identical.
>
> Wow Thomas! Another oldie (also from me BTW).

Hi Bob, I had not immediately made the connection :-)

> Maybe too slow for animation, I was surprised how long it took when trying it
> here. Maybe it's that radiosity, easily skipped.

It is a slow process indeed. I still intend to study this scene more 
closely. I find the differential snow cover very tempting to use one way 
or another in a scene.

>
> I was able to get that old MegaPOV animation to render. What was stopping me
> before was the old style slope pattern, only needed newer syntax.
>
> And the animation started below the landscape so I changed the noise type
> (actually didn't have one before) for the isosurface f_ridged_mf function.
>
> That modified scene file is attached here, despite needing much more done to it.
>
> Bob
>


-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 9-2-2017 14:40, omniverse wrote:
> > Maybe too slow for (quick) animation, I was surprised how long it took when trying
it
> > here. Maybe it's that radiosity, easily skipped.
>
> It is a slow process indeed. I still intend to study this scene more
> closely. I find the differential snow cover very tempting to use one way
> or another in a scene.

You're sure to get something interesting rendered.

This had me looking at slope pattern in the documentation and something I wasn't
aware of is the "new to 3.7" point_at for it. Or if I did know I had forgotten
it.

http://wiki.povray.org/content/Reference:Slope_Pattern

Since point_at isn't used in the snow slope pattern I'm guessing a change to
that might need adjustment, since the doc says altitude can't be used in
conjunction with point_at.
Although, looking again at the scene file altitude is not used anyway!

Food for thought anyhow, because it seems like it would be what SunPosition is
made for.

Bob

Post a reply to this message

Am 10.02.2017 um 11:15 schrieb omniverse:

> This had me looking at slope pattern in the documentation and something I wasn't
> aware of is the "new to 3.7" point_at for it. Or if I did know I had forgotten
> it.
...
> Food for thought anyhow, because it seems like it would be what SunPosition is
> made for.

Only if the sun is supposed to be very close, so that its rays are
supposed to be noticeably non-parallel. Otherwise the direction vector
would probably be the better choice.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 10.02.2017 um 11:15 schrieb omniverse:
>
> > This had me looking at slope pattern in the documentation and something I wasn't
> > aware of is the "new to 3.7" point_at for it. Or if I did know I had forgotten
> > it.
> ...
> > Food for thought anyhow, because it seems like it would be what SunPosition is
> > made for.
>
> Only if the sun is supposed to be very close, so that its rays are
> supposed to be noticeably non-parallel. Otherwise the direction vector
> would probably be the better choice.

Hmm. I think I know what you're saying, which is direction vector easier and
that point_at is intended for more localized behavior of slope.
At least that's my guess.

I just tried something with point_at anyway, going by your saying 'sun very
close'.

Took the SunPosition numbers given by it's dot x y and z.
Divided those (less decimals) into the slope SunPosition for the point_at and it
resembled the direction vector method.
Not the same as direction only, but similar perhaps.

#declare pigment3 =
pigment {
  slope {
    point_at
    <SunPosition.x/818827576,SunPosition.y/163128554,SunPosition.z/550373032>/2
....

Post a reply to this message

I see what Christoph and you are meaning. I am busy with another POV 
scene at the moment but I need to test this out myself too...

-- 
Thomas

Post a reply to this message

Regarding current changes to this SDL, most recent file attached here.
Following is from the posting at binaries.animations:

New and improved, and maybe that's saying too much. LOL

Too large a file for here, almost 7 MB.

https://youtu.be/aLwYm9aBQ80

Still a wild ride because of a crumbling natural bridge fly-thru, and my sloppy
attempt at slowing the flight at that point in the animation. I messed up the
cubic spline path there, it was supposed to move slowly past the natural bridge.
Timed it wrong.

No worries, you can retry it yourself. Posting the updated scene file at
binaries.scene-files once again. Better clouds in motion and casting shadows.
Although parameters are minimal quality, for isosurface too, for faster frame
rendering.

At least I got rid of the annoying camera discontinuities caused by adding
different vectors together from one clock range to the next, see previous SDL.

This particular animation, 320X240 and 600 frames with default antialiasing,
took about 10 hours on a i5 processor @ 3.4GHz.

Bob

Post a reply to this message

Attachments:
Download 'rmf-mountains_lakes_2017.pov.txt' (29 KB)