# $Id: FUTUREPLANS,v 1.7 2004/01/19 17:09:02 wes Exp $ # $Revision: 1.7 $ # $Log: FUTUREPLANS,v $ # Revision 1.7 2004/01/19 17:09:02 wes # Updated future plans. # # Revision 1.6 2004/01/17 04:02:07 wes # Updated for 1.5.1 beta..more to come. # # Revision 1.5 2003/07/25 21:55:32 wes # More updates for 1.5.0. # # Revision 1.4 2003/07/20 14:54:43 wes # More 1.5.0 updates. # # Revision 1.3 2003/07/20 14:52:21 wes # Updated for 1.5.0 # # Revision 1.2 2003/07/14 02:19:29 wes # More 1.5.0 updates. # # Revision 1.1.1.1 2003/01/28 02:15:23 wes # Manual rebuild of rm150 repository. # # Revision 1.5 2002/09/22 22:57:24 wes # Updates for v1.4.3 distribution. # # Revision 1.4 2001/06/03 20:21:45 wes # v140-beta1 # # Revision 1.3 2001/03/31 17:13:47 wes # v1.4.0-alpha-2 checkin # # Revision 1.2 2000/12/03 22:46:29 wes # v1.4.0-alpha-1 # # Revision 1.1.1.1 2000/02/28 21:29:40 wes # OpenRM 1.2 Checkin # 19 January 2004 Here's a list of stuff we're either working on, will be working on, or is otherwise a gaping hole in functionality in OpenRM. These items are approximately in priority order. 1. FLTK/GLUT documentation and examples. The Gordo distribution contains several FLTK+RM examples. We intend to expand the example base to include GLUT+RM examples, and to write those Chapters for the Programming Guide. 2. Cleaner boundary between RM, OpenGL and the windowing system. To better support integration with other environments, we will clarify the boundary between RM, OpenGL and the windowing system. 3. Obtain a loaner Mac, and do a port to Mac OS X. 4. Statistics & Performance measurement Some rudimentary facilities within OpenRM exist for measuring performance. They are not documented either in the man pages or in the programming guide. Check out the vis3d.c demonstration program for example code. Look for routines of the form rmStats*. The reason these routines are not documented is because the API is still too immature to call it "production code." However, those routines do work and can be useful for those interested in measuring performance. 5. rmdemos - A number of improvements are scheduled: 7a. Add a command-line flag that enables/disables printing of per-frame statistics. Right now, some demos print such information whether you want them to or not. Other demos have such a switch already in place. The lot needs to be consistent. 7b. For the demos vrend, vslicer, we need to detect the amount of texture memory available to applications and respond accordingly. At the present time (July 2003), the size of the default dataset exceeds the maximum texture size permitted by Mesa, which is a common development platform. 6. Offscreen rendering. On X platforms, we use a GLX pixmap for offscreen rendering. A few years ago, pbuffers were not as widely supported as they are now. We need to port the X11 offscreen rendering code to use pbuffers when they are available. 7. Volume rendering. The OpenRM octmesh generates geometry that is aligned with the axes of the underlying grid. The generation code needs to be updated to generate geometry that is perpendicular to the line of sight. This work was supposed to have been performed on a recent project, but the contractor failed to deliver. Sorry for the delay. 8. CVS Access. To partially satisfy the CVS appetite, we can set up a nightly or weekly tarball on the r3vis.com website. We will probably not be doing a CVS repository on sourceforge due to a history of CVS problems on that server. 9. File loaders/writers We have added support for JPEG & PPM i/o, but there are many other popular image formats to support, as well as support for geometric model loaders, and support for OpenRM native binary save/restore. Basically, there is a lot of work to do on the subject of loaders. 1a. An RM-specific save/restore feature set to quickly save and load entire scene graph structures to disk files (a la PFA/PFB). 1b. Loader support for MultiGen .obj files. 1c. Loader support for VRML files. 10. Intersection/collision detection. The idea is to quickly determine whether or not some point or volume in space intersects anything in the scene, and if so, what and where. 11. Texture paging/texture management. There is none at this time. Either all the textures fit or they don't. This area obviously needs work. 4a. Detect whether or not a given texture will fit into texture memory. If not, report and error. This condition (tmem starvation) will occur when using either of the demo programs vrend.c or vslicer.c with any current Mesa implementation. Both of those programs will generate an OpenGL error code when running with Mesa, but will continue to execute. Visually, the results appear to be untextured geometry. 12. Other language bindings, such as C#, to better support Web-enabled use of RM in graphics and visualization applications. One OpenRM user contributed some bindings to C#. We are in the process of investigating that work now. --EOF--