 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Last year I had some fun with POV-Ray animation. The main aim was to find some
(any?) way to utilise my mini-farm of PCs.
The main result of that time can be seen at: https://vimeo.com/242598466
The subject was chosen to fit a piece of music by a Heavy Metal band (they're a
lot heavier than this piece). The Chess is NOT the greatest of contests but it
fits. (No Chess experts please!)
Python 3 was used to generate the POV-Ray pov/ini files, with most of the
parameters (timing, start/end distances) pre-generated in a spreadsheet. Some 50
pov/ini scenes were then farmed out in separate frames. The total number of
frames is ~1700 for ~1:50 secs of animation, including fillers and titles. The
final render session took ~25 hours, and the frames and soundtrack were finally
sewn together with ffmgeg at 25fps.
The render farm is a mix of i7/i5 PCs (and recently a couple of Ryzens). At
full tilt, that's pumping out over a kilowatt and perfect for a cool winter's
day. The master (Gru) is Win10 while the clients run Linux Mint (the
"Mintions"). The home-brew render job management is a bit of Python using
UDP(!!) over the gigabit LAN.
tery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/14/2018 12:16 PM, greytery wrote:
> Last year I had some fun with POV-Ray animation. The main aim was to find some
> (any?) way to utilise my mini-farm of PCs.
> The main result of that time can be seen at: https://vimeo.com/242598466
Very nice!
I love the sparkle effect where the king is first captured. Very liquid-y.
I like the shape of the mass of pieces when first laying out the board.
I would have started them in the center back and expand left/right
instead of in the corner.
>
> The subject was chosen to fit a piece of music by a Heavy Metal band (they're a
> lot heavier than this piece). The Chess is NOT the greatest of contests but it
> fits. (No Chess experts please!)
Well, you did need a match that fits in 1:50. Someone has to make a dumb
move. ;)
>
> The render farm is a mix of i7/i5 PCs (and recently a couple of Ryzens). At
> full tilt, that's pumping out over a kilowatt and perfect for a cool winter's
> day. The master (Gru) is Win10 while the clients run Linux Mint (the
> "Mintions").
Heh. Nice node names. How many boxes are in the farm?
The home-brew render job management is a bit of Python using
> UDP(!!) over the gigabit LAN.
UDP huh? That's an interesting choice.
>
> tery
--
dik
Rendered 920576 of 921600 pixels (99%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dick balaska <dic### [at] buckosoft com> wrote:
> On 02/14/2018 12:16 PM, greytery wrote:
> > Last year I had some fun with POV-Ray animation. The main aim was to find some
> > (any?) way to utilise my mini-farm of PCs.
> > The main result of that time can be seen at: https://vimeo.com/242598466
>
> Very nice!
Hey thanks. I was just checking out YOUR 'Child'. Spooky or what!
> I love the sparkle effect where the king is first captured. Very liquid-y.
> I like the shape of the mass of pieces when first laying out the board.
> I would have started them in the center back and expand left/right
> instead of in the corner.
>
Corners chosen because I wanted a longer spread, but I take your point.
> >
> > The subject was chosen to fit a piece of music by a Heavy Metal band (they're a
> > lot heavier than this piece). The Chess is NOT the greatest of contests but it
> > fits. (No Chess experts please!)
>
> Well, you did need a match that fits in 1:50. Someone has to make a dumb
> move. ;)
>
Hey - I said No Chess exp ..
> >
> > The render farm is a mix of i7/i5 PCs (and recently a couple of Ryzens). At
> > full tilt, that's pumping out over a kilowatt and perfect for a cool winter's
> > day. The master (Gru) is Win10 while the clients run Linux Mint (the
> > "Mintions").
>
> Heh. Nice node names. How many boxes are in the farm?
10 (3 i7, 5 i5, 2 Ryzen 1700 - all SSD and 8-16GB RAM).
>
> The home-brew render job management is a bit of Python using
> > UDP(!!) over the gigabit LAN.
>
> UDP huh? That's an interesting choice.
>
Been writing comms code off & on since 1973. Back then it was teletypes,
dial-up. Went through the early internet thing, and was involved in maybe 7
TCP/IP subsystems. Our designs then used to fake the wiring between Host and
User by drawing a {{cloud}}. Have bought and sold international - and even
orbital - networking solutions as a consultant .... so when I retired and sat
down at home and checked out the best solution for a bunch of PCs connected to
the same gigabit switch - who needs a cloud? UDP is reliable enough.
> >
> > tery
>
>
> --
> dik
> Rendered 920576 of 921600 pixels (99%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/14/2018 01:33 PM, greytery wrote:
> dick balaska <dic### [at] buckosoftcom> wrote:
>> On 02/14/2018 12:16 PM, greytery wrote:
>>
> Corners chosen because I wanted a longer spread, but I take your point.
That makes sense.
>>
>> Heh. Nice node names. How many boxes are in the farm?
> 10 (3 i7, 5 i5, 2 Ryzen 1700 - all SSD and 8-16GB RAM).
Well I'm jealous of *that*. I have (1) i7 and (3) i5.
(Recently swapped an i5 and a Celeron for a new i5. More throughput,
less node count). My max node count was 8, but the family now all uses
iPads and slow laptops that hibernate when you close the lid.
>>
>> The home-brew render job management is a bit of Python using
>>> UDP(!!) over the gigabit LAN.
>>
>> UDP huh? That's an interesting choice.
>>
> Been writing comms code off & on since 1973. Back then it was teletypes,
> dial-up. Went through the early internet thing, and was involved in maybe 7
> TCP/IP subsystems. Our designs then used to fake the wiring between Host and
> User by drawing a {{cloud}}. Have bought and sold international - and even
> orbital - networking solutions as a consultant .... so when I retired and sat
> down at home and checked out the best solution for a bunch of PCs connected to
> the same gigabit switch - who needs a cloud? UDP is reliable enough.
Yeah, it's reliable enough but ... I guess you're using some python
library to assemble the small packets into a big message (like the
returned image).
I did an early innernet video game. UDP is great until it breaks. Error
tracing is difficult. (I always thought it was me until my TiVo also
gave me the same useless "No route to host" message. It's the same lan,
you stupid box.)
--
dik
Rendered 920576 of 921600 pixels (99%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dick balaska <dic### [at] buckosoftcom> wrote:
> >> Heh. Nice node names. How many boxes are in the farm?
> > 10 (3 i7, 5 i5, 2 Ryzen 1700 - all SSD and 8-16GB RAM).
>
> Well I'm jealous of *that*. I have (1) i7 and (3) i5.
So. That's a farm!!
Did I mention I was a 'consultant' before retiring? == adequate pension + loads
of time.
> >>
> >> UDP huh? That's an interesting choice.
> >>
> > UDP is reliable enough.
>
> Yeah, it's reliable enough but ... I guess you're using some python
> library to assemble the small packets into a big message (like the
> returned image).
Nope. It's pretty simple Python - no classes or Obscure Obfuscation. All done at
the POV frame level with a shared (SMB) folder. I call it
UDPov. UDPov Job manager sends text message to client(s) to render a batch(1) of
frames. UDPov client calls POVRay command line with .ini file name and
start/end frame number(s). Client then writes whole image back into shared
folder and polls for next. Folder fills up with the frames and eventually they
can be combined (ffmpeg).
Development seems to be changing the structure of POVRay so that maybe we can
distribute work at the tile level but that's not here yet. Currently frame level
works for me. And anyway it's not always clear whether work is more efficiently
done at either the frame or at the tile level, especially for longer runs of
frames.
> I did an early innernet video game. UDP is great until it breaks. Error
> tracing is difficult. (I always thought it was me until my TiVo also
> gave me the same useless "No route to host" message. It's the same lan,
> you stupid box.)
I'm really talking 1970's here :-) Back then you built in recovery at the
application level as well as at the network level. Stupid application IMHO.
(but yeah. UDP is 'fire & forget' so you need to remember and retry. Er, did I
mention the 70's?)
>
> --
> dik
> Rendered 920576 of 921600 pixels (99%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2018 um 23:28 schrieb greytery:
> Development seems to be changing the structure of POVRay so that maybe we can
> distribute work at the tile level but that's not here yet. Currently frame level
> works for me. And anyway it's not always clear whether work is more efficiently
> done at either the frame or at the tile level, especially for longer runs of
> frames.
For animations, frame-level job distribution will most certainly remain
the most efficient solution, even once tile-level job distribution is
enabled.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 14.02.2018 um 23:28 schrieb greytery:
> For animations, frame-level job distribution will most certainly remain
> the most efficient solution, even once tile-level job distribution is
> enabled.
It's also easier to manage from a recovery POV. (No apology - pun intended!)
Easier to recover a missing frame - but a missing tile would ruin several
clients work.
I've only been using a private, local farm with home-brew UDP plumbing - but
never hit a recovery problem.
If "we" were to distibute animations across the web, say, then tile-level
message passing overheads would be horrendous. There will always be an overhead
in distributing the jobs, mainly because there doesn't appear to be any way of
cacheing/sharing the parsing results ( am I wrong?).
In this example, the individual moves were ~1-4 second scenes, each job split
into 30-100 frames. So there is an even higher level of job management - and job
recovery. Frames is good!
I understand that the render engine efficiency has been improved in > 3.7 and I
look forwards to feeling the difference.
tery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
