POV-Ray : Newsgroups : povray.animations : Clockless_Animation Server Time
28 Mar 2024 12:30:31 EDT (-0400)
  Clockless_Animation (Message 35 to 44 of 44)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: Clockless_Animation
Date: 3 Jul 2017 12:55:53
Message: <595a7719$1@news.povray.org>
Am 03.07.2017 um 18:27 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> As guessed by Stephen, that would be the source package, which you
>> /could/ use to compile UberPOV from source codes.
>>
>> [snip]
>>
>> https://github.com/UberPOV/UberPOV/releases
>>
>> There, for each such well-defined version you'll again find at least the
>> corresponding source code package (in both zip and tar.gz format), but
>> usually also pre-built Windows binaries.
>>
> 
> Excellent! Thanks (and to Stephen and Green as well.) Yeah, the Github way of
> doing things seems a bit odd and convoluted. Well, at least to me...

I guess it's not GitHub in particular, but rather git. (And yes, that's
/penultimately/ Linux-ey; not surprising actually, given that it was
/invented/ by Linus Torvalds himself /for/ kernel development ;))

> SO... to help others... the Windows binary download (I happen to have chosen the
> 64-bit version) is only a single file called   Uberpov64  and is meant to
> (temporarily) replace v3.70's  'pvengine'  file, in POV-Ray's "bin" directory--
> identical to how the various 3.71 ALPHA releases were installed.
> 
> Once I install it there and see the results, I might even try to do likewise in
> one of the latest 3.71 'beta' releases-- just to see what happens ;-)  If there
> is a tremendous explosion on the East Coast of the U.S., you'll know the source,
> ha!

You shouldn't do that. There is no advantage in transplanting UberPOV to
a v3.7.1-beta system whatsoever; to the contrary, you may find UberPOV
interfering with the v3.7.0 installation in interesting ways.

(In a nutshell, the v3.7.1-beta uses directories and registry keys named
"v3.7-beta", whereas v3.7.0 and the latest UberPOV versions use registry
keys named "v3.7".)


Post a reply to this message

From: Bald Eagle
Subject: Re: Clockless_Animation
Date: 3 Jul 2017 15:20:00
Message: <web.595a98a8992dfbe2acfa72180@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> If there
> is a tremendous explosion on the East Coast of the U.S., you'll know the source,
> ha!

They'll probably still try to blame it on us here in NH.
:|


Post a reply to this message

From: Kenneth
Subject: Re: Clockless_Animation
Date: 4 Jul 2017 11:10:00
Message: <web.595baf55992dfbe2883fb31c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 03.07.2017 um 18:27 schrieb Kenneth:
> >
> > Once I install it there and see the results, I might even try to do
> > likewise in one of the latest 3.71 'beta' releases-- just to see what
> > happens ;-)  If there is a tremendous explosion on the East Coast of
> > the U.S., you'll know the source, ha!
>
> You shouldn't do that.

:-O

Good safety tip!! I was just about ready to 'light the fuse'...

Disaster averted! Thanks.


Post a reply to this message

From: Kenneth
Subject: Re: Clockless_Animation
Date: 11 Jul 2017 00:55:00
Message: <web.59645922992dfbe2883fb31c0@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> 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).

While doing some more tests of these features, I discovered that I made a small
mistake in that final comment, and in how I set up the #while loop itself-- due
to the nature of how CLOCK normally runs.

On the first frame of a regular animation, CLOCK is equal to 1/200, not 0.0
(assuming that the animation length in either scenario is 200 frames.) To get
consistent animation when switching back and forth between scenarios, the #while
loop should be like this when rendering with  +kla  +rtr  ...

#declare CLK = 1/200; // not zero
#while(CLK <= 1.0) // <= , not <
// 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


Post a reply to this message

From: muyu
Subject: Re: Clockless_Animation
Date: 3 Jan 2018 10:20:01
Message: <web.5a4cf3e7992dfbe2cf0bfa9c0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.

Happy new year first. I am back to this problem.

I did another search in the forum. It seems that UberPOV can pass data through
frames without parsing each time. Is this true?
The discussion is here
http://news.povray.org/povray.animations/thread/%3Cweb.565084806f515a457a3e03fe0%40news.povray.org%3E/?mtop=403126

Thanks in advance.

Shouyang


Post a reply to this message

From: clipka
Subject: Re: Clockless_Animation
Date: 3 Jan 2018 13:20:04
Message: <5a4d1ed4$1@news.povray.org>
Am 03.01.2018 um 16:16 schrieb muyu:

> I did another search in the forum. It seems that UberPOV can pass data through
> frames without parsing each time. Is this true?

Yes, absolutely.


Post a reply to this message

From: muyu
Subject: Re: Clockless_Animation
Date: 4 Jan 2018 07:05:00
Message: <web.5a4e17ec992dfbe2cf0bfa9c0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 03.01.2018 um 16:16 schrieb muyu:
>
> > I did another search in the forum. It seems that UberPOV can pass data through
> > frames without parsing each time. Is this true?
>
> Yes, absolutely.

I did not find material to show how to use this feature. Could you please give
an simple example? Thanks a lot.

Shouyang


Post a reply to this message

From: clipka
Subject: Re: Clockless_Animation
Date: 4 Jan 2018 11:40:35
Message: <5a4e5903$1@news.povray.org>
Am 04.01.2018 um 13:02 schrieb muyu:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 03.01.2018 um 16:16 schrieb muyu:
>>
>>> I did another search in the forum. It seems that UberPOV can pass data through
>>> frames without parsing each time. Is this true?
>>
>> Yes, absolutely.
> 
> I did not find material to show how to use this feature. Could you please give
> an simple example? Thanks a lot.

For example, to load a complex mesh just once, you could use:

    #ifndef MyMesh
      #persistent MyMesh = mesh { ... }
    #endif
    object { MyMesh }

Or, to load an image map just once, you could use:

    #ifndef MyPigment
      #persistent MyPigment = pigment {
        image_map { ... }
      }
    #endif
    object { SomeObject
      texture {
        pigment { MyPigment }
        finish { ... }
      }
    }


In essence, `#persistent` works like `#declare`, but the variable sticks
around until UberPOV exits.

You'll still need to assemble the contents of such persistent variables
into a new scene for each frame; however, you can prepare arbitrarily
complex objects in this manner, such as nested CSG unions.


Post a reply to this message

From: muyu
Subject: Re: Clockless_Animation
Date: 5 Jan 2018 20:20:00
Message: <web.5a502405992dfbe2553834de0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 04.01.2018 um 13:02 schrieb muyu:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 03.01.2018 um 16:16 schrieb muyu:
> >>
> >>> I did another search in the forum. It seems that UberPOV can pass data through
> >>> frames without parsing each time. Is this true?
> >>
> >> Yes, absolutely.
> >
> > I did not find material to show how to use this feature. Could you please give
> > an simple example? Thanks a lot.
>
> For example, to load a complex mesh just once, you could use:
>
>     #ifndef MyMesh
>       #persistent MyMesh = mesh { ... }
>     #endif
>     object { MyMesh }
>
> Or, to load an image map just once, you could use:
>
>     #ifndef MyPigment
>       #persistent MyPigment = pigment {
>         image_map { ... }
>       }
>     #endif
>     object { SomeObject
>       texture {
>         pigment { MyPigment }
>         finish { ... }
>       }
>     }
>
>
> In essence, `#persistent` works like `#declare`, but the variable sticks
> around until UberPOV exits.
>
> You'll still need to assemble the contents of such persistent variables
> into a new scene for each frame; however, you can prepare arbitrarily
> complex objects in this manner, such as nested CSG unions.

Thanks a lot for your suggestions. But it still need parsing from frame to
frame. I upload my pov file in this link
http://news.povray.org/povray.binaries.animations/message/%3Cweb.5a50228f5c821073553834de0%40news.povray.org%3E/#%3Cweb
.5a50228f5c821073553834de0%40news.povray.org%3E

Could you please help have a look? Thanks a lot in advance.

Have a nice weekend
Shouyang


Post a reply to this message

From: clipka
Subject: Re: Clockless_Animation
Date: 6 Jan 2018 00:55:27
Message: <5a5064cf$1@news.povray.org>
Am 06.01.2018 um 02:19 schrieb muyu:

>> In essence, `#persistent` works like `#declare`, but the variable sticks
>> around until UberPOV exits.
>>
>> You'll still need to assemble the contents of such persistent variables
>> into a new scene for each frame; however, you can prepare arbitrarily
>> complex objects in this manner, such as nested CSG unions.
> 
> Thanks a lot for your suggestions. But it still need parsing from frame to
> frame.

Well, yes, of course. The scene needs to be parsed again for each frame,
if only to insert the `#persistent`-declared object into the scene for
that frame in a manner that's unique to that particular frame (after all
you want /some/ difference between the frames of an animation).

Parsing speed is still increased, because UberPOV doesn't actually need
to process the tokens in the `#ifndef FOO #persistent FOO = ... #endif`
blocks again, but can just skip over them instead. For example, in an
image based pigment the most time is spent in loading the actual image
file, not parsing.

In cases where the block is just a long litany of loopless SDL code that
would be easy to parse except for its sheer length (as might be the case
for mesh2 objects), another trick you can use is to pull out that code
into an include file, and place the `#include` statement into the
`#ifndef... #endif` block, e.g.:

    // main file
    #ifndef MyMesh
      #include "mymesh.inc"
    #endif
    object { MyMesh }

    // mymesh.inc
    #persistent MyMesh = mesh2 {
      ...
    }

Or, if your mesh is generated by a 3rd party utility and uses
`#declare`, you might use:

    // main file
    #ifndef MyMesh
      #include "mymesh.inc"
      #persistent MyMesh = object { ExportedMesh }
    #endif

    // mymesh.inc
    #declare ExportedMesh = mesh2 {
      ...
    }


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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