dillon@CORY.BERKELEY.EDU.UUCP (12/03/87)
The IFF should NOT contain any actual code to *render* the object, but ONLY code to *describe* the object. That is, have a general set of basic objects, but make the IFF extensible by allowing actual code that would describe the object. The code would have a standard calling sequence something like: min,max,base,dir,result,normal = are all arrays of three coordinates. object_ptr is the custom object that only the code routine knows the internals of. object_code(0, object_ptr, &min, &max) -get bounding box object_code(1, &base, &dir, &result, &normal) -get line intercept point and normal at that point. etc.. So all the IFF would describe is the world... colors, polygon faces, texture mapping (the texture map would be handled by object_code(1,...)), etc... The rendering program would then be able to render the scene any way it wishes: by raytracing, raycasting, Z-buffering, etc... Color information would include inverse absorbtion coefficients, reflection coefficients, etc... in R,G,B with enough precision (i.e. 16 bits per R,G,B) so that conversion to/from other color formats would not cause any problems. The texture specification would be IN the color information as a 16 bit integer selecting one of several basic types. The remaining selections are reserved for custom object_code() routines that only they know about. WORLD SYSTEM: Use one standard coordinate system. I suggest a left-handed coordinate system (X going right, Y going up, and Z going into the screen). The header would contain the bounds of the entire scene in an ASCII representation of arbitrary precision. ALL OTHER COORDINATES IN THE OBJECT DEFS ARE NORMALIZED. That is, the bounding box defines the minimum and maximum, so we represent the coordinates of the objects as 32 bit integers where 0 represents the minimum and 0xFFFFFFFF represents the maximum. Each coordinate X, Y, and Z is scaled according to that coordinate's min and max. This allows maximum precision. For those people worried about space, a flag in the header would indicate whether unsigned longwords (0-0xFFFFFFFF) or unsigned shorts (0-0xFFFF) be used. The render would convert the normalized format to it's own internal format. The IFF CANNOT MAKE ASSUMPTIONS as to how the render works and thus using a 'selected' floating point format would be useless and unfair. This format allows the renderer to easily scale the world into something it can handle. There would be an Eye and a Center, both specified in homogeneous coordinates allowing both absolute and 'eye at infinity' and 'center at infinity' scenes. The infinity representations essentially mean a parallel projection. Non infinity representations mean a perspective projection. Homogeneous coordinates allow you to do this. Homogeneous coordinates are arrays of 4 longwords, coordinates in object specifications are not homogeneous and specified with 3 longwords. BASIC OBJECTS: color information. R,G,B (or any other standard format... but pick JUST ONE representation for gods sake, don't make the reader programs have to do too much!!!). To be applied to any object or light source. Would also have reflection and refraction coefficients.. may a couple of other coefficients. Would have the ability to specify a texture by way of actual code. The color information also specifies which shading algorithm to use.. None, Lambert, Gourard, Phong, or custom (specified by a code segment). This can be specified in an unsigned byte since I doubt there will ever be more than a dozen different shading ALGORITHMS for a scene. light sources, in homogeneous coordinates allowing both point and parallel. Also allow the light source to *be* any arbitrary object allowing an arbitrary configuration (no longer point, but not parallel either). polygons, plane-ellipses, ellipsoids, and other simple objects. Cubes and such would be represented by polygons. Front-Face: For polygons, use the counter-clockwise standard or the clockwise standard, but JUST ONE STANDARD! This refers to which side of the polygon is considered the front face, and which side is considered the backface... being able to assume the representation this way makes it easy to calculate normals. Polygons do not have to be planar. EXTENDED OBJECTS: Extended objects in the format of actual code. The code must be completely relocatable. An extended object would have a special ID and SIZE field (since the renderer does not know the format of the object). The only information the renderer can get from this object is it's bounding box, color, and specific intercept instances found by calling the code. One code segment can be applied to any number of extended objects, of course. FINAL WORD: Allowing included code means that the IFF will not be compatible across different processor lines. There WILL be an ascii string in the header specifying the processor and if a co-processor is required so rather than crash, those objects are simply not rendered on an incompatible machine. I suggest that no assumptions be made as to the operating system. The code must be relative and completely self contained. The code should NOT ever make OS calls, and any memory allocation must be from the stack. The code should not take more than X Kbytes of stack where X is some decided upon value like 2 or 3. Some people will argue that code should not be included in an IFF spec at all. Consider that if no code is alloweds, it will be impossible to add new object types to the IFF without making those types incompatible and unavailable to all renderers except the one that originally created the object type. -Matt