CompuServe Messages

The current capabilities of the "output" mode for BXP is severly limited. It pre-supposes output to a "sequence of files" with an increasing number in the last 4 chars of the file name. This is well and good for a "step-wise" animation to independent files. It is very "weak" for supporting output to a multi-fram file such as AVI, MPEG, and the like. Why is this so? The existing Client function sequence is a repeated pair of ClientSaveImage – ClientTerminate. This sequence pre-supposes Memory allocation, File Open, FileWrite, FileClose, Memory Free for each individual frame. It does not allow the BXP to optimize memory allocation for multiple frame handling. I would propose that a new client function be added for animation output to multi-frame files, and another client function added by which 3Ds can query the BXP as to the method to be employed: e.g ClientGetMode(EXPbuf *buf) to query the BXP as to whether it wants Multi-frame single file method, or Multi-frame multi file method. The client can return an appropriate opcode stating which method to emply for the BXP. When a BXP wants multi-frame single file method, then a ClientPutFrame(EXPbuf *buf) needs to be devised to be called sequentially with no intervening ClientTerminate until after the final frame or an error exit is determined. The mapping of buf.data union should be to a BXPSaveImage structure, BUT the structure should be revised to add a traid of "frame" variables analogous to the FrameParm variables used in an IXP. The BXP needs to know the following via the BXPSaveImageStructure: int start_frame; // frame number of 1st frame to be submitted to the BXP int end_frame; // frame number of the last frame to be submitted to the BXP int frame; // current frame number with the above 3 vars added to the structure, a BXP can optimize all operations relevant to memory and file allocations, and can keep track of what needs to be freed on the final call to ClientTerminate. The current method of ClientTerminate after each frame forces a BXP to always free stuff between frames and this is grossly inefficient for some potential BXP implementations.