#Amiga PAR and 3.1 Field
38 messages in this thread
Mike, I never heard from Gary at DPS so I called them today and spoke to
Scott. He said that they are not having a problem FIELD rendering with
Lightwave and other Amiga 3D rendering programs that support FIELD
rendering. He said that the trouble has to be with Imagine 3.1. He said
you may be sending the file on the Amiga version the same way as you do on
the IBM version and that won't work. He suggests you send him 3.1 so he
can check it. I am stuck in the middle. PLEASE HELP! I have been putting
off clients that need and demand the smoothness of FIELD rendering.
Thanks for your help,
Jim R. Ollick
Using AP from Bergenfield, NJ
Jim
Here is the problem, no matter what they tell you.
First, we make an iterim file, that is not ILBM or any other kind of
file that DPS can read, so they have a time out waiting for the file to be done
to thier specs,. we dont do it that way, never have and so its apparent after
you conversation that they could care less, they have all the LW users they
need.
I have talked with them, once they never called back, hell I have no
idea what to do now.
I have the same problem, I use the product they make and I just render
the images to a final format then copy them over, it works for me until the
really decide what they want to do, I would love to help more but I dont know
what else to do.
Mikes
PMFJI, but why can't you save your interim file to someplace like RAM: (or
a user specified TMP directory)?!? It seems like the PAR is choking
because you save it out with the final image name. Save the file out as
<SAVEDIR:>fubar.tmp. Do this for every frame, using the same tmp filename.
It might take a few seconds longer, but at least you can get the job done
simply.
I'm amazed that you're having so much trouble solving a problem that to me
seems trivial. Expecting DPS to tailor their software to the
idiosyncrasies of one lone package is not a realsitic solution.
(Now, let me adjust my blast shields – I think it's going to heat up here.
:^)
Keep On Toastin'
Erik Flom – ELF Works 3D Construction Co.
Thanks for your help. I don't want to have to switch to LW after making an
investment in time and money on Silver, Turbo Silver, and Imagine.
Jim R. Ollick
Using AP from Bergenfield, NJ
I wasn't trying to get anyone to change apps/platforms.
The point I'm trying to make is that the programming solution to this is
_TRIVIAL_, and I can't believe the amount of foot dragging I'm seeing on
the part of the developer. (To expect the PAR s/w to 'figure out' whether
you're using the file as a tmp file or the real thing is ludicrous. I'd
like to hear the reason that a tmp file couldn't be created, either in
program RAM, RAM:, or a user specified TMP directory?!?)
Good luck in your quest for field rendering….It's worth it!
Keep On Toastin'
Erik Flom – ELF Works 3D Construction Co.
I have found a way around the problem for the time being. As long as I
have enough hard drive space, I am saving the picture files to a directory
on my hard drive and when Imagine is finished, I import them using the PAR
software. I agree with you 110% and hope Impulse sees things our way to.
Jim R. Ollick
Using AP from Bergenfield, NJ
Good Luck! It's worth it. (I just finished a 300 frame shot panning across the
front of a movie theater, and it looks a thousand times better at 60fps!) Erik
Flom
Jim
What do you mean, see things your way, there is no your way there is
only the way that works, there are only a few users of the PAR card, and as
such we will stive to fix the problem that DPS is ignoring. Its also good to
see that you took my advice about the workaround, I am sure that we will have
the problem in had very soon and if you are part of the Constant Update you
will get it in the next release.
Mike
I am on the update program, how else could I have had 3.1? I am happy that
you will work it out in a future release, that is all I ask. I do not need
a non-liner system. All I do is the post work ie:creating logos and flying
them around, etc. Your product has been ideal for this especially since
you added the spline editor, postscript font support and field rendering.
Jim R. Ollick
Using AP from Bergenfield, NJ
Mike,
I have another thought, while we're talking about 3.X things.
One thing that's often done in high-end productions is the making of something
called a "matte reel." It's used particularly with complex 3D animations that
must be keyed over live video.
It works like this: you get the animation on two reels. The main reel contains
the 3D logo, or flying bird, or spaceship, or whatever. Parts of it may be
dark, and so wouldn't key very well if the keying was done as a luminance key
using the object itself. The second reel is the matte reel. It's a black
background with a white object the same shape as the 3D object on the main
reel. The thing is that it's not just black and white; there are some grey
pixels on curves and other areas that require antialiasing. Basically what I'm
describing is the output of an alpha channel, recorded on tape. During
editing, the matte reel is used to create the key signal and the main reel is
used to produce the "fill" video.
I'd love the ability to put both the "real" animation and a matte on the PAR
for output to tape. Can you see a way to do this in the future, based on where
you see Imagine 3.X going?
Pete
Pete,
I don't want to take Mike's place, but he did indicate that a future
version of Imagine would have alpha channel support, and knowing Impulse,
I'm quite confident that, perhaps a version or two later, we'll have a
renderer that outputs two streams of frames, each to its own directory:
rendered images and alpha-channel images.
In the meantime, you can roll your own alphas by creating a duplicate of
the .imp directory once your animation is "frozen"; changing all object
references in the Action editor to the new project directory's "objects"
sub-directory; editing the objects by removing all textures and brushes,
and making them matte black; and setting the Globals background to all
white on the +/-Zenith and Horizon fields. The result: a version of your
animation with featureless black objects on a white background.
Blaq!
Charles,
>> In the meantime, you can roll your own alphas…
I have done similar things in the past, but it's too time consuming. The
watchword of all this stuff is "speed."
Blaq!
Pete
Sure, we are doing that now, funny you should want that. I must also
admit that it will be much easier than done with film, I know I have worked on
several movies where the process of cutting mattes was very time consuming and
lead to major delays as well as many late night screaming sessions.
Mike
Mike,
>> we are doing that [matte output] now, funny you should want that.
That's great news. It keeps getting better and better…
Pete
Erik
Thanks for your comments, as always its like eating a sweet tart with
glass on it, the insides are most likely worth the effort. You idea is
interesting, I wished it had worked.
DPS has had Imagine for two years, they have know of this problem form
the start, it is much easier for them to check for a valid format, than for us
to re-write the way the render does what it does.
We are however looking into it and may have a solution very soon, this
ought to make you toaster guys real happy.
Mike
Thanks for your response. I know I'm a pain, but I mean well. :^) You say you
'wished it (my idea) had worked'? Is their some reason you can't create a temp
file either on a local dir, or in RAM? It seems like the best solution. As I
said, expecting DPS to determine whether a file is a tmp file, or the finished
image is asking quite a bit Am responding onliune (AP took a powder on me this
morn.), so will keep it short. Keep On Imaginin' :^) Erik Flom
BTW, you keep grousing about DPS' lack of support.
Well, at least I can DL' the latest patched version of _their_ s/w for
free! (Or, is this the reason you'd like _them_ to fix the problem? :^)
Keep On Toastin'
Erik Flom – ELF Works 3D Construction Co.
Erik
The other problem that eveyone forgets is that the PAR does not know
how to Cache, so our file format could be easily read if not valid it could
wait until it gets valid, this would be trival on thier part.
We will indeed be writing a temp file to the main drive and this fix
will be part of the 3.x update program.
Mike
While it would be trivial for PAR to support your intermediate format(s),
I think it's the thin end of the wedge.
As it stands, people who own the PAR know they can use it to load and save
images and framestores as if they were accessing a real drive. If
companies start relying on the PAR to take care of things like storing
non-image data, pretty soon DPS is going to have to bend to the will of
every type of caching out there.
To say that 'the PAR does not know how to Cache' is like saying Imagine
has a funky User Interface – both statements can be untrue, you just have
to look at it from both sides.
Thanks for taking the time to resolve this problem. You're going to have
some very thankful user's. (Even if there is 'only a few' of us out there.
:^)
Keep On Toastin'
Erik Flom – ELF Works 3D Construction Co.
Erik
The problem is a DPS problem, its simple, while our interface may be
quirky it has been so for 5 years, nothing new in that comment. The DPS
problem has been a problem that they knew about and ignored, we until recently
did not even have a board to do this field render thing. On the other hand,
these folks were aware of Imagine and as such should have taken it upon
themselves to communicate thier needs to us, in the least, and at most should
have supplied us with a board to get thier product inline with what we are
doing. I must say that other companies have seen that this was a wise idea,
Digital Creations, Centaur Development, to name a couple, there have been
other makers of hardware that felt Imagine was an important product to
suppport.
I think that there is more that can and should be done with the PAR, we
could do those things but without a sense of co-opeartion there will be little
done.
I am sure it is easy to assume that we are not willing to work with
other vendors, nothing could be further from the truth, we are as open as
possible, with the release of our file formats, and texture information we are
making easy for anyone to explore the possibilities.
The time has come when the user, needs to look at all sides of the
issue, our software does not come easy in the development stage, this is not
news either, its the same for NT or GVP or any other company for that matter.
The only thing that most users have in common is the computer they use, not the
extra added goodies, like the PAR. We still have to address these issues as
well as others that are not as high on the list for most users.
We have already fixed the problem in house and will soon be releasing a
update to the folks on the Constant Update program so at least those who are
supporting us will find a higher level of service, that is indeed what the
Constant Update program is all about, service.
I think that this release will be an EXTRA release with a few less
goodies than 3.1 but it will have a intresting surprise for most users.
Thanks for your comments and I hope that at some time we can all
refrain from deciding that one vendor or the other is the bad guy. When a
problem crops up, lets us know, we will fix it and get it to the user base in
the best and most cost effective method that we can.
We are still listening, we are glad that some are still talking.
Mike
>>apparent after you conversation that they could care less, they have all
>>the LW users they need.
That's funny, that's what they said about you, "Impulse now has PC users
and could care less about Amiga users."
All I know is that if it works with LW, as a non-programer, it seems that
you have to change the way you are sending the file to the way LW sends
it. Should DPS make 2 versions of the PAR software, one for LW and others
that work with it and one special version for Imagine? I think not!
Loosing money as time runs on,
Jim R. Ollick
Using AP from Bergenfield, NJ
James
I dont think you get the point, we know the problem does exsist, no
matter what LW or DPS does, and while it seems that everyone has become a
programmer, the way our code works, is not so easy and as some have said TRIVAL
to change, if it were we would have already done so.
There is as I said before, a simple stop gap measure that you should
employ, render the pics and dont ask Imagine to address the PAR, simply copy
the images over to the PAR after you have amassed a few hundred or so. It
works for me until the programmer persons take up the challenge.
As for not needing Amiga users, I would like to remind you and DPS that
we have supported the Amiga data base in the face of others moving to platforms
and dropping the Amiga entirely. I find this kind of comment totally absurd,
DPS has never even tried to deal with the problem.
The fact of the matter is this, we have many more users of Imagine than
does DPS have of the PAR. It is simple and cost effective for them to address
the problem, with a few exceptions you are the only person who is still
beating this thing beyond resonable limits. We will fix the problem, now I
suppose you think it makes good sense to send every Amiga user and PC user a
new copy even if they dont have a PAR board. This makes no sense and is far
beyond our financial capability.
I would like you also to know that until last year, after 12 calls to
DPS and 3 letters, I was promised a PAR card, it never came, we could have
addressed the problem a long time ago, but someone, at DPS thought the effort
to get us a board was not worth it. I guess its easy to blame Impulse for the
problem, when out of ignorance of the product we have done what we have done.
It took a call to the VP in Kentucky to get a board, and that was a board that
we paid for, one that I must add we only wanted for a few days to get things
straight.
As you might know, we have a Non-Linear editing and animation system
that far exceeds the abilities of the PAR, the product was sold to Sanyo
Electric Corporation of Japan. It will be available in Jan of 95 from Sanyo,
and it has none of these problems. I dont suggest that you buy one, but I
there is indeed two sides to every story, possibly you know have a better
insight in to our side.
We will fix your problem with the PAR and as well will try and figure a
cost effective way of getting the fix to those who need it. Until then, try my
way of making the images and storing them to dh0 or wherever you have some
space, copy them over, and it all seems to work just fine.
Mike
Mike,
Sounds like the other users here have explained the problem pretty clearly.
Imagine is trying to save the interim file into the same directory as the
regular .pic files, and since the "directory" is the PAR: virtual device, it
chokes.
You need to add a "Directory for .temp files" in Preferences.
I have the same problem, too, and it just lost me a job. My new 3.1 disks
arrived and I bragged to the client that it would do field rendering. Very
embarassing.
This is something that should be fixed NOW, not something that should wait for
another interim release. It's really hurting those of us who are trying to use
your product professionally.
Pete
Pete,
We understand, and it is also a bit more complicated than you know. I
am sorry you lost work but it seems completely absurd that you would have done
so. There is a simple way around the problem for now. Make the images and
save them to a different drive, then simply copy them in mass over to the PAR
drive, it works for me, I assume you knew that, and I also assume that this
would have kept you from loosing any work.
We will fix the problem in the RIGHT manner, not just some dumb fix
that will break something else. And we will figure out some way of getting
this fix to those who have the PAR, I trust this answer will suffice for the
time being, we are aware of your problem, you have a workaround and also the
knowledge that we are doing what we can.
I do find it silly, as a side note, that DPS has not said, he we could
make our code, look for a file format, if it aint right we will just wait for
another cycle and see what happens, if it starts to render again, then we will
wait for the next time out and maybe it will be right, no instead its easier
for them to not communicate with Impulse and hope the problem will go away.
Yeah that makes much more sense, while people who have purchased an expensive
hardware product and who are loosing money not being able to use it, are told
that Impulse has the problem and LW does not, that makes great business senese.
Mike
Mike,
>> There is a simple way around the problem for now. Make the images and
>> save them to a different drive, then simply copy them in mass over to
>> the PAR drive . . .
The problem was essentially my fault, in that the Amiga was on site at the
customer's facility and I walked in, perhaps a bit overconfident, with my
trusty new 3.1 disk and announced that now we could do field rendering (which
they had insisted on for this particular project). The result, as you can
Imagine, was rather embarassing. The client didn't want to hear about
workarounds; they wanted to see me do what I said I could. My fault; I should
have tested it out privately.
>> We will fix the problem in the RIGHT manner, not just some dumb fix
>> that will break something else.
Fair enough.
>> [w]e will figure out some way of getting this fix to those who have
>> the PAR, I trust this answer will suffice for the time being . . .
Can't get much fairer than that. Please make sure I'm on your "PAR" list.
>> I do find it silly, as a side note, that DPS has not said, hey we
>> could make our code look for a file format, if it aint right we will
>> just wait for another cycle and see what happens . . .
Well — not really. They took a unique approach to a generic problem: how do
we do what the PAR needs to do, given how the existing 3D programs work. Their
approach was to make the PAR look like another hard drive to the application.
But given what the PAR does, it can't completely be treated like a regular hard
drive — because it isn't one. That's a basic hardware limitation of the PAR;
and it didn't present a problem to 3D applications existing at the time the PAR
was developed. One can hardly hold DPS responsible for not knowing how Impulse
was going to implement field rendering. It's just a matter of luck that you
and Newtek used different methods, and theirs happens not to break the PAR. It
could just as well have worked the other way around.
Pete
Pete,
I dont want this thing to denegrate to a name calling situation, but, I
can assure that DPS could have done the whole thing differently, and to assume
that there is something special about the hard drive connected to the PAR is
wrong,. It could be anything they wanted it to be. The only reason they use
this drive is so that they can get a constant speed playback, from an
unfragmented file format that they control, sorta a simple way to attack an
even simpler problem. We have done the same thing but we dealt with the entire
problem.
I am sure that you are happy with the PAR and I hope that it makes you
lots of money, however I must admit that we did approach the problem with a
different and more productive approach.
Never-the-less I guess that the real lesson to be learned here is a
simple one, check it out before you assume that everyting is perfect. 3.1 is
an iterim program, the constant update program is also going to be trying some
new things out on the code of Imagine, it is up to you to beat the hell out of
it so that we find any and all bugs before we get to Imagine 4.0. This is why
the upgrade price is so low, we want to let you have feedback, and input to the
development process. In a small way, Imagine has been the domain of Impulse,
we have made it for ourselves, it became apparent that Imagine no longer
belongs to us, it is your code now, you make money with it, pay bills with it
and do other great things that we never hear about until it does not do what
you want it to do.
We are listening and we are glad that you are talking, together we are
going to make Imagine….. the best that it can be.
Mike
Mike,
>> …to assume that there is something special about
>> the hard drive connected to the PAR is wrong.
I didn't mean that there was something special about the drive; I meant that
although the drive is made to look like any other partition to AmigaDOS it
really isn't, because the PAR board and software sits between it and the rest
of the system.
>> …it is up to you to beat the hell out of [Imagine] so that we find
>> any and all bugs before we get to Imagine 4.0.
Sounds good to me! 🙂
>> you make money with [Imagine], pay bills with it and do other great
>> things that we never hear about until it does not do what you want it
>> to do.
Jeez, I hope you hear at least some of the good stuff too, from time to time.
Pete
Pete
Most of the time the good stuff stays hidden, I think the loudest
voices are often the ones that have the most negative things to say, not to
insinuate that you are being negative but you hardly ever see good news on the
TV. I suppose it is the state of things in general, people beleive that for
some reason they get more from being nasty, for the most part however we enjoy
peoples comments even when they are less than positive.
I do also think that when people post the positive things, other people
tend to blast them for being kiss arses. SO I guess you cant win for loosing.
Have fun.
Mike
Mike,
Have you had any experience with the V-Lab Motion board? This is an
alternative to PAR that I am looking into.
…Warp Engine Engaged…
-Paul-
Paul
No I have not, and I doubt that we will be getting one, so move slowly
and make sure that they read TIF or TGAs or something after the fact so that it
wont create a problem. Let me know what you find out.
Mike
Pete and James,
Give me a couple of days and I'll upload a little ARexx utility which will
let you correctly field render using Imagine and the PAR. I can't bear to
see you losing jobs over this. The macro will simply read images from one
directory and copy them over to the PAR, as they are created by Imagine.
Each copied frame will be deleted from the source directory, so you'll be
able to render large sequences without having to possess enough storage
for all the frames. You're welcome.
In the meantime, perhaps you'd like to send me a typical Imagine project
name, and destination PAR "directory"? I'd be nice enough to create
iconized scripts to launch the macro from Workbench.
You meet the nicest people online sometimes. <bow>
Blaq!
Blaq !
Thanks for you comments and help, this is what this is supposed to be a
forum for ideas, exchange and a sense of team. Thanks for being a good
quarteback, I think that a light is always better than a scream.
Mike
Charles,
I appreciate your offer very much. There was a time when I would have been
able to do something like that myself; unfortunately (or maybe fortunately!)
I've been so busy lately that I never have time to tinker anymore. We're
talking fourteen and sixteen hour days here. So I never would have had a chance
to discover your workaround for myself.
>> In the meantime, perhaps you'd like to send me a typical Imagine
>> project name, and destination PAR "directory"?
Sure. A typical project would have a directory like:
Video-1:CoolLogo.imp/PAR.pix
..which would contain the individual .pic files, and the PAR "directory" would
be something like:
DDR:CoolLogo
..which would contain the PAR animation file.
>> You meet the nicest people online sometimes.
Indeed. I'm in your debt.
Pete
Thanks for your ARexx script offer. Another member suggested Sentry (that
comes with ADPro) I tried it and found it to work without a hitch.
However, I'd still like to try your approach. I would like to render my
picture files to RAM:, I would save them to DDR:rendered-anims.
Thank you for your time,
Jim R. Ollick
Using AP from Bergenfield, NJ
If you have ADPro, you could use the Sentry program to monitor Imagine's
rendering to a disk file, and then when the file is done you can have Sentry
copy it to the PAR and delete the disk file. I've had similar problems with
other software, and that's a solution that's worked for me.
If you don't have ADPro/Sentry, I think the shareware REND105 (something like
that) might work for that sort of thing,too.
Jim Shields
Regal Rodent Development
The only problem that I have is with field rendering, full frame rendering
to the PAR works just fine. I have ADPro but do you really think it will
split the fields?
Jim R. Ollick
Using AP from Bergenfield, NJ
My guess is to what is happening is this:
1. Imagine renders a continuous stream when it renders to regular frames. When
it's done, it closes the file, and the PAR munches it, and everybody's happy.
2. When rendering fields, Imagine does its setup, renders the first field, but
in a temporary format. It then pauses a bit, sets up again, and renders the
second field, probably also in a temporary format. Then it combines the two
temp files. Now the PAR is waiting for a frame from Imagine. When Imagine
completes the first field, which is not a complete frame, the PAR software
assumes that the frame is done, and looks at the file. It doesn't see a
complete frame, and chokes.
IMHO, the fix for this should probably come from Impulse — I think Imagine
should render its temp files (*I am assuming it's rendering the first field to
some sort of temp file, probably in the subproject's output directory *) to a
TEMP directory (maybe where quickrenders are rendered?) and then after the
second field is rendered and the final frame is assembled, write the final
frame to the subproject output directory. This will probably involve some
increased memory overhead, and a bit of processing time, but it need not be
significant.
As for ADPro, my thinking is that Sentry can wait for the frame to be completed
(both fields) and then do the copying to DDR:woof or whatever your PAR
directory is. Then the PAR won't get confused, because it's getting the final
file. I don't have 3.1 for the Amiga — I have 3.1 for the PC, and copy
rendered frames from the PC to the Amiga over a network, to the PAR — but I
*think* Sentry, or possibly REND105 (or whatever number it's up to) should be
able to wait for the completed frames and then send them to the PAR.
I can try and cobble up some AREXX code (kinda blind, but I'll give it a shot)
if you want, for use with Sentry.
Jim Shields
Regal Rodent Development
Thanks, I tried sentry but it needs an Arexx script that I do not know how
to create. I would be very greatful if you could create one for me. I
would save the temp file to RAM: and then to DDR:.
You are correct, Imagine 3.1 creates the odd.0001 file, then an evn.0001
file (or visa versa) them combines the two. The PAR sees these files and
reports back no ILBM found. Imagine also reports back that it can not find
the two files to create the final one.
You are absolutely correct, Impulse should correct this. They need to save
the odd and even files to RAM: then to DDR:
Jim R. Ollick
Using AP from Bergenfield, NJ