POV-Ray : Newsgroups : povray.animations : Clockless_Animation Server Time
29 Mar 2024 12:03:01 EDT (-0400)
  Clockless_Animation (Message 11 to 20 of 44)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Mr
Subject: Re: Clockless_Animation
Date: 27 Jun 2017 04:30:01
Message: <web.595216a5992dfbe216086ed00@news.povray.org>
"Mr" <nomail@nomail> wrote:

> > animation and real-time rendering are two entirely(?) different things.
>
> What should I use, if any of these, for Blender real time mode?
>
> (have a try at Cycles viewport rendered mode to get an idea of required usage)

or also Blender Internal which has this mode too, being closer to POV in its
architecture.


Post a reply to this message

From: William F Pokorny
Subject: Re: Clockless_Animation
Date: 27 Jun 2017 08:39:52
Message: <59525218$1@news.povray.org>
On 06/26/2017 03:28 PM, Thorsten Froehlich wrote:
> "muyu" <lsy### [at] gmailcom> wrote:
>> I would like to generate animation using a very big file. It took a lot of time
>> in sparsing. Each time, only the camera position will change.  As I see,
>> Clockless_Animation may be the function to save the time cost.
>>
>> I set the following in .ini file:
>> Real_Time_Raytracing = on
>> Clockless_Animation = on
>>
>>
>> I add several camera positions, but there is in the DSL. The rendering runs
>> without stop and no output.
>>
>> I guess that I missed some information. Thanks in advance.
> 
> You are mixing up two things. The real-time raytracing "feature" is just a demo
> mode on Windows, and was never meant to be used for anything useful other than
> showing how powerful modern processors are, i.e. on a computer at at least
> tradeshow booth.
> 
> The clockless animation on the other hand is a useful features that allows you
> to move the camera in a scene without reparsing. While it was developed for the
> demo mode at first, and that is probably where you got the idea to use both
> settings together, but really, you just need to disable the real-time rendering
> option (which effectively just screws up internal options and their logic to
> bypass certain code needed for proper rendering). Then, the clockless animation
> shoudl work as documented as long as you have a camera for each frame in your
> scene as described in the docs.
> 
> 
Thanks for the information. I tried the clockless option apart from the 
real time rendering option without success. Results just posted at:

https://github.com/POV-Ray/povray/issues/301

Am I missing how to make clockless animation (no scene reload) work on 
linux?

Bill P.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Clockless_Animation
Date: 27 Jun 2017 12:50:00
Message: <web.59528c34992dfbe26c6d834f0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 26.06.2017 um 21:32 schrieb Thorsten Froehlich:
>
> >> I've opened at github issue. See:
> >>
> >> https://github.com/POV-Ray/povray/issues/301
> >
> > .... which should just be closed because you reported something that works
> > exactly as designed. The mode is for developers to specify exact behavior in a
> > hands-on manner with one on one support, and not for users without such
> > guidance. The "solution" should probably be to disable that option from being
> > accepted by a condictional compile as well ;-)
>
> Actually, the issue should be left open until it is resolved.
>
> In my book, the first step in resolving it would be to document what the
> real-time rendering mode is for anyway (even if that documentation would
> just be a line saying "not intended for normal users", that would be an
> improvement over the current situation).
>
> As demonstrated, it would also be helpful to document that clockless
> animation and real-time rendering are two entirely(?) different things.

Well, here is the background:
For the Mac 3.6 version I was looking for an Easter Egg to hide in the about box
of POV-Ray for Mac. With some modifications to the, back then single threaded,
code, I was able to pull that off by feeding a custom camera setup as well as a
fixed scene (not parsed but hardcoded structures without texturing) into the
core. Chris played with a variant for Windows.

Now when 3.7 development was far enough along, Intel asked Chris for a demo as
back then POV-Ray was one of the few very efficient multithreaded visual
applications. However, we had since moved to a message based system for
rendering. So he needed to add hooks (the RTR_HACK) to bypass the message
passing. That is also why nothing happens when one trys to use that feature.

In order to control the hack, he had added real-time rendering option.

However, he also still needed a way to control the camera. As the goal was to
use a regular scene file, he had the idea to just allow multiple camera
definitions as the camera object is pretty much independent of the scene file.
This is where the clockless animation comes in. It basically permits multiple
cameras, which are selected based on the frame number.

As far as I recall, you need to enable that option plus the animation feature
with frame numbers, and POV-Ray will render the scene...


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Clockless_Animation
Date: 27 Jun 2017 12:55:00
Message: <web.59528d07992dfbe26c6d834f0@news.povray.org>
"Mr" <nomail@nomail> wrote:
> "Mr" <nomail@nomail> wrote:
>
> > > animation and real-time rendering are two entirely(?) different things.
> >
> > What should I use, if any of these, for Blender real time mode?
> >
> > (have a try at Cycles viewport rendered mode to get an idea of required usage)
>
> or also Blender Internal which has this mode too, being closer to POV in its
> architecture.

This is just a similarity between the name of a feature in POV-Ray and Blender
and has absolutely  nothing to do with Blender at all!


Post a reply to this message

From: Kenneth
Subject: Re: Clockless_Animation
Date: 29 Jun 2017 14:25:01
Message: <web.59554419992dfbe2883fb31c0@news.povray.org>
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

From: Bald Eagle
Subject: Re: Clockless_Animation
Date: 29 Jun 2017 15:10:00
Message: <web.59554f72992dfbe2c437ac910@news.povray.org>
"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

From: Stephen
Subject: Re: Clockless_Animation
Date: 29 Jun 2017 15:47:46
Message: <59555962@news.povray.org>
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

From: Kenneth
Subject: Re: Clockless_Animation
Date: 29 Jun 2017 23:50:01
Message: <web.5955ca43992dfbe2883fb31c0@news.povray.org>
"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

From: Kenneth
Subject: Re: Clockless_Animation
Date: 30 Jun 2017 00:50:00
Message: <web.5955d770992dfbe2883fb31c0@news.povray.org>
"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

From: Kenneth
Subject: Re: Clockless_Animation
Date: 30 Jun 2017 01:00:01
Message: <web.5955da2b992dfbe2883fb31c0@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.