CompuServe Thread

As requested by Jonas, here is my April 1 list of IPAS improvement requests… —- More orthogonality in functions From my perspective as a maker of foreign file import and export routines, I want enough IPAS functions to create a complete object including geometry, hierarchy and materials. (I'll leave motions out of the discussion for now.) For a file exporter, I need to access both the hierarchy information as well as the geometry at the same time, so my routine can make a proper object for another file format. The brick wall between the functionality of the Keyframer and the 3D Editor makes it very difficult to assemble links between objects you've just made in the 3D Editor. Far too often while reading the IPAS docs, I got the feeling that IPAS functions were added only as needed to accomodate specific new IPAS ideas. Instead, new IPAS functionality should be added in general, extensible contexts. In general, I'd recommend adding more IPAS functions to make access to the internal data more orthogonal: every item of data inside the program (as created through the actions of the user) should be able to be examined, set, created or destroyed from within IPAS functions. Orthogonal example with materials For example, there should functions for manipulating materials: 1. Iterate through the list of materials in 3DS at the moment. Retrieve each name. (You can do this now.) Expand this include a mechanism to retrieve all other values associated with the material. 2. Add a new material given a name. (You can do this now, but you can't set any material attributes.) To avoid a big struct and for future expansion of material definitions, make a function that's passed a struct containing the name or index of the material to change or retrieve, plus a union pun that can hold any data that defines a material. Each element within a material (various RGB values, specular coefficients, map filenames, etc.) would be assigned a unique #define enumeration, and 3DS would reset the element based on the proper value. 3. The limit of 255 materials per scene is tough. With our import and export conversions, this was a major obstacle. However, the user faces this purely within 3DS, too. Loading a series of objects with varied materials soon overflows the list of materials. If IPAS routines could iterate through the material list, we could write our own routine that mapped excess materials to the list of 255. But this is a tough routine to write. If 3DS had an official method to map excess materials, we could follow that rule. Otherwise, we'd need to invent our own. IPAS descriptions The user should see a better description of each IPAS routine. DOS filenames are bad enough, restricting them to six characters (because of the _I or _W suffixes) makes it worse. Instead, the user should see an English descriptive name. One possible way to do this would be to require a database-like file that contains basic information about each IPAS: a description, version numbers, date stamp, etc. The file would have a standard extension, and 3DS could examine them on startup when it builds the list of available IPAS routines. Automatic recognition Depending on filename extensions for loading alternate bitmap formats is a good idea. But what about PICT files, for example, which do not have a standard filename extension? An alternative would be a scheme that, when the user has selected a file that isn't recognized by 3DS's internal GIF/TIF loaders, would query all available BXPs to see if they can recognize the file type. They would be passed the filename, and perhaps a buffer of the first few bytes of the file, and if one says it can recognize it, then it should load it. You could do this with 3D files, too: our InterChange loaders all contain a subroutine that can attempt to "autorecognize" any 3D file format. I have a lot of experience with developing APIs that handle this kind of extensible loading and recognition of file types, if you need some free advice, I'm here to help. With a better organized loader/saver scheme, the list of available formats would be present in the Load and Save dialogs. For example, our after-market export IPAS would appear in a list of available export formats, in the Save As dialog. Future IPAS Also, I'm curious about how IPAS will be adapted to WinNT and the SGI. We've adapted our translators to several platforms, including DLLs under Win32s / Windows NT.