PAR CARD and .ifl's
11 messages in this thread
I have the par card with the tbc IV so I can grab real-time to.
They both work great! but the problem I am having is that I want to bring in
as an animated texture map some of the video I grabbed.
The people at Pyros Partnership told me the way they do it was to
create an .ifl text file that states ex: pic0001.tga pic0002.tga and
so on…and it (par) would do the rest.
we set it all up and got it to see the actual first tga of the .ani on
the par, and he said that now when I did a keyframer animation that
it would go to the next tga as the 3dstudio animation did.
So I tried it today…saturday…..and you guessed it, it didnt. So
for all you POWER PAR users out there could you tell me how to
achieve this.
All I am getting it the same tga over and over on my object. Any
Help would be great thanks!
Tony:
>> PAR rotoscoping
Sounds like you are close! In the PAR PXP, do you have your settings
as described on pages 83-84 of the manual?
Specifically, as per paragraph 4 on page 84, did you make sure the PAR
is set to "Filename" when using an IFL? That sounds like the
solution to the problem you described. If you have already done
this, and it still doesn't work, please e-mail me the way you have
set all the buttons in your PXP.
Also, just to be sure, you have included the PAR drive and directory
in the MAP paths of 3DS, and have no files with the same four-letter
prefix on your hard disk? Just move the PAR to the top of your
map-paths list.
Ola Greg,
What is supposed to be on Pg 83-84 of the manual? Mine has Appendix B.
PAR PXP = DPSPAR_I.PXP? Must be something different.
They must have made some major revisions in the manuals – my Appendix
B starts on page 89! 83 is "Exporting Targa Frames Directly to 3D
Studio". The manual I have is Release Version 1.2
You need to tell the PAR to do that. If you don't, you will always get
just the first frame. There are three ways to output frames from a
PAR animation. "Fixed" (the default) doesn't change the frame
number. You always get the first frame. "Increment" increments the
frame number each time you read from the PAR. You can also set which
frame will be the next frame to come out (and it will automatically
increment thereafter). And lastly, "Filename". That's what you want.
In this mode, the driver will extract the frame number information
from the filename you give to it. From within 3D Studio, just load
the DPSPAR.PXP and set "Output Mode" to "File". From the DOS prompt,
just type "PARDRV /I:FILE".
All this should be in the docs (I'm just guessing because I haven't
read it myself <g>).
I have the PAR on a non rendering file server. This is because my
other three machines are full. DPSPAR_I.PXP won't recognise the PAR
as its not local. How can I use an .ANI file for rotoscoping when I
can't access the PAR directly over a network? It would really be
useful to be able to access the PAR directly, as well as share .ANI
files, especially as most people have multiple machines for
rendering. Any suggestions?
PARDRV converts a non dos file system into something dos can read.
The process of doing that is through a network redirector interface.
It's a sort of "installable file system" in a dos that doesn't really
allow IFS's. The draw back is that a redirector cannot be
"redirected" again. In order to do that, special drivers would have
to be written for each type of network. Note that even though MSCDEX
gives the same type of functionality, the level of access is very
different from that of the PAR. Can be done? Well, anything can be
done in software given the time and money!
>> The drawback is that a redirector cannot be "redirected" again. <<
Right, so what can be done to make this thing work? How about this?
The renderer's feed the file server, which has a local hard drive
with C:\IMAGES and C:\DPS_PAR directories, and the PAR with its
native HD on a drive D:\. A DOS program is initiated on C:\ of the
file server which checks the images in C:\IMAGE while the networked
renders feed that directory.
The DOS programs function is to continually looks for the next
sequential file in the image directory, and when it finds it, send it
to the PAR.
What kinds of problems do you forsee in this approach? Would this
constant checking interfere with the networks ability to pass the
rendered images to the C:\IMAGES directory? Is there a way to specify
a time out to release control of the program so that rendered images
could be transferred from the network to the directory? Would this be
necessary?
It would be nice to keep the PAR busy while the network is rendering,
and I get the impression that if 3DS is not installed on the file
server, N_DUMP won't work for me.
I hope I'm not speaking out of turn here, but that is EXACTLY what the
net at Pyros does. There is a little program that looks for finished
frames on the net and then copies them to the PAR as they are
completed.
I think N_DUMP would have to be local (ie: on the same system as the
PAR) to work, and as I mentioned, I don't have 3DS loaded on my
"non-rendering" file server. So we shall see…
Correct, even though we have a dedicated UNIX server, but our PAR is
on a node, which makes the process easy. JohnE wants to run the PAR
on a dedicated DOS server without 3DS running on it.