Forgot to ask…
7 messages in this thread
"IPAS3"? Since "IPAS" stands for .IXP, .PXP, .AXP, and .SXP, and since
Release 3 adds .BXP (bitmap import/export filters) and .KXP (Keyframer external
procedures — YAY!!!), why not a new acronym that includes all of those? I
suggest "BIPAKS" (pronounced "bypacks"). <grin>
Can .BXPs import bitmaps from ANY source? Could, for instance, an SVTR .BXP
be written that on export would write to a specific tape frame, and on import
read (rotoscope) from a specific frame (or range of frames)? It'd be a lot
more elegant than the Video Post .BATch files needed now. Assign a rotoscoped
texture map by clicking on ".SVR" (added via .BXP) and giving a "file name"
which encodes the start frame, as in "00033015.SVR" to mean "00:03:30:15" (0
hours, 3 minutes, 30 seconds, frame 15). This would mean rotoscoping could be
done without having to resort to Video Post.
BIPKAS maybe? <g>
BXP's are technically capable of writing to any source, but you've got to
realize that they have absolutely no UI, since their purpose is to be
user-transparent file filters. It's an interesting thing to think about,
however. We'll have to have a discussion about it after we ship R3.
Snowed under in SF,
– G
I dunno. I think BIPAKS sounds better that BIPKAS. <g> How about SKIPAB?
BASKIP? PASKIB? (Hmmm — almost sounds like Pascal!) SPIBAK? SPAKIB?
PSIBAK? PSIKAB? Lotsa possibilities here! 🙂
I must say I think it was rather short-sighted of you to provide no UI
capability to BXPs. I suppose it's possible for developers to brute-force
build their own UIs if necessary, but they shouldn't have to. Even discounting
what I discussed before, allowing BXPs to pop up dialogs for more info would
have been quite nice — an advanced TIFF BXP could have allowed the user to
select from a list of the various compression methods supported by the TIFF
spec, move the origin, change the DPI resolution, adjust the TIFF for Macintosh
compatibility, etc. An AVI BXP (presuming that BXPs can also do animation
saves) could allow the user to select between standard Microsoft AVI and the
better (but which requires either a 486 or a special coprocessor card) Intel
Indeo compression. Without UIs, seperate BXPs would be required for every
possibile variation on the TIFF, EPS, AVI, etc. formats, and the user would
need to know which button to click (not to mention how quickly this could fill
up your File Load/Save dialog boxes with BXP buttons!).
I mean, how hard would it have been to allow BXPs to call the same UI
interfaces as IXPs, PXPs, AXPs, SXPs, and presumably KXPs? Seems to me you
would actually have had to have gone to extra work to REMOVE those calls from
the scope available to BXP routines!
Actually, it was a very deliberate design decision to make BXP's
interface-less. The entire POINT of them was to provide a transparent way of
loading any file format. The way they work is, if you've got an AVI.BXP
sitting out there, the bxp searches for whenever you look for AVI files and
then just converts them as if the AVI file format was designed into the
program. You don't have to know about buttons or anything… just select the
file and go. (bxp's don't put up their own buttons; you just select them from
the file selector list)
I've got an entire design document around here somewhere discussing why we made
these decisions. Perhaps after we ship R3 I can dig it up for you.
– G
PS: If you want to configure a bxp to do something special, you can use a pxp
that writes a configuration file. We ship a couple of examples with R3 that
show how this is done.
Ah, okay, I guess that makes sense. So the BXPs are loaded at startup
time and automatically activate if a file of their given extension is to be
loaded or saved? That doesn't quite jibe with the 3DSr3 demonstration I
saw at your SIGGRAPH booth, though. I clearly remember the demonstrator
loading bitmaps as various maps in the new Materials Editor, and seeing all
the usual File Type buttons in the dialog box (.GIF, .CEL, .TGA, .TIF,
.FL?, and now .BMP and .JPG as well). From what you say, those buttons
should not have been there. I thought .BXPs would show up as their own
buttons — for instance, if you had an AVI.BXP in your PROCESS directory
when starting 3DSr3, and you selected any command that would ask to load or
save a bitmap (Materials Editor maps/masks, Video Post, etc.), you would
simply see an ".AVI" button alongside all the others that are normally
there. Clicking it would show only matching .AVI files, and you could
select an .AVI file and load it as usual. I guess I was wrong.
I was hoping that maybe it was set up so that right-clicking on any of
the file type buttons, regardless of whether it was a built-in or .BXP file
type, would, if the type supported it, pop up a dialog box that lets the
user specify certain options (especially on saving, but I could also see
this being useful on loading) such as various types of compression for
TIFs, etc.
Now you're getting it… I think your confusion was due to thinking that
JPEG and BMP were handled via BXP's… they're not. Those formats are now
built into the basic architecture of the system. To load BXP-filtered
files, you just click on *.* and then select the file format compatible
with a BXP filter that you've got in your process path. It's completely
transparent to the UI.
And, like I said before, BXP's _can_ read parameter files, which can be set
up via PXP's. So they're quite flexible, actually.
– G
Ahhh! Okay! That does make sense!