QuickPass Rave
>>You've got a PAR that's capable of outputting roughly 360 frames per hour..
Yes, but that's when I run the PAR in slomo. <G>
The way I figure it is that the PAR requires an additional 2 seconds to dump
the rendered frame (752×480) to the par drive during the rendering process vs.
rendering to null device only.
When I tested the same rendered animation in AT Vista mode (756×486) and it
was saved to the Dos drive it saved at 2 seconds per frame so the difference in
going to the PAR was zero seconds of added rendering (processing) time. Once
the rendering time is done I just launch the Par.exe and the output is real
time or 1800 frames per minute (30 frames per second).
I actually ran the renderings both ways and took an average for the total time
to render AND save the frame, once to the dos drive and once to the PAR.
I don't own quick Pass so I have to rely on what people have told me they get
which has been 10 frames per pass. This is a speed up of 10 times what I used
to get with my DQ422 on the AG7750. or 16 seconds per frame using a 5 second
preroll. Dividing by 10 the recording should be done, I assume, in 1.6 seconds
per frame with QP. A minute of animation (1800 frames would take 2880 seconds
or 48 minutes to record to tape.
Since my experiment showed no difference in recording the frame to the PAR vs.
recording the frame to the dos drive we can figure that the recording process
is a relation of par recording to tape vs. quickpass recording to tape or 1 min
for PAR vs. 48 minutes for QP.
In reviewing several of your arguements of last winter on the subject you were
making a comparison using IMO two invalid parameters. First, you compared the
PAR speed using a rendering resolution of 752×480 vs. a quick pass or FxF
rendering of 512×486. You used the rendering speed difference as part of the
equation. In several tests here I found all the people asked could pick out
the PAR resolution quality as superior in sharpness and video noise to the
targa+ output. It is assumed that an AT Vista or Ill Pro would be more
comparable to the quality of the PAR as opposed to the targa+. Maybe JKJ could
offer some input to this question. On this assumption I use the resolution
slow down issue as.. not valid and make my speed tests at the same resolution.
Second, You used a figure of 4-5 seconds per frame of additional processing
time ( a figure Greg P. volunteered) to convert the rendered TGA's to the PAR
using PAR's import feature. While this is an additional step in the process
and these numbers are similar to what I confirm here it is not the most
expedient way to get rendered frames to the PAR although it can be a much
safer, conservative, use of ones time assuming DOS space is available. In
actual work here I choose both ways depending on the circumstances. I realize
that the configuration you use in your network obviates the direct saving of
these frames to the PAR. This is one reason I chose not to mimick the
dedicated server approach you chose. Possibly NDUMP.exe could salvage this PAR
speed loss in your setup.
Bottom line is that QP is a much improved way of recording over FxF but still
is a far cry to the output speed of real time recording. The only way to
improve recording real time with the PAR is to go with lesser and lesser
compression or no compression such as the Abekas/Accom system network fed.
Ref. Paul Lind's setup.
Now I have to get to work.