I ran some tests in Windows-- with the downloaded demo scene "cube_rtr.pov" and
its "cube.inc" file-- and this is what I've found. (I happen to be running
POV-Ray v3.7.1 beta 8)

1) I turned on animation in my 'quickres.ini' file, by specifying
'Final_Frame=100'-- assuming that it was required. By the way, the demo scene
does not have the 'frame_number' keyword anywhere (or 'clock' either, for that
matter.)

3) clockless animation (+kla) does not work *by itself*-- the animation images
are rendered, but the camera doesn't move at all, and each frame takes the same
amount of time to parse. Assuming that the scene needed 'frame_number'
somewhere, I added it to the camera definition here...

#declare ck = ck + 0.01*frame_number;

..... but that didn't help. Then, guessing that the camera(s) needed to be
#declared first, I did that too. Still no success.

3) However, using *both* clockless animation and real-time raytracing...
                     +kla +rtr
and running the scene *as-is* (no frame_number addition or #declared cameras),
the scene does indeed work as planned. The full parsing is done only for frame
1; the following frames render in real time.  But there's no image output now...
which I kind of expected, since these experimental features are really only for
demonstration purposes. But unexpectedly, the animation proceeded *past* frame
100; in fact, it's never-ending, unless you stop the render.

4) From the results of 3), turning on POV-Ray's animation feature ('Final_Frame
= ...) is NOT necessary; apparently it's turned on by default when using the
combination of  +kla +rtr  and runs forever.

In order to really see the time-savings of these rendering features, I wanted
the scene to take much more time to initially parse. (The scene as-is parses too
fast on a modern computer.) The simplest way I could think of was to add  a box
object to the scene, with a HIGH-rez image_map on it. That did the trick ;-)

I would agree with previous posts here that the documentation needs more
information and clarity about these features: their co-dependent operation; the
fact that POV-Ray's 'animation' feature does not need to be turned on; etc.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> I would agree with previous posts here that the documentation needs more
> information and clarity about these features: their co-dependent operation; the
> fact that POV-Ray's 'animation' feature does not need to be turned on; etc.

I'd say that packaging a working scene file and .ini in a subdirectory of the
distribution, posting it here, or including it the docs is by far the best way
to "document" its usage.


About this whole clockless animation - It would be interesting if it could be
modified so that POV-Ray split a scene into 2 separately parsed sections - a
static part, and a dynamic part.  Then you could have, say, a complex terrain
that takes forever to parse - but only gets parsed once, and then clouds or the
sun, or an automobile or a ball that is the only thing that changes position in
the scene.

I don't know if that's feasible, but just throwing it out there.  ;)

Post a reply to this message

On 6/29/2017 7:18 PM, Kenneth wrote:
> I ran some tests in Windows--

 From what I can remember is that Clockless_Animation was implemented as 
a demo to show that it could be done, some time ago. But no one showed 
any interest in it and it was left as it was. A Proof of concept.
I will be pleasantly surprised if it can be brought into a useful state,

-- 

Regards
     Stephen

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> In order to really see the time-savings of these rendering features, I wanted
> the scene to take much more time to initially parse. (The scene as-is parses too
> fast on a modern computer.) The simplest way I could think of was to add  a box
> object to the scene, with a HIGH-rez image_map on it. That did the trick ;-)
>

There's an even simpler way to create meaningless extra parsing time for the
first animation frame: use a meaningless #while loop!

#declare K = 0;
#while(K <= 10000)
#declare K = K + .01;
#end

Change values to waste as much time as you want. ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> 3)...But unexpectedly, the animation proceeded *past* frame
> 100; in fact, it's never-ending, unless you stop the render.
>

That's not quite correct. The demo scene contains a #while loop, with the 'total
number of cameras' determined by the loop's counter. Although the animation
*does* proceed forever, it's because the #while loop itself is endlessly
repeated-- kind of like viewing an animated movie clip (with a definite number
of frames) that continuously loops. A clever feature, IMO!

From further experimenting, here are a few more bits of behavior worth
mentioning...

* The cameras in the scene don't *need* to be created in a #while loop or #for
loop (although that's definitely the most practical approach.) You could write
1001 INDIVIDUAL camera definitions-- with changing values of course-- and the
cameras are chosen one after another automatically, one for each new animation
frame.

* Using only 'real-time raytracing' ( +rtr )  *by itself* has odd behavior: Only
one animation frame appears-- it's with the *final* camera-- but the rendering
continues 'behind the scenes' endlessly.

* If your animated scene already has 'clock' and/or 'frame_number' in it for
changing something, that's OK, you don't need to comment-out those things; but
those actions are ignored (as if clock and frame_number are both set to zero and
remain so.) For that reason alone, you can't change anything in the scene
*except* the camera. But that's really useful anyway, for doing quick(er)
camera-movement test renders.

Given a typical animation scene-- one that wasn't initially set up to use these
features -- here's one way to make a few minor changes to the camera so that it
will work correctly (assuming that the camera was using 'clock' to vary its
parameters, and with default values of 0.0-to-1.0 for simplicity):

ORIGINAL camera statement example:
camera {
  perspective
  location  <0, 3 - 1.5*clock, -5>
  look_at   <-3*clock, 2 - 1.2*clock,  .5*clock>
  right     x*image_width/image_height
  angle 55
}

CLOCK (for the camera only) needs to be substituted with a #declared name:
#declare CLK = 0; // no longer the real clock

#while(CLK < 1.0)
// new camera statement...
camera {
  perspective
  location  <0, 3 - 1.5*CLK, -5>
  look_at   <-3*CLK, 2 - 1.2*CLK,  .5*CLK>
  right     x*image_width/image_height
  angle 55
}
#declare CLK = CLK + .005; // assuming that the original animation ran
// for 200 frames-- 1.0/.005 = 200
#end

For doing a typical NORMAL render of the animation, all that's necessary is to
comment-out the added #while-loop-specific parts (and re-#declare CLK = clock).

Post a reply to this message

Forgot to add this:

If POV-Ray's 'animation' feature is already 'on' (i.e., Final_Frame = ...) it
can be left on (or turned off); either way doesn't matter, as it's completely
ignored. The number of CAMERAS in the scene determines the length of the
animation.

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

>
>  From what I can remember is that Clockless_Animation was implemented as
> a demo to show that it could be done, some time ago. But no one showed
> any interest in it and it was left as it was.

I have to admit that I didn't work with it either-- mainly because I didn't
truly know HOW to use it! But I'm beginning to see the real power of these new
features. I just ran an older and not-too-complex animation scene (with a few
necessary changes to the camera definition) and saw a 3-fold decrease in total
render time. With a *complex* slow-to-parse scene, the time-savings could be
enormous! Of course, right now only the camera can be moved; but that's quite
useful by itself, for testing.

If I had only known... :-(

Post a reply to this message

Am 29.06.2017 um 21:05 schrieb Bald Eagle:

> About this whole clockless animation - It would be interesting if it could be
> modified so that POV-Ray split a scene into 2 separately parsed sections - a
> static part, and a dynamic part.  Then you could have, say, a complex terrain
> that takes forever to parse - but only gets parsed once, and then clouds or the
> sun, or an automobile or a ball that is the only thing that changes position in
> the scene.

You might be interested to hear that _UberPOV_ already provides an
experimental mechanism that can be used to that end:

    #persistent Foo = ...;

defines an identifier that will survive across parser runs in an
animation. So you could use

    #ifndef(MyStaticScene)
      #persistent MyStaticScene = union {
        // Static stuff present in all frames goes here
      }
    #end
    object { MyStaticScene }
    // Dynamic stuff changing between individual frames goes here

This mechanism is also flexible enough to define the individual
components of your animation's dynamic portion just once, and in the
individual frames just rotate and translate them to their final
orientation and location.


(In UberPOV for Windows, this mechanism will even retain data between
consecutive runs of a single-frame scene, or even different scenes; but
that's more an unintended side effect of its implementation rather than
deliberate, and may be subject to change. In essence, variables declared
using `#persistent` are just never deleted as long as UberPOV is
running. This may be subject to change.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> You might be interested to hear that _UberPOV_ already provides an
> experimental mechanism that can be used to that end:
>
>     #persistent Foo = ...;
.....
> This mechanism is also flexible enough to define the individual
> components of your animation's dynamic portion just once, and in the
> individual frames just rotate and translate them to their final
> orientation and location.

Aha.  So many things to experiment with, and it hadn't occurred to me that the
#persistent directive would be applicable to things other than "variables" -
though I suppose to a certain degree, everything is just an identifier with
"data" stuffed into that bin.
I can see Kenneth salivating now, rubbing his hands together, and getting the
42-cup coffee urn fired up for some very nice animations....   :D

> (In UberPOV for Windows, this mechanism will even retain data between
> consecutive runs of a single-frame scene, or even different scenes; but
> that's more an unintended side effect of its implementation rather than
> deliberate, and may be subject to change. In essence, variables declared
> using `#persistent` are just never deleted as long as UberPOV is
> running. This may be subject to change.)

Hmmm.
And I suppose a way to undo that would be #ifdef() and then #undef().

Post a reply to this message

On 6/30/2017 6:14 AM, Kenneth wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>>
>>   From what I can remember is that Clockless_Animation was implemented as
>> a demo to show that it could be done, some time ago. But no one showed
>> any interest in it and it was left as it was.
>
> I have to admit that I didn't work with it either-- mainly because I didn't
> truly know HOW to use it! But I'm beginning to see the real power of these new
> features. I just ran an older and not-too-complex animation scene (with a few
> necessary changes to the camera definition) and saw a 3-fold decrease in total
> render time. With a *complex* slow-to-parse scene, the time-savings could be
> enormous! Of course, right now only the camera can be moved; but that's quite
> useful by itself, for testing.
>

The mesh_camera is another feature that came out about the same time, I 
think. I've read the docs and still don't understand what it does. :(


> If I had only known... :-(
>

The story of my life. :)


-- 

Regards
     Stephen

Post a reply to this message