#new PAR.EXE
8 messages in this thread
Brick –
To pick up on something Don L. mentioned. . .
>>a speedy way to resolve the dilema of multi channel rotoscope files<<
Any chance that the DPSPAR.pxp will be rewritten to allow mulitple animations
to be rotoscoped simultaneously from the PAR drive? This would mitigate any
need to "JPEG" out any files to a hard disk (something I'm doing while I
write).
While everyone's on the subject of wishlist items, thought I'd throw mine in .
. . 🙂
bob
Bob: You can do this already using the IFL and specifying file in the PXP.
The problem that I ran into was you need to port the roto files to your HD for
network slave access. If using only one machine, the PAR machine for
rendering, you don't need to export the roto files.
Thanks for the input . . .
>>You can do this already using the IFL and specifying file in the PXP<<
I've found that the PXP doesn't support multiple simultaneous file
accesses to the PAR, for several different rotoscoped animations, to
two different locations in the same file that is being rendered
(e.g., a background and a TV screen). Several other PAR users have
acknowledged that this is a shortfall in the software as it exists
today. I guess we can only hope that Gus will one day modify the PXP
(are you out there, Gus?) :-).
The PXP is just a control panel to access the different settings in
the driver down below. The limitation is of PARDRV, not the PXP. The
problem of supporting multiple (simultaneous) reads and writes is
that the file must be converted in its entirety before sending either
way. In other words, when you copy a Targa file over to the PAR, the
driver will read the entire file in its buffer. When the copying is
done, it will convert to YUV and then send it over to the PAR. If a
second read or write request arrives while one is being processed,
there is no "second" buffer to load and convert this image. DOS isn't
multitasking. If it were, all I had to do was to wait for the first
request to finish. Having several buffers is a little impractical as
each buffer is at least 1.1 Meg. The only simple solution (simple
when compared to almost impossible) is to handle YUV files directly.
For that a new driver would have to be written. This driver would
know nothing about Targas. Just raw YUV files. That way, no buffers
would be needed. The driver would also be much smaller. The draw back
is that no software out there knows about YUV files. It would be
simple to handle 3D Studio (through a BXP) but that's about it.
By the way, this is all up to DPS, not me. I will do whatever they ask
me to do (well, almost) but it is very unlikely I will write
something of this magnitude "just for fun". So, when you say "I can
only hope that Gus will one day modify the PXP…", I can't do
anything about it.
Gus, I don't know why Robert can't do this because I've been doing
multiple ani file accesses from the PAR drive for the past 3 weeks
now. As I write this I'm pulling 14 ani files of 600 frames each for
a rotoscoped composite of cubes. Each also has a feathered windowed
opacity map so the roto files blend without hard rectangle edges.
After all is rendered it is dumped back to the PAR using the same
PXP. I have a monitor on the PAR output and can monitor each frame
of each ani file as it is accessed by 3DS when the render screen
says: "processing maps". It takes about 20 seconds to process all 14.
They go in order. The last roto file stays on the screen for the
duration of the rendering and then I see the composite as it writes
to the PAR. The only drawback is this won't render on my network.
But, we've beat that issue to death with Greg already. The secret to
doing this is proper use of the IFL procedure. During a previous
test I had different lengths of ani files. I was able to allow these
IFL's to cycle during a much longer animation. The roto files just
repeat themselves when they get to the end of the list..
PS: I just made arrangements to exchange my VM for the fourth time.
Apparently the SC box rev. is not compatible with my board and
therefore has problems communicating the LTC codes.
If only a single machine is involved in the process you should not
have any problems. The problem shows up when the PAR is a "shared"
resource on the network and two or more computers request access at
the same time. In other words, it will handle synchronous access just
fine. It will choke on asynchronous access.
FAST!? Grrrrr! I haven't touched that thing in months. It's not good
for my blood pressure. <g>
Gus –
Thanks for the thorough update. I didn't realize that it's not simply a feature
that can be added to the ipas. 🙂 Would be nice to have, whoever would need to
do it, however. Is anyone from DPS listening?
bob
>>I've found that the PXP doesn't support multiple simultaneous file
accesses to the PAR, for several different rotoscoped animations, to
two different locations in the same file that is being rendered …
Well it's obvious your doing something very wrong or God is on my side
working miracles. <G>
I just did a 7 channel rotoscoped sampling for a client last week to
demonstrate to his investors the opening to a new video. The object
was a simple cube with all 6 sides detached to individual objects. I
recorded six 2 second scenes form the camera video stock for the
picture. each of these 60 frame ani files was named aaaa0000.ani,
bbbb0000.ani….ffff0000.ani. Then a background was recorded and
named bakg0000.ani. IFL's were created for each on the ani files and
a special materials library was created for each of the 6 files. The
6 materials were mapped in the normal fashion to the cube and the
background was also selected using the IFL file. The paths pointed to
the IFL directory and to the PAR project directories where these 7
files were located. The PXP was set up for targa and file field 1. I
rendered the thing back out to the par as roto####.ani and the whole
thing completed from beginning to end including recording to VHS
video tape in 50 minutes. FYI each frame rendering time was 18
seconds. But then I only have a DX2-66. Better get religion,
Robert. <BG>