#Parout
5 messages in this thread
For the last 3 days I have been rendering a rather large animation that would
not normally fit on my hard drive. I decided to use Parout. This is the first
time I ever used it other than a simple test where it appeared to work fine
with two machines rendering a simple 20 frame animation. I assumed it was
working.
This large animation is 1200 frames long and I had three machines rendering
full time and a fourth part time at night. Everything seemed to be working
smoothly with each frame flashing up on the monitor as they were coming into
the server for parout to do its thing. In the end, the first surprise was when
I examined the dos directory and discovered 346 TGA files still there. Why
were't these deleted? The ones left had been rendered by all machines at
random. There was no pattern to the files remaining that were not deleted by
parout. I booted up par.exe and discovered that the only reference to my
animation was a STL file ABCD0000.stl and it was of the last frame of the
animation. The rest of the 3 days work is gone! I am starting over by
splitting the job into two rendering sessions where I will join them together
in the PAR in the end without Parout. I'm sure I must have done something
wrong, but what? There are only two things to do in Parout. There was no
Parout log file to examine and indicators during the run were that everything
was proceeding normally. There should be some sort of warning when something
is going wrong. After all, the time one uses this tool is when the jobs are
large enough to require a network and it must be pushed to the PAR immediately.
Any ideas?
I will not be using Parout until I have a thorough understanding of what
happened here and can trust it to do it's job in the crises of a deadline job.
You must be using the first version of ParOut (1.0) where the "orphan" frames
were deleted only at the end of the project. These orphan frames used to dangle
around as they were written by 3D Studio only _after_ ParOut had processed
them. The new version will keep an internal list of processed frames and delete
those "orphans" accordingly.
The fact you had a ".STL" file at the end had to do with the fact you didn't
change the driver from Stills to Animation. ParOut, as of today, does not alter
any setting in the driver (PARDRV). Those are expected to be set by the user as
they would normally be under any other circumstance. If you have the driver set
to create still, that's what you end up with. ParOut's task is to ensure frames
are transferred in the right order over to the PAR disk. I did not include any
driver (PARDRV) setting as these are handle by the user in too many different
ways to keep track off.
And, yes. You did not have any error message in the log file as, in ParOut's
point of view, there were no errors. It just did what it was told to do.
To avoid a 3 day surprise like this, you can stop the machine with the PAR and
check what you have gotten so far (using either the ParCtl or PAR.EXE). When
you go back to slave mode, just "Clean" the network queue and ParOut will pick
the work up where it left.
As far as upgrading your ParOut to handle those "orphan" files, you need to
contact Greg. If you have any other problem, please let me know.
Gus
Thanks, Gus for the explanation. When I launched Pardrv I did discover it was
in the stl mode. I overlooked this. I'll contact Greg on the upgrade next
week when I get back from an out of town video shoot.
Don:
Sorry you had that problem! Gus answered all your questions, and gave you a
way to test everything to see that all was set correctly.
Dumb computer! Did what you told it to, not what you wanted! Isn't there a
button for that, right next to the "any" key and above the "make art" one?
Greg Pyros
Yes, Thanks Greg.
We're parouting again, correctly this time but I do get those phantom files.
Gus says I need an update to the program to correct this.