I added some BorderChars to my animation, between the 40-55 second marks.
http://www.buckosoft.com/tteoac/

tl;dr
---------------------------------------------------------------------
I wanted to add some BorderChars to the credits of my animation.
This was a good excercise to actually use povclipse2.  I am pleased with 
that; editing in povclipse2 is superior to pvengine.  Pvengine still has 
a huge leg up on in-program integration with the render engine.
But it is so nice to say "show me a clickable list of all occurrences of 
'StuGuitarExplodeStart' in all files".  My goal is to get back to my 
mushroom-cloud-in-the-kitchen explosion. Anyway...

So I upgraded my farm's povray and then whined that my i7 is slower than 
my i5s.  I went back to 3.7.1-alpha.8353331, which ran 100K frames for 
me in the past, and still my i7 is slower.  Perhaps M$ is punishing me 
for failing to free upgrade from Win8.1 to Win10. [1] ;)

I was annoyed when 8353331.exe crashed. twice. Of course, Windows 
doesn't just terminate the program. No, it puts up a "checking for a 
solution" dialog and then sits there.  So there is a 10 hour frame 
(instead of 45 minutes) that will forever skew my stats.  I am now 
running 3.7.1-alpha.8451792.  I will update to beta.3 when that is released.

I realized that once upon a time I said, "I can't wait to see a 1080p 
version of my animation!",  but I was so happy with the 720p-30fps 
version that I never did that.  So I started that 1080p job up. I'm 
irked because my farm was idle for a year and could have been doing that 
job.  I estimate 5-6 months to render it.

Immediately, I notice that my i7 is running twice as fast as my i5 on 
the old, non BorderChars work.

So huh, it is BorderChars that is slow on my i7. I never could have 
guessed something scene-specific could do that.

I got my first test results from 1080p-30fps.  I tried 60fps and 40fps 
but the x.264 encoder laughed at me.  Hmm, there is very very slight 
video tearing at the motion borders. This is especially noticeable 
during slow movement.  Err, I wonder if I should kill it and start again 
at 23.976fps.  That's the bluray standard, anyway.

Bleh, yes. I will kill it and start over. It's only a week's worth of 
renders.  I will take this time to upgrade the farm's povray again.

I visualized povray's git history and chose origin/master (SHA 
71c1415e). This is the best tag that has the utf8 fix, and I believe it 
makes more sense for me to run this version over a year old version. I 
know it's not a proper tag...  Internally, I called this beta.2a .

So the farm is updated, the frames are deleted, I am cranking through 
the credits at 3358 frames per hour. (Once I open that door, it will 
slow down to 30-60 minutes a frame @ 1920x1080)

-- 
dik

[1] At the time, OpenVPN didn't run on win10 and that is a critical 
program for me.

Post a reply to this message

Am 12.02.2017 um 08:44 schrieb dick balaska:

> Bleh, yes. I will kill it and start over. It's only a week's worth of
> renders.  I will take this time to upgrade the farm's povray again.
> 
> I visualized povray's git history and chose origin/master (SHA
> 71c1415e). This is the best tag that has the utf8 fix, and I believe it
> makes more sense for me to run this version over a year old version. I
> know it's not a proper tag...  Internally, I called this beta.2a .

Prepare to want to upgrade your farm /again/ in about a week or so ;)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:
> So huh, it is BorderChars that is slow on my i7. I never could have
> guessed something scene-specific could do that.

Hi there, I'm not sure exactly what you're describing but if you identify a
problem with BorderChars I'll be interested to know about it in case it's
something that can be fixed.

I did notice you're using FontVariationNumber 28 with the sample interior
object. (It looks great in your animation!) The wavy interior object renders
extremely slowly due to the use of so many sphere_sweeps. You can speed it up a
little by changing the setting of "#local DeltaTheta = 30;" to 45. This will be
perfectly acceptable for your scene.

Regards,
Dave Blandston

Post a reply to this message

Am 2017-02-15 12:20, also sprach Dave Blandston:
> dick balaska <dic### [at] buckosoftcom> wrote:
>> So huh, it is BorderChars that is slow on my i7. I never could have
>> guessed something scene-specific could do that.
>
> Hi there, I'm not sure exactly what you're describing

i5 = 3.2Ghz, 4 cores
i7 = 3.4Ghz, 4 cores, 8 threads.

So the i7 is a wee bit faster.  Also, 4 cores means the chip can do 4 
things at once.  The i7 has 2 threads per core; it can sort-of do 8 
things at once, but 2 threads share each FPU, I expect waiting for the 
FPU to be involved.

In practice, I see the i7 average running about 80% faster than the i5.
(Looking at the Christmas tree, 26 minutes for i7 vs. 43 minutes for i5.)

But those scenes with BorderChars, the i7 is actually *slower* than the 
i5.  I would think even if a thread is always waiting on the FPU, it 
should still be minimally 6% (34/32) faster than the i5.

but if you identify a
> problem with BorderChars I'll be interested to know about it in case it's
> something that can be fixed.

I can't imagine anything you could do different. It's just SDL.  The 
issue has to be deep in the optimization code of the M$ compiler.
Or ... I blame clipka.

>
> I did notice you're using FontVariationNumber 28 with the sample interior
> object. (It looks great in your animation!)

Thanks!  My problem now is, I did those 3 shots with BorderChars and 
then it goes back to regular boring white characters and my brain says 
"wtf, fix it, dude".


>
> Regards,
> Dave Blandston
>
>


-- 
dik

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:
> I can't imagine anything you could do different. It's just SDL.  The
> issue has to be deep in the optimization code of the M$ compiler.
> Or ... I blame clipka.

OK I understand now. I thought maybe you had found a bug that I missed. Thank
goodness you didn't!

Regards,
Dave Blandston

Post a reply to this message

Am 16.02.2017 um 03:21 schrieb dick balaska:

> So the i7 is a wee bit faster.  Also, 4 cores means the chip can do 4
> things at once.  The i7 has 2 threads per core; it can sort-of do 8
> things at once, but 2 threads share each FPU, I expect waiting for the
> FPU to be involved.

I think it is realistic to expect hyperthreading to give about 15% more
pixels per unit of time.


> But those scenes with BorderChars, the i7 is actually *slower* than the
> i5.  I would think even if a thread is always waiting on the FPU, it
> should still be minimally 6% (34/32) faster than the i5.
...
> I can't imagine anything you could do different. It's just SDL.  The
> issue has to be deep in the optimization code of the M$ compiler.
> Or ... I blame clipka.

:)

I tend to blame it on different cache sizes. Or different number of CPU
clock ticks required to execute particular instructions. Or differences
in the CPU clock. Or in the branch prediction. Or in the instruction
pipeline depth. Or... well, I guess you get the picture: CPU performance
is an utterly complicated topic.

Post a reply to this message

Am 2017-02-12 02:44, also sprach dick balaska:

> I realized that once upon a time I said, "I can't wait to see a 1080p
> version of my animation!",
>
> Err, I wonder if I should kill it and start again
> at 23.976fps.  That's the bluray standard, anyway.
>
> Bleh, yes. I will kill it and start over. It's only a week's worth of
> renders.  I will take this time to upgrade the farm's povray again.
>

I now have 3.5 minutes of 1080p video (175MB).  I'm not loving the 
motion. When paused, it looks gorgeous on my 24" 1920x1200 screen, but 
movement is jerky. I notice it especially doesn't like when a line of 
solid color moves against another solid color (you know, typical 
computer animation stuff). My 720p version in full screen VLC stands up 
pretty well to it.  The stills aren't as crisp, but the motion is 
superior. *sigh*

-- 
dik

Post a reply to this message