 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/2/2017 8:37 PM, green wrote:
> "Kenneth" <kdw### [at] gmail com> wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 29.06.2017 um 21:05 schrieb Bald Eagle:
>>>
>>
>>>
>>> You might be interested to hear that _UberPOV_ already provides an
>>> experimental mechanism that can be used to that end:
>>>
>>> [snip]
>>
>>> (In UberPOV for Windows, this mechanism will even retain data between
>>> consecutive runs of a single-frame scene...
>>
>> From visiting the UberPOV Github repository here...
>>
>> https://github.com/UberPOV/UberPOV
>>
>> ... I'm honestly not sure how to download it, or which of the separate components
>> are needed. I assume that this is the Windows version(?) Does it need to be
>> *compiled* on my end? I don't see a clearly-labeled Windows executable there.
>
> it is not you; it is github. github is retarded. i suspect it was made by
> linuxians.
Exterminate! Exterminate! Exterminate!
https://www.youtube.com/watch?v=mxD-5z_xHBU
> above the red bar is cryptic scribbling 'commits', 'branches', 'releases' etc,
> click on 'releases'. there you will find the binaries.
>
>
Thanks for the info. :D
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Exterminate! Exterminate! Exterminate!
You would make Davros proud.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/2/2017 11:56 PM, Bald Eagle wrote:
>
>> Exterminate! Exterminate! Exterminate!
>
> You would make Davros proud.
>
>
I am of that age. :)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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...
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!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
