woolstar@nntp-server.caltech.edu (John D. Woolverton) (11/12/90)
I'm looking for input of any kind (all kinds), for a reasonable animation scene and object file format. I have been involved for the past several years breaking down animation files from various mid-range PC packages, and putting them into a format to be read quickly and easily by our own software. After adapting to many changes in the input software, as well as a few different designs of our own, I've come to the point that I'm pretty comfortable with what I have now. There's only two problems: 1. No one else can read the format 2. Everyone says I should be Renderman compatible. First of all, I've read through Renderman several times, and there are THREE big problems: It's hard to parse (ok, there's supposed to be a binary encoded version), there's no coherency in the objects that a ray tracer could use, and there's little to no coherency between frames. There is also no language or place for describing any type of ray tracing bounding organization (octrees, bboxes, or other). Now while I could get away without caring on Un*x boxes, my friend has gone and ported our work to the Macintosh. So I'm looking for a better answer than just what we've brewed up by ourselves. What we have now: The scene is basically in three parts: the objects, the animation tracks, the scene description. The objects start out very simply as a short list of surfaces, a list of verteces, and a list of faces. We load these up, calculate surface normals, and write out a binary version, but they stay basically the same. The animation tracks are the positions and transformation values for various pieces of the scene: camera, lights and objects. This is currently all compiled from a nightmare format of key frames, static tracks, and interpolation vectors. Camera and light values are complete calculated out (all hierarchy worked out), and objects are left as a series of transformation and attachment data (rotate, scale, translate, parent). The scene description (always a text file) contains pointers to the object files, and animation tracks, as well as hierarchical structure, and any other options we could come up with (shadows and falloff values for lights, object -> file lookup tables, and any resolution information for the camera). This is probably the most underdeveloped. The principle in all of this, was make the bulk of the data easy and quick to read in (no calculation or parsing), and the small important part easy to change (textual) but still easy to read in (very minimal parsing). Any experience or thoughts on this would be greatly appreciated. If anything forms out of this, I'll be sure to keep comp.graphics up to date. John D. Woolverton, animation production engineer woolstar@cobalt.caltech.edu | woolstar@cit-vax.UUCP ---- The ideas and spelling mistakes are all mine. "Jobs don't kill programmers, programmers kill jobs."