#PAR on network?
Don,
After a long week I got a chance to re-read your message on the subject and
realised what you were talking about.
>> My recollection was that his server PAR was not the best way to run the PAR.
<<
Well technically you're right though it served its purpose. Here's the thing.
DPS determined that the most stable way to run the PAR is on a 3DS Server as a
single source unit. For Network rendering, to use a program like NDUMP or the
new version; PAROUT, to collect frames for the 3DS Server from a variety of
networked Slaves. As far as the PAR is concerned it sees these frames as
coming from a single source via the 3DS Server.
The way I had it set up was to be able to render frames from a variety of
machines to a "dumb server" with the PAR on it. This had advantages for me, but
because of the networking arrangement that is required ie a link from each
machine to the PAR direct, its not an advisable scenario.
PAROUT and NDUMP are designed to be used in accordance with what DPS suggests,
ie the PAR on the 3DS Server collecting frames from the slaves. From what I've
gathered and from some comments I noted from Gus, the new PAROUT solves most if
not all of the previous problems with NDUMP with some clever programming. It
seems like it wouldn't have been that complicated except that the Server had to
have forknowledge of Slaves activity, like when they were going to finish
rendering, which was a problem if the Server finished first as it would close
out the sequence, and the remaining frames wouldn't have NDUMP to guide them to
were they needed to go. The solution of course was to render extra frames so
that the Server stayed in control.
But as I said, I believe this has been resolved, so if you've been holding out,
PAROUT and the other two programs that come with it are the answer.
As I need to hold onto my frames, there's really no advantage for me as I
render directly to an external SCSI. Again I'm PARless (no jokes please), don't
ask why. <g>
John