I've seen a difference in one example scene animation from 3.6.1 and 
3.7.beta.7.

Since I was checking on this new beta for its "animation support" I went 
about editing the file Scenes\Animations\speclr.pov so it would show 
roughness variations along with the already changing specular amount, which 
it already did, then realized the decimal number returned by str() was 
skipping 0.1 (going directly from 0.0 to 0.2).

Next I found Cyclic_Animation in the file speclr.ini didn't seem to work the 
same as in 3.6, or at least that something was different about it. That 
meaning, the final scene values don't stay the same between the two 
versions. In this particular case my roughness value went negative due to 
there being one too many calculations with the clock variable.

Sorry, I haven't delved far into this, I just thought it peculiar that there 
would be any differences like this between the program versions at all and 
maybe this could be a bug. Or I thought perhaps the animation functionality 
might still be incomplete. Hopefully I'm not trying to report something 
prematurely.

P.S. another hurray for Chris and all others involved in getting this beta 
out.

Bob

Post a reply to this message

Sorry about the incorrect date of my posting this. Had tried the previous 
beta again and neglected to switch my system clock back to today.

Post a reply to this message

I was looking at this again this morning, using the unmodified 
scenes\animations\speclr.pov and speclr.ini files, and the two POV-Ray 
versions (3.6.1 and 3.7.beta.7 {icl8}) definitely use 'clock' differently.

Again, checking this in version 3.6 shows the clock (or specular value) 
counts like:

0.0, 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8, 0.9. Skipping 0.5.

And in the beta this is done like:

0.0, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0. Skipping 0.1.

Also, in the beta, I saw the specular (clock) value go up to 1.1 instead of 
remaining at or below 1.0 like it is supposed to. Cyclic_Animation=on keeps 
it from going beyond 1.0 but with it "off" it becomes 1.1 at frame 10. So 
this seems the important aspect, that clock should never jump over 1.0 even 
if cyclic is off... unless the Initial_Clock and Final_Clock aren't 
defaults, of course.

Might be something to do with str() but I must leave that up to you to 
figure out.

Bob Hughes

Post a reply to this message

Bob Hughes wrote:
> Might be something to do with str() but I must leave that up to you to 
> figure out.

What you see is simple rounding differences.  You need to use two digits.

	Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message 
news:42e648ae$1@news.povray.org...
>
> What you see is simple rounding differences.  You need to use two digits.

Um, I don't think that explains it. I gave it a try just now and saw the 
clock (or specular value text) say 1.11 for the last frame when 
Cyclic_Animation=off. And it also still jumps directly from 0.00 to 0.22, 
skipping 0.11.

So it wouldn't just be rounding errors, right? Seems more like a problem 
with clock (and the animation calculation), not something to do with str() 
reading.

Post a reply to this message

Bob Hughes wrote:
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message 
> news:42e648ae$1@news.povray.org...
> 
>>What you see is simple rounding differences.  You need to use two digits.
> 
> 
> Um, I don't think that explains it. I gave it a try just now and saw the 
> clock (or specular value text) say 1.11 for the last frame when 
> Cyclic_Animation=off. And it also still jumps directly from 0.00 to 0.22, 
> skipping 0.11.
> 
> So it wouldn't just be rounding errors, right? Seems more like a problem 
> with clock (and the animation calculation), not something to do with str() 
> reading.

No, that would be a really strange error.  What is your SubsetStartFrame 
(spelling?) INI option set to?

	Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message 
news:42e6abdb@news.povray.org...
> Bob Hughes wrote:
>> Seems more like a problem with clock (and the animation calculation), not 
>> something to do with str() reading.
>
> No, that would be a really strange error.  What is your SubsetStartFrame 
> (spelling?) INI option set to?

Isn't used. The file speclr.ini (in scenes\animations\speclr-- I think I 
gave incorrect path to it before) contains only the following:

------------------------
Antialias=Off

Antialias_Threshold=0.2
Antialias_Depth=3
Test_Abort_Count=100
Input_File_Name=speclr.pov

Initial_Frame=1
Final_Frame=10
Initial_Clock=0
Final_Clock=1

Cyclic_Animation=on
Pause_when_Done=off
-------------------------

When Cyclic_Animation=off the str(S,1,1) in the rendering reads 
"specular=1.1" upon reaching the last frame. And #declare S=clock; is where 
it gets the value from.

Post a reply to this message

FYI, I think I have found and fixed the problem: The framenumber used to 
compute everything but the initial clock value (which does not need to be 
computed) was off by one.  Hence the second frame will appear to have been 
dropped and one at the end added.  I think you can work around this by 
specifying a substartframe number of 2and asubendframe number of 2 and 
render an animation in two parts for now. That should give you the one 
missing frame.  The image file numbering will be wrong though, I suspect.  I 
suggest renaming the initial frame to "0", backing up the original "2" 
frame, renaming the newly rendered frame "2" to "1" and the backup frame to 
"2" again.  Then delete the last frame and tellyour movie-creation 
application that the first frame has number "0".

	Thorsten

Post a reply to this message

Okay, thanks!

Using your suggestion it's interesting to see that adding:

Subset_Start_Frame=1
Subset_End_Frame=10

Can prevent the skipped value.

Having thought over this particular example scene file a while now I'm 
thinking it shouldn't use Cyclic_Animation=on anyhow. Reason being, if it 
should run the clock from 0 to 1 to show the specular change by that same 
amount cyclic=on would lose part of it. Only way to be sure such animations 
use a full clock value would be by using Cyclic_Animation=off.

As it currently is, the following INI setup allows the expected rendering of 
the example scene file:

Initial_Frame=1
Final_Frame=10
Initial_Clock=0
Final_Clock=1
Subset_Start_Frame=1
Subset_End_Frame=10

Cyclic_Animation=on

Problem is, doesn't seem correct to use cycling and still see the whole 
clock run from 0 to 1. Should be dropping part off.

I went back to POV 3.5 and it was the same behavior as in 3.6 using the 
above setup, they both run the clock from 0 to 0.9; but with cyclic off they 
both skip 0.5 (due to the rounding). However, version 3.7 beta 7 runs it 
from 0 to 1 (in tenths) okay when cycling, but continues to 1.1 when not 
cycling.

I just wanted to reiterate that point because I think such a scene file 
shouldn't use cycled animation.

Not only is that different, from the previous versions, I just now noticed 
the frame numbers shown in the status are going from 1 through 11 instead of 
1 through 10.

Good luck with any fixes you guys can do with the program, sounds like you 
already know what the problem is about. All the animation example scenes 
will need some checking but maybe that should be held off until the next 
beta...? Or does anyone think that this is a necessary thing (making 
possible changes to the examples)?

Bob Hughes

Post a reply to this message

Bob Hughes wrote:
> Okay, thanks!
> 
> Using your suggestion it's interesting to see that adding:
> 
> Subset_Start_Frame=1
> Subset_End_Frame=10
> 
> Can prevent the skipped value.

Yes, because then the initial clock value has to be computed while otherwise 
it is just set to zero.

	Thorsten

Post a reply to this message