coy@ssc-vax.UUCP (Stephen B Coy) (03/09/89)
Today's question is "What constitutes a _good_ input file format?" With all the ray trace code floating around I've noticed that just about all of them are a pain to generate input files for. DBW_Render is often sighted as being an example of the worst and after playing with it for a while it is easy to see why. Obviously (he says) it is a better idea to seperate the input of geometry data from surface data. IE if you have a 1000 polygon object which is blue and shiny you shouldn't have to describe how blue or shiny for each and every polygon. QRT and MTV (using nff) do this and it works well. A related question is "What should be controlled from the input file?" One gripe I have with QRT is that the image size is compiled into the code. Until I get a scene set up just the way I want it I like to generate much smaller images. MTV allows this. Since MTV also seperates the field-of-view angles from the screen resolution I can generate a 320x200 image and a 320x400 (interlace) image on my Amiga and both will look the same when displayed full screen. Another problem with QRT is that the FOC_LENGTH parameter, which adjusts the fov angle, is very non-intuitive. I'd much prefer entering an angle. Also, by making the input an angle you loose the problem of having your fov be resolution dependent. Ok, enough gripes, your turn. What makes a good input format? What parameters should be under user control? What is your favorite color? Stephen Coy uw-beaver!ssc-vax!coy "All you need in this life is ignorance and confidence, and then success is sure." -- fortune cookie