#Rotoscoping with the PAR
7 messages in this thread
> RE: Reversed animated mats
>
> Check the frames by hand.. Can you play the frames normally? I can't
> think of anything
> off hand that would cause the PAR to reverse the frames.
Here is a overview of my situation: [1. -The scene is composed of a
background and two meshes with animated maps, ( right.ifl on the right mesh &
left.ifl on the left mesh). [2.- The maps (.ANI files are 1000 frames ea.)
are rendered to frames from 3DS3. [3. -The scene is rendered to fields and
the rendering time is approx. 2 min per frame (1000 frames total). [4. – The
.ANI files are being accessed twice (once for each field) which equals four
times per frame (once every 30 seconds).
The Network: [1. -Lantastic 5.0 w/NR2000C net cards [2. -Loading Share (I
thought this was the problem at first) [3. -The PAR is on a 486-66 4. The
rendering machines are two P5 90's.
WHAT WORKS [1. -One machine rendering and accessing the PAR accross the NET.
WHAT DOES NOT WORK [1. -Two or more machines rendering across the NET.
THE PROBLEM!!! [1. -The second machine going into Slave Mode gets confused
information from the PAR.
[A. -The right map is on the left side and the left map is on the right
side or
[B. -The right map gets the left field #0 and the right field #1 (composit
of right & left map) [2.- If I try to sinc the two machines so they are
reading the materials at differnent times this seems to help for 100 frames or
so.
Brick I hope this helps you understand this problem. Also I had a problem
joining two animations together, the join box did not allow me to select a
second file on the first try, it was ok the second try.
Thanks Mike Morgan-Cad Forms Inc. San Diego, CA
The PAR driver is not a network driver. That means only one process at a time
can read or write frames from/to it. You cannot have two (or more) machines
asking it for different frames at the same time. When a frame is requested from
the PAR, it is converted to Targa first and then sent to the calling
application at the application's own pace. If a second process comes along and
requests a new frame, the driver doesn't know what to do with it as it only has
one buffer to read Targa frames (this buffer is 1080 kbytes long).
So the timing idea will work as long as there is enough time between reads to
give the par time to reset itself, or in other word I guess i have been lucky
when it woks across the NET with my timeing idea. Out of the 1000 frames I did
not loose any of them while rendering from a single machine across the NET. I
hope in the future there will be some work done on the software to be able to
NET render using this feature.
Thanks for the info Gus. Mike Morgan-CAD forms Inc. San Diego, CA
I think you answered my question, Gus. I just landed several rotoscoping jobs
and discovered I must render to the PAR drive and receive roto video files via
the IFL and PAR drive due to hard disk limitations. I suddenly realized that
this rendering process "obsoletes" my network rendering setup. I thought NDUMP
might help but most likely not for bringing in the roto files across the
network to each calling machine. While NDUMP will enable my PAR for the
network to receive the rendered animation I will have to put the roto files
onto my DOS drive. Right? I guess I'd better start considering a 2-3 G drive
just for all those roto files. :-<
With some programming all can be done. You could run a process that copies a
bunch of images from the PAR to a local disk. A line in your VP queue would
read in the rotoscoped image. If it cannot find it, it would fire off the batch
reader. The batch reader could get rid of the old files and read another batch.
Sounds good, is this the making of the "pro" version of NDUMP? The version
that supports rotoscoping across the network?
Actually what I had in mind was just a couple of sophisticated batch files. DOS
alone couldn't do it but if you run 4DOS, you can construct for…next loops
and conditional branching which would allow that sort of things. That's one of
the big differences between dos and unix. The ability to solve simple problems
with simple (and not so simple) shell scripts. Now that dos is leaving and
Windows4 is coming in to play, this is probably going to be gone for ever. The
draw back of making computers totally idiot proof is that you loose the
computer's greatest ability -> to compute! They are turning computers into
specialized typewriters as the great majority of people use computers to do
nothing else other than that. The draw back is that if you need anything that
isn't readily available from commercial software (the majority of these day to
day stuff) you're out of luck.
Oh well, I bet the last thing you're asking for was this grumpy mambo jumbo.
<g>
Let me think about this. I haven't had much free time lately (sleeping 4 hours
a night seven days a week for 3 months) and I'm ready to start drilling holes
in people's teeth using my Makita. The advantage of batch files is that you can
tweak them as much as you want. To write a full blown application a lot of
thought has to go before actually implementing it.