# $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--