Geomview For Windows?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Goals for the January 1992 release (!!)
I'm cleaning out my home directory and came across the following file which I don't need to keep personally but I thought it would be nice to record it here (in software.log) for posterity. The date on the file is Nov 25 1991. ------------------------------------------------------------------------ Goals for the January release of the OOGL/viewer monster (not in any particular order): I. Come up with a name for the viewer! Something catchy would be nice, but in the absense of such I'd like to propose that we start calling it "geomview" for now, until we come up with something better. I'm afraid that if we stick to "w" or "v" or "wv" too long, they will stick permanently! "geomview" is at least descriptive of what it does (displays geoms) and where it came from (Geometry Center). II. Compatibility with MinneView. A. data file formats My understanding is that this is not a problem --- the gprim formats haven't changed, right??? B. communication We need to somehow support communication with external programs written to talk to MinneView: 1. Programs that use shared memory directly (trigrp, dirdom, evolver, ...). 2. Programs that use "stuff" We could re-write "stuff" so that it writes its data to a named pipe instead of stuffing into shared memory. Geomview can read from that pipe. Is this the best way to do this? C. Other??? Are they other things we need to keep in mind? In general, someone currently using MinneView should be able to start using geomview for the same task with a minimum of adjustment. III. User Interface A. Hook up & polish Tamara's panels. B. Lighting editor Regarding the debate about whether the lighting editor should be internal or external: would it be possible to think of the entire user interface as potentially external? Like Mathematica, sort of --- a computational kernal and a separate front-end. We could supply a built-in, default front-end, which could be replaced when desired by something external --- perhaps a collection of specialized external front-ends (one for material, one for lights, one for motion, ...), any subset of which could actually be hooked up when needed. The viewer could be compiled either with or without the built-in front-end. ??? This is just food for thought at the moment; how much work would it be to do this? IV. Ability to save / restore viewer session Should be able to save various aspects of the viewer state: the state of the viewer itself, the geometry itself, etc. V. Ability to save image files What formats ??? At least SGI format, at first. VI. XGL viewer VII. Documentation A. source-code --- clean it up, document it, and put copyright notices on everything in sight. B. other documents to write 1. viewer man page 2. viewer tutorial --- interactive, if possible ??? Or, our philosophy could (should?) be: the we'll make the thing so easy to use that no tutorial is necessary !! Is this possible??? 3. "How to write an MG device driver" 4. "How to port the viewer to a new platform" 5. "How to write a new gprim" VIII. Debugging and testing We need to exercise the code more --- try displaying various gprims, editing appearances, etc. Track down and fix bugs bugs bugs!
Home | Overview | FAQ | Documentation | Support | Download | Mailing List
Windows? | Development | Bug Reporting | Contributing | Contact Us | Sponsors
site hosted by