# $Id: RELEASENOTES,v 1.11 2001/07/15 23:05:56 wes Exp $
# $Revision: 1.11 $
# $Log: RELEASENOTES,v $
# Revision 1.11  2001/07/15 23:05:56  wes
# 1.4.0-FCS releasenotes.
#
# Revision 1.10  2001/06/03 20:56:20  wes
# v140-beta1
#
# Revision 1.9  2001/03/31 17:13:47  wes
# v1.4.0-alpha-2 checkin
#
# Revision 1.8  2000/12/04 00:31:22  wes
# Added RM_FONT_DINGBATS problem description.
#
# Revision 1.7  2000/09/02 19:26:13  wes
# Updated info re: default button/action mappings for RMdemo programs.
#
# Revision 1.6  2000/09/02 19:06:39  wes
# For rm130 release.
#
# Revision 1.5  2000/05/17 14:35:01  wes
# Partial update for 1.3.0.
#
# Revision 1.4  2000/04/27 03:13:58  wes
# More 1.2.1 updates.
#
# Revision 1.3  2000/04/22 01:44:23  wes
# OpenRM 1.2.1 updates.
#
# Revision 1.2  2000/04/20 17:43:28  wes
# OpenRM 1.2.1 updates.
#
# Revision 1.1.1.1  2000/02/28 21:29:40  wes
# OpenRM 1.2 Checkin
#

July 15, 2001 v1.4.0
--------------------

New Features and API Changes in v1.4.0
--------------------------------------

1. The RMaux "init function" now has an additional parameter: the 
RMnode that is passed to rmauxEventLoop. Formerly, the app init function
was declared as:
	void myInitFunc(RMpipe *p);
and should now be declared as:
	void myInitFunc(RMpipe *p, RMnode *subTree);


Bugs fixed between v1.4.0 and v1.4.0-beta1
------------------------------------------

1. Memory leaks associated with rmPrimitiveDelete/OpenGL display 
lists fixed (see Known Bugs).

2. Choice of direct vs. indirect OpenGL contexts is working properly
again. In Beta1, an indirect context was always used, thereby 
reducing performance of all OpenRM apps.

3. Fixed bad code in private_rmFontRegistryIndex that would return
the incorrect font registry index when using RM_TRUE for both
emboldening and italicization.

4. The rendering error reported in v1.4.0-beta1 in the "jack" program
under older versions of Mesa is fixed in Mesa version 3.5.

5. rm2screen would sometimes fail to launch all windows. This problem
has been fixed.

6. Fixed a memory leak associated with management of RMtextProps objects.


v1.4.0 Notes about the nVidia OpenGL Drivers
--------------------------------------------

At this time, we have no open issues related to the nVidia drivers
under Linux! We have even tried out early versions of upcoming drivers
(1.0-1420) and were pleased to see that there is h/w support for
3D texturing on GeForce3 cards. Kudos to the folks at nVidia!


Known Bugs/TODO
---------------

1. During the SBIR work, support for display-listing of RMimage
objects had to be removed, and has not been reimplemented using
the context cache framework. As a result, performance for image
operations (background image tiles, sprites) is less than what is
possible as all these operations occur in immediate mode.

2. There are lots of compile warnings on IRIX systems. Most of these
warnings point out variables are declared, but not used.

3. The configure script in $RMDEMO is pretty lame.a

4. Only transformations are frame-accurate in multistage processing.


June 3, 2001  v1.4.0-beta-1
---------------------------

The v.140-beta-1 release provides increased stability in the
multithreaded and multistage rendering subsystems, and adds support
for input/output of two popular raster image formats (PPM, JPEG).
Thanks go to jdb for the new PPM code.

Features New in v1.4.0-beta-1
-----------------------------

1. Added support for PPM and JPEG input and output. There is a new
directory, $RM/rmi, that is the new home for image loaders.

2. Wired in support for OpenGL spotlights.

3. New RMAUX routines for attaching callback to handle keyboard
and window resize events. Removed callback handlers from the
rmauxEventLoop() call (thanks go to jdb for these new routines).

4. New routine rmPipeProcessingModeIsSerial(RMpipe *) can be used
to determine if the current RMpipe processing mode is serial or
multithreaded. Note that there are two serial modes (one is
multistage), and two multithreaded rendering modes.

5. Improved $RMDEMO/configure script by (1) adding -jpeg=/dir/to/jpeg-stuff
flag to let you configure the makeinclude to point to the JPEG 
distribution (Unix systems) and (2) improving support for the
many IRIX ABIs via the previously underutilized -irixarch flag. Note
that the default IRIX ABI is -64.

6. New RMDEMO programs:
	a. spotlight - interactive demo of OpenGL spotlights
	b. glxinfo - writes lots of info about your GLX system to stdout
		(thanks to jdb for this contribution).

Issues Resolved Since v1.4-alpha-2
----------------------------------

1. nVidia detonator drivers and Win32. We isolated our problems
to a single nVidia GeForce card (the ELSA Erazor-X). Other
nVidia cards do not exhibit any problems. We cannot say for
sure if the problem stems from the GeForce + Detonator driver
combination, or if we have a single hardware component that
is broken.

2. RM_PIPE_MULTISTAGE_PARALLEL does not work with the 0.9-769 nVidia drivers.
The multistage, multithreaded rendering modes, as well as the "rm2screen"
demo program both well with the 1.0-1251 drivers and a stock RedHat 7.1
system (2.4 kernel). There is a lingering issue with "rm2screen" in
which startup can sometime be "slow." The symptom is that the slave
windows do not quickly appear. To rectify the problem, we have had to
manually induce activity in the X11 event queue. This is done by
attempting to rotate the object via the "navigate window". This
activity will cause the 2 slave windows to appear, then the program
operates normally. 

Another development demonstration program that creates four slave
windows, rather than two, does not work properly. Therefore, it appears
that there is a limitation in the current batch of nVidia drivers
that precludes the use of more than three simultaneous OpenGL 
rendering contexts on a single platform.

Known Limitations in v1.4.0-beta-1
----------------------------------

1. Only transformations are frame-accurate in multistage processing.

2. The "jack" demonstration program exhibits render errors in all
versions of Mesa except Mesa 3.2. The problem is that some portion
of the OpenGL rendering context is not accurately restored during a 
push/pop operation. We have not yet narrowed down the guilty attribute, 
and are unable to reproduce the problem outside of OpenRM. This rendering
error occurs ONLY when using Mesa - all vendor implementations work OK.

3. JPEG: Some systems (Win32, Solaris) require you to download and
build the JPEG image i/o library. While this is an inconvenience, it
is well worth the effort. You can grab the source code for free from
www.ijg.org.



March 31, 2001 v1.4-alpha-2
------------------------------

The 1.4-alpha-2 release is the second early code release from work
funded by the US Department of Energy under a Phase I SBIR grant. The
highlights of 1.4-alpha-2 are:

1. Multistage rendering (Win32 & Unix/Linux)
2. Multithreaded, multistage rendering (Win32 & Unix/Linux)
3. Direct support of offscreen rendering (Win32 & Unix/Linux)
4. Thread-safety work for Win32 complete.

We expect to release 1.4.0 near the end of May 2001, after
doing some additional release engineering and fixing any bugs
that are reported in 1.4-alpha-2.

New Software Dependency
-----------------------

Up until this release, OpenRM has been completely standalone - no
3rd party software is required. In order to support full and
consistent multithreading operation across Win32 & Unix, we introduce 
a new dependency:
- Posix threads for Win32: http://sources.redhat.com/pthreads-win32/

The pthreads-win32 library is just a zip file you unpack - no 
compilation is required. You will need to modify your $PATH environment
variable on Win32 to point to the directory containing the new
Pthreads .DLLs - we modified our vcvars32.bat file to do this.


Multistage/Multithreaded Processing
-----------------------------------

OpenRM now supports 4 types of rendering modes, and these are 
attributes of the RMpipe object. Use the new routine

	rmPipeSetProcessingMode(pipe, mode)

to change the processing mode. The new modes are:
RM_PIPE_SERIAL - uses the old serial rendering code;
RM_PIPE_MULTISTAGE - uses a multistage algorithm for rendering (view and
	render). Each stage runs sequentially within one rmFrame() call,
	and both stages operate on the same frame. This is effectively the
	same as RM_PIPE_SERIAL, but uses a different internal code path.
RM_PIPE_MULTISTAGE_PARALLEL - uses the multistage algorithm for
	rendering (view and render), but both view and render execute
	concurrently in separate pthreads. View processes frame N, and 
	render processes frame N-1.
RM_PIPE_MULTISTAGE_VIEW_PARALLEL - places view in a separate thread,
	but keeps draw in the same thread as the caller. Use this mode
	for multistage processing where draw must be in the same
	thread as the caller (e.g., for use with CAVELib or a similar
	package that thinks it owns the OpenGL context). View processes
	frame N, and render processes frame N-1. 

At this time, only transformations are guaranteed to be frame accurate.
See our white paper describing the multistage, multithreaded implementation
for more details. Future work on this project will be to implement
strategies for guaranteeing frame accuracy across all scene graph data.

API and other changes since v1.4-alpha-1
----------------------------------------

1. t3dstubs.c removed from demos directory. This file contained 
stub implementations of glTexImage3DEXT() and glTexSubImage3DEXT().
These OpenGL routines are supplanted by glTexImage3D() and 
glTexSubImage3D() in OpenGL 1.2. The nVidia drivers *do support*
3D texturing (software) but silently fail if your texture is greater
than 64x64x64 in size.

2. The routines rmNodeSetPreTraversalCallback and rmNodeSetPostTraversalCallback
have a new parameter that indicates during which pass of multistage rendering
the callback will be invoked. The new parameter can take values of either
RM_VIEW or RM_RENDER. For applications that use RM_SERIAL rendering, both
RM_VIEW and RM_RENDER callbacks will be invoked during the same pass, 
as view and rendered are combined into one. The RM_PIPE_MULTISTAGE*
family of processing modes will invoke the callbacks in a more
selective fashion.

3. Added a new routine: rmNodeFrustumCullback() to rmnode.c. This routine
should be added as a view-traversal callback in order for view frustum
culling to be active for a given scene graph node.

4. Removed the "center" attribute from the transformation struct, and 
moved it to the RMnode level. No external API changes result from this
change. This change was made because changes to the center point
attribute were causing addition work to be performed in the view/render
pipeline, as the presence of any transformation fields (including the
center point) would cause a bunch of matrix multiplies to occur, and
would load new matrices on the OpenGL matrix stack. This change is
a performance improvement.

5. New routines in rmaux to support offscreen rendering. The new
routine rmauxCreateOffscreenDrawable() will create a structure
suitable for use in offscreen rendering. 

6. rmauxFlyUI has a new parameter: an RMnode * that is the rooted
subgraph to be drawn on each frame. Previously, we assumed that
rmRootNode() would be drawn on each frame. This change was made in
order to support a tiled display implementation of tfly.

7. New offscreen.c demonstration program in RMDEMO. Note that this
program creates a huge image (2K by 2K), and works on both
Unix and Windows (yay!). The image is written to disk in AVS .x image
format. Upcoming OpenRM releases will read/write other raster formats.

8. New tcube.c demonstration program. This program generates a cube
that uses six texture maps.

9. New clrball.c demonstration program. Exercises multipass rendering
with 3D opaque and 3D transparent objects.

10. OpenGL attribute push/pop is much more selective than in previous
implementations. There are no external API changes that result, but
this is a significant internal change. We are on the lookout for bugs.


Known Bugs and Limitations in v1.4-alpha-2
------------------------------------------

1. Offscreen rendering using nVidia OpenGL drivers. We have discovered
that glXMakeCurrent with an offscreen context will crash the Xserver
using the 0.96 nVidia drivers. The problem has been reported to nVidia,
and they say the problem will be fixed in the next driver release.
(This problem is fixed in the 0.9-7 driver release).

2. RM_PIPE_MULTISTAGE_PARALLEL does not work with the 0.9-769 nVidia drivers.
Programs that use this mode will hang when attempting to create the worker
threads. The hang occurs when the render thread makes a glXMakeCurrent()
call to assume ownership of the OpenGL context, and after the caller
releases the OpenGL context with glXMakeCurrent(ctx, None, NULL). The
problem has been reported to nVidia.  Do not use this mode with the
0.9-769 drivers. All other processing modes work OK.

4. rm2screen does not work with the 0.9-769 nVidia drivers. The problem is
apparently known to nVidia, as they clearly state in the 0.9-7 release
notes that there is discord in systems when multiple OpenGL applications
attempt to run at once.

5. Only transformations are frame-accurate in multistage processing.

6. The "jack" demonstration program exhibits render errors in all
versions of Mesa except Mesa 3.2. The problem is that some portion
of the OpenGL rendering context is not accurately restored during a 
push/pop operation. We have not yet narrowed down the guilty attribute, 
and are unable to reproduce the problem outside of OpenRM. This rendering
error occurs ONLY when using Mesa - all vendor implementations work OK.

7. nVidia detonator drivers and Win32. On our Win32 development box,
all OpenGL programs (even little simple ones that don't even use OpenRM
at all) will hang after a few frames. The system wedge is so severe that
only a powercycle will recover the machine. For our development, we
yanked the nVidia hardware and used a Matrox card. The problem was
reported to nVidia. We are using non-nVidia hardware for now on our
Win32 development platforms.

8. The "pdb" and "trans2d" demo programs should *not* be compiled to use
RM_PIPE_MULTISTAGE_PARALLEL. Logically speaking, the multistage mode
of operation is inconsistent with how this program works. That's
good, because it will force us to think hard about this problem in
future work, but it's bad because we wanted all the demo programs
to operate in all modes.



December 2, 2000 v1.4-alpha-1
-----------------------------

The 1.4-alpha-1 distribution is an early code release containing work
performed under the Phase I SBIR Grant from the U.S. Department of
Energy. That grant funds work in 4 areas:
	1. Thread-safety
	2. Pipelined-parallel rendering
	3. Support for tiled displays
	4. Support for off-screen rendering
The major version change number means there are changes to the API.

Thread-safety means support for multiple threads simultaneously
writing into the scene graph, and multiple threads simultaneously
reading from (rendering from) the scene graph. 

At this time, the v1.4-alpha-1 release is thread-safe 
ONLY on Unix/Linux platforms. Support for Win32 is coming soon.

API changes to support thread safety include:

1. rmFrame() now takes two parameters, an RMpipe handle and an
   RMnode handle. The scene graph rooted at the input node is drawn
   onto the named RMpipe.

2. rmauxEventLoop() has an additional parameter, an RMnode handle. The
   event loop internally performs a draw call using rmFrame(), so the
   combination of RMpipe and RMnode are required.

Internal changes to support thread-safe rendering are extensive, but
largely not visible to the application.  The changes were designed to
remove all static data from the scene graph (multiple readers), and
to provide orderly access to scene graph components from multiple
application threads. 

Summary:

3. The RMpipe contains a new object called an RMcontextCache. The
   context cache manages all retained mode structures, such as OpenGL
   display lists and texture object IDs. Applications need not be
   concerned with this new object, and there is no public API to
   manipulate the context cache. Each RMpipe is expected to have it's
   own OpenGL rendering context (needed to support true parallel rendering).
   At this time, multiple contexts do not share display lists or other
   retained mode structures.

4. Portions of the scene graph (RMimage, RMprimitive, RMnode, RMtexture,
   and RMtextProps objects) are now controlled by an internal "component
   manager." There is no public API to manipulate the component manager.
   The component manager will preallocate a large number of these scene
   graph components at rmInit() time, and will dole out and reclaim resources
   from an internal pool of objects as applications new and delete these
   objects (previously, each was malloc()'ed off the heap). The component
   manager internally implements mutex locks, so multiple applications 
   threads that build scene graphs may safely allocate and deallocate
   scene graph components concurrently.

   Warning: scene graph topology changes (rmNodeAdd/DeleteChild,
   rmNodeAddPrimitive) are NOT thread safe, and should be serialized
   in application code (this will be fixed in a future release).

5. To assist applications in synchronizing access to critical sections
of the scene graph, the following family of routines can be used
to create/manipulate/check/destroy a mutex object at a scene graph node:

	RMenum	rmNodeMutexInit(RMnode *toModify, RMenum lockStatus);
	RMenum	rmNodeMutexLock(RMnode *toModify);
	RMenum	rmNodeMutexUnlock(RMnode *toModify);
	RMenum  rmNodeMutexTryLock(const RMnode *toQuery);
	RMmutex *rmNodeGetMutex(const RMnode *toQuery);
	RMenum 	rmNodeMutexDestroy(RMnode *toModify);

The mutex locking enumerators are: RM_MUTEX_LOCK and RM_MUTEX_UNLOCK.
rmNodeMutexTryLock will return either RM_MUTEX_LOCK or RM_MUTEX_BUSY.
rmMutexLock is a blocking wait. 

The RMmutex objects are implemented using "error checking" mutexes.
The primary difference between "error checking" and "fast" mutexes
is the behavior when a thread tries to lock a mutex it has previously
locked. When a thread that owns a locked mutex of type "fast" attempts
to lock the same mutex again, it will deadlock forever. If the mutex
is of the "error checking" type, an attempt to apply a lock to a locked
mutex will return an error (rmMutexLock will return RM_WHACKED).

The node-level mutexes are completely optional, and use thereof is
up to the application. At this time (12/2/2000), the rendering
engine ignores mutexes at the RMnode. This behavior will likely 
change in the OpenRM that supports pipelined-parallel rendering.

6. Textures are now downloaded at render time. There is no way to
   cause textures to be downloaded prior to rendering.

The mutex objects used internally by OpenRM are also available
to applications. Apps may use the new RMmutex object for app
code synchronization, or (continue to) use custom sync mechanisms.
We chose the mutex because it is simpler than a semaphore, is
a POSIX standard, is quicker, and more closely fit our needs.

7. The following new API calls are present in v1.4-alpha-1:

	RMmutex * rmMutexNew(RMenum initLockState);
	RMenum    rmMutexDestroy(RMmutex *);
	RMenum    rmMutexLock(RMmutex *);
	RMenum    rmMutexUnlock(RMmutex *);
	RMenum    rmMutexTryLock(RMmutex *toQuery);

8. The demonstration programs (in rmdemo) were all updated to
compile and run with the v1.4-alpha-1 API, and will be incompatible
with previous releases of OpenRM.

9. Two new demonstration programs are included in rmdemo. "rm2screen"
implements multiple reader (rendering) threads, and "isodrv-mt"
implements multiple writer threads (a parallel isosurfacing demo).
	
	Note: rm2screen tickles a bug in the XFree86-4.01 + nVidia 0.9-5
	combination, and does not execute reliably. Other Linux
	combinations, such as XFree86-4.01 + Matrox G200, work great.
	We have tested rm2screen on several Linux platforms and under
	solaris, but not SGI.

"rm2screen" will open a total of 3 windows on a single display. The
first is a small "navigation" window, followed by two more 
unmanaged windows, placed side-by-side. Each of the unmanaged
windows uses a different view frustum, effectively simulating a
tiled surface display. When you rotate the object inside the
navigation window, the view is correspondingly updated in the
two tile windows. "rm2sceen" is merely an experiment, and is not
intended to be a general-purpose framework for doing tiled-surface
displays.

"isodrv-mt" will perform isosurfacing in parallel using 
multiple threads (to build a scene graph). The number of threads
defaults to 1, but may be changed on the command line. See the
HTML page for the demo programs for more details.

There are lots of pitfalls surrounding rm2screen, mostly pertaining
to Linux users. Please read the demo programs page carefully for
detailed information concerning where things can go wrong.
(http://openrm.sourceforge.net/docs/demoprogs.shtml)

10. To create isodrv-mt, changes were required to the RMV API for
rmvK3MarchingCubes(). New parameters include pointers for the
"base" of the coordinates and data. These pointers are passed along
to the "grid" and "data" callbacks supplied by the application, so
the callback API changes as well. These changes were required to
support applications assigning domain-decomposed portions of
the dataset to each separate execution thread.  It is likely that
the interfaces to the rest of the RMV routines will be similarly 
affected in upcoming releases.



11. Win32 Changes to Makefiles. Certain Unix-like commands were removed 
from the Win32 makefiles, and replaced with DOS equivalents (thanks to 
Ben D. for pointing this out).  The issue stems from the fact that all 
our Win32 development machines have GNU software installed, including 
all the familiar (to Unix-heads) commands like cp, mv, etc.

12. API change to rmImageResize. rmImageResize now takes an additional
parameter, an RMpipe. Hardware-accelerated image resizing is supported,
and the RMpipe parameter says which graphics pipe/context to use
for the resize operation.

13. Linux+XF86 (RedHat 7.0) font issues. Late in testing, we
discovered that the RM_FONT_DINGBATS font doesn't work properly
under RedHat 7.0 (XF86 4.01). Using the nVidia drivers, programs
that use RM_FONT_DINGBATS will crash. On other systems, no
DINGBATS text appears. We're investigating the cause of this problem
and hope to have the issue resolved in the next alpha release.
This issue affects previous releases of OpenRM; it's not specific
to the 1.4.0-alpha-1 release.




September 2, 2000 v1.3.0
------------------------

1. Documentation enhancements for scene parameters. All remaining 
   routines in $RM/rm/rmscene.c have been documented (whew!).

2. OpenRM compabitibility with the CAVELibrary (www.vrco.com).

   The fundamental change required to enable the use of OpenRM as
   the rendering engine within the CAVELibrary was to allow for
   existing values in the OpenGL matrix stack to be used during
   OpenRM rendering. To achieve this, a new attribute was added to
   the RMpipe, and it controls how the OpenGL matrix stack is 
   initialized at render time. Access to this new attribute is
   via these two methods:
   
   RMenum  rmPipeSetInitMatrixStackMode(RMpipe *toModify, RMenum newMode);
   RMenum  rmPipeGetInitMatrixStackMode(const RMpipe *toQuery);

   When newMode is set to RM_TRUE (the default), OpenRM will initialize
   the OpenGL matrix stack at render time. When set to RM_FALSE,
   OpenRM will use whatever values are in the matrix stack for rendering,
   but will concatenate transformations contained within the scene
   graph during rendering.

3. OpenRM + CAVELib demonstration programs.

   New demonstration program(s) that may be used on tiled surface
   displays with the CAVELibrary. These demo programs will appear in
   a new module to accompany the OpenRM distribution. A couple of
   cave.config files will be included.

4. Added RM_POLYS primitive - a collection of n-gons may be stored
   within a single primitive. Code supplied by Matt and Todd of VRCO
   (but not extensively tested at the time of this writing).

   Need additional documentation, along with a demo program, that show
   how to use this primitive.

5. Texture environment stuff added in rmframe - this wasn't being honored
	(bug) in previous version (vrco).

6. Linux users - the make.cfg file has been modified to assume that
   you have the OpenGL headers installed under /usr/include, and OpenGL
   libs installed under /usr/lib. Note that XFree86 version 4.0 and
   later include the Mesa distribution (libs and includes located under
   /usr/X11R6/[include, lib]). We do development using both software
   OpenGL (mesa) as well as with the nVidia drivers (libGL.so and
   libGLcore.so located in /usr/lib). By default, make.cfg in rm130
   assumes OpenGL is in /usr/lib and /usr/include. Similarly, the
   same directories are assumed defaults for rmdemo on Linux.

7. nVidia drivers for Linux. We have performed development and
   testing using XFree86 4.0.1 and the 0.9-4 drivers from nVidia.

8. Bounding Box computation code upgraded and overhauled.

9. RMAUX - replaced trackball model with Arcball, along with
   camera translation and dolly interfaces. All rmdemo programs
   updated to use this new model (thanks jdb for this code).

   Note the new default button/action mappings:
  
   RM_BUTTON2 (middle button) - arcball rotation
   RM_BUTTON1 (left button) - translate camera parallel to image plane
   RM_BUTTON3 (right button) - dolly camera along Z axis in eye coords
   SHIFT+RM_BUTTON2 (shift + middle) - isometric scaling.

   Some of the programs in RMDEMOS use button/action pairs in
   addition to this list. Check comments inside code for details.


4/27/2000 v1.2.1
---------------

1. Node traversal mask routines renamed to be consistent.

   rmNodeSetRenderpassOpacity() replaced by rmNodeSetTraversalMaskOpacity()
   rmNodeGetRenderpassOpacity() replaced by rmNodeGetTraversalMaskOpacity()

   rmNodeSetRenderpassDims() replaced with rmNodeSetTraversalMaskDims()
   rmNodeGetRenderpassDims() replaced with rmNodeSetTraversalMaskDims()

   rmNodeSetChannel() replaced with rmNodeSetTraversalMaskChannel()
   rmNodeGetChannel() replaced with rmNodeGetTraversalMaskChannel()

2. Routine and constant name changes:
   - rmNodeSetRenderMode replaced with rmNodeSetShader
   - rmNodeGetRenderMode replaced with rmNodeGetShader
   - RM_RENDERMODE_[SMOOTH,FLAT,NOLIGHT] replaced with
	RM_SHADER_[SMOOTH, FLAT, NOLIGHT]

   - rmNodeSetPolygonMode replaced with rmNodeSetPolygonDrawMode
   - rmNodeGetPolygonMode replaced with rmNodeSetPolygonDrawMode
   - rmNodeSetCullMode replaced with rmNodeSetPolygonCullMode
   - rmNodeGetCullMode replaced with rmNodeGetPolygonCullMode

   - rmNodeSetLinestyle replaced with rmNodeSetLineStyle
   - rmNodeGetLinestyle replaced with rmNodeGetLineStyle

   - rmNodeSetLinewidth replaced with rmNodeGetLineWidth
   - rmNodeGetLinestyle replaced with rmNodeGetLineStyle

3. Added lines2d.c in rmdemo. This program demonstrates the line width
   and line style attributes in RM.

4. Source code documentation for:
      - rmNodeGetShader/rmNodeSetShader() in rmnode.c.
      - rmNodeSetPolygonMode/rmNodeGetPolygonMode() in rmnode.c.
      - rmNodeSetPolygonCullMode()/rmNodeGetPolygonCullMode().
      - rmNodeSetFrontFace()/rmNodeGetFrontFace()
      - rmNodeSetLineStyle()/rmNodeGetLineStyle()
      - rmNodeSetLineWidth()/rmNodeGetLineWidth()
      - rmNodeSetPointSize()/rmNodeGetPointSize()
      - rmNodeSetNormalizeNormals()/rmNodeGetNormalizeNormals()

5. New render state access:
      - Polygon draw mode: rmStateGetPolygonMode()
      - Current shader: rmStateGetShader()
      - Polygon cull state: rmStateGetPolygonCullMode()
      - Polygon front face: rmStateGetFrontFace()
      - Current line style: rmStateGetLineStyle()
      - Current line width: rmStateGetLineWidth()
      - Current point size: rmStateGetPointSize()

6. Copyright assertions added to include/*.h

7. Problem with [rm,rmv,rmaux]/Makefile.w32 - the makes would fail
	if the dest libraries did not exist prior to building new
	ones. This was fixed by adding the "optional" character
	to the del command. EG,

	del $(RMLIB)/lib 
	is replaced with
	-del $(RMLIB)/lib

	Thanks to Paul Bleisch for this one.

8. Missing $RM/lib directory would cause problems with builds.
	This problem has been fixed for both Unix/Linux and Win32
	builds. All makefiles (Makefile.x11 and Makefile.w32) will 
	greedily mkdir $RM/lib.

9. Info: Extraneous warning message from Mesa on Linux. 
	An /etc/mesa.conf file appeared with RedHat 6.2. That conf file
	has an erroneous "mesa-3.1-beta" - when a glx context is
	created, a warning message is issued by Mesa. You can safely
	ignore that warning, or you can either hack on or move the
	/etc/mesa.conf file.

10: New make targets in $RM/Makefile
	The new "docs" target will cause HTML documentation to be
	generated directly from the source code. The resulting documentation
	is placed into $RM/doc/HTML. To view the docs with your browser,
	first cd to $RM, then launch "netscape ./doc/HTML/index.html."

	The new "cleandocs" target will remove all HTML docs from 
	the $RM source tree. You can always regenerate them using the
	"doc" target.

11. About the new nVidia driver & OpenGL - we've not had a chance yet
	to download and try it out. The existing comments about the
	alpha nVidia GLX/OpenGL driver stand for that version, your 
	mileage may vary with the newer version (released 4/25/2000).

12. With Mesa3.2, the first item listed under v1.2.0 remains an
	open bug.

13. Some versions of OpenGL, including Mesa3.2, do odd things when clipping
	n-gons. The trans2d program reveals this problem - drag the circles
	into a corner - each n-gon appears to be triangulized, and the
	gl polygon draw mode (GL_LINE) is applied to each triangle,
	rather than to edges of the new triangles that were a part of
	the original n-gon.

14. The trans2d demo program reveals an OpenGL bug on SGI iR2 systems.
	The circles should be rendered in a dashed line pattern, but
	appear as though rendered with a solid line pattern. Further
	investigation reveals that only on iR2 platforms, when the
	line segments of an n-gon drop below a certain threshold, the
	line stippling algorithm is defeated. Other SGI hardware appears
	to be unaffected.



1 March 2000 v1.2.0
------------

1. glGetError() reports an error when glRectv()'s are collapsed into
	 a display list under Mesa-3.1. A fix will be forthcoming.


2. nVidia OpenGL driver issues

   NOTE: The OpenRM project is not intended to provide support for
   h/w accelerated Linux/OpenGL problems. We are interested in 
   building and deploying h/w accelerated apps under Linux, and the
   information contained herein reflects our experiences and the 
   current state of OpenRM.

   - calling glIsTexture() will crash your X server. there is code inside
   OpenRM that will avoid calling glIsTexture() whenever OpenRM is built
   using Mesa, and a warning message is printed at runtime.

   - the routines glTexImage3D() and glTexSubImage3D() are *missing*
   from the nVidia libGL.so ! there is a file called t3dstubs.c included
   in the OpenRM demonstration programs distribution that you will have
   to compile by hand. Include t3dstubs.o on your link line,
   otherwise your programs will not run at all.

   - there is no h/w support for 3D texturing at this time.

   - multibuffered stereo display not tested on nVidia hardware.

3. Win32 issues
   - no support in Win32 OpenGL for 3D texturing.
   - W2K's OpenGL is unstable.

4. Thread safety
   At this time, OpenRM is not completely thread safe. See FUTUREPLANS.

--EOF--
Finally, we expect 1.4.0 FCS to become available upon the conclusion
of the Phase I SBIR effort - around 1 April 2001. Between now and
then, we will put out two more alpha releases. The next will contain
a preliminary implementation of pipelined-parallel rendering, and is
expected to become available in early January, 2001.




September 2, 2000 v1.3.0
------------------------

1. Documentation enhancements for scene parameters. All remaining 
   routines in $RM/rm/rmscene.c have been documented (whew!).

2. OpenRM compabitibility with the CAVELibrary (www.vrco.com).

   The fundamental change required to enable the use of OpenRM as
   the rendering engine within the CAVELibrary was to allow for
   existing values in the OpenGL matrix stack to be used during
   OpenRM rendering. To achieve this, a new attribute was added to
   the RMpipe, and it controls how the OpenGL matrix stack is 
   initialized at render time. Access to this new attribute is
   via these two methods:
   
   RMenum  rmPipeSetInitMatrixStackMode(RMpipe *toModify, RMenum newMode);
   RMenum  rmPipeGetInitMatrixStackMode(const RMpipe *toQuery);

   When newMode is set to RM_TRUE (the default), OpenRM will initialize
   the OpenGL matrix stack at render time. When set to RM_FALSE,
   OpenRM will use whatever values are in the matrix stack for rendering,
   but will concatenate transformations contained within the scene
   graph during rendering.

3. OpenRM + CAVELib demonstration programs.

   New demonstration program(s) that may be used on tiled surface
   displays with the CAVELibrary. These demo programs will appear in
   a new module to accompany the OpenRM distribution. A couple of
   cave.config files will be included.

4. Added RM_POLYS primitive - a collection of n-gons may be stored
   within a single primitive. Code supplied by Matt and Todd of VRCO
   (but not extensively tested at the time of this writing).

   Need additional documentation, along with a demo program, that show
   how to use this primitive.

5. Texture environment stuff added in rmframe - this wasn't being honored
	(bug) in previous version (vrco).

6. Linux users - the make.cfg file has been modified to assume that
   you have the OpenGL headers installed under /usr/include, and OpenGL
   libs installed under /usr/lib. Note that XFree86 version 4.0 and
   later include the Mesa distribution (libs and includes located under
   /usr/X11R6/[include, lib]). We do development using both software
   OpenGL (mesa) as well as with the nVidia drivers (libGL.so and
   libGLcore.so located in /usr/lib). By default, make.cfg in rm130
   assumes OpenGL is in /usr/lib and /usr/include. Similarly, the
   same directories are assumed defaults for rmdemo on Linux.

7. nVidia drivers for Linux. We have performed development and
   testing using XFree86 4.0.1 and the 0.9-4 drivers from nVidia.

8. Bounding Box computation code upgraded and overhauled.

9. RMAUX - replaced trackball model with Arcball, along with
   camera translation and dolly interfaces. All rmdemo programs
   updated to use this new model (thanks jdb for this code).

   Note the new default button/action mappings:
  
   RM_BUTTON2 (middle button) - arcball rotation
   RM_BUTTON1 (left button) - translate camera parallel to image plane
   RM_BUTTON3 (right button) - dolly camera along Z axis in eye coords
   SHIFT+RM_BUTTON2 (shift + middle) - isometric scaling.

   Some of the programs in RMDEMOS use button/action pairs in
   addition to this list. Check comments inside code for details.


4/27/2000 v1.2.1
---------------

1. Node traversal mask routines renamed to be consistent.

   rmNodeSetRenderpassOpacity() replaced by rmNodeSetTraversalMaskOpacity()
   rmNodeGetRenderpassOpacity() replaced by rmNodeGetTraversalMaskOpacity()

   rmNodeSetRenderpassDims() replaced with rmNodeSetTraversalMaskDims()
   rmNodeGetRenderpassDims() replaced with rmNodeSetTraversalMaskDims()

   rmNodeSetChannel() replaced with rmNodeSetTraversalMaskChannel()
   rmNodeGetChannel() replaced with rmNodeGetTraversalMaskChannel()

2. Routine and constant name changes:
   - rmNodeSetRenderMode replaced with rmNodeSetShader
   - rmNodeGetRenderMode replaced with rmNodeGetShader
   - RM_RENDERMODE_[SMOOTH,FLAT,NOLIGHT] replaced with
	RM_SHADER_[SMOOTH, FLAT, NOLIGHT]

   - rmNodeSetPolygonMode replaced with rmNodeSetPolygonDrawMode
   - rmNodeGetPolygonMode replaced with rmNodeSetPolygonDrawMode
   - rmNodeSetCullMode replaced with rmNodeSetPolygonCullMode
   - rmNodeGetCullMode replaced with rmNodeGetPolygonCullMode

   - rmNodeSetLinestyle replaced with rmNodeSetLineStyle
   - rmNodeGetLinestyle replaced with rmNodeGetLineStyle

   - rmNodeSetLinewidth replaced with rmNodeGetLineWidth
   - rmNodeGetLinestyle replaced with rmNodeGetLineStyle

3. Added lines2d.c in rmdemo. This program demonstrates the line width
   and line style attributes in RM.

4. Source code documentation for:
      - rmNodeGetShader/rmNodeSetShader() in rmnode.c.
      - rmNodeSetPolygonMode/rmNodeGetPolygonMode() in rmnode.c.
      - rmNodeSetPolygonCullMode()/rmNodeGetPolygonCullMode().
      - rmNodeSetFrontFace()/rmNodeGetFrontFace()
      - rmNodeSetLineStyle()/rmNodeGetLineStyle()
      - rmNodeSetLineWidth()/rmNodeGetLineWidth()
      - rmNodeSetPointSize()/rmNodeGetPointSize()
      - rmNodeSetNormalizeNormals()/rmNodeGetNormalizeNormals()

5. New render state access:
      - Polygon draw mode: rmStateGetPolygonMode()
      - Current shader: rmStateGetShader()
      - Polygon cull state: rmStateGetPolygonCullMode()
      - Polygon front face: rmStateGetFrontFace()
      - Current line style: rmStateGetLineStyle()
      - Current line width: rmStateGetLineWidth()
      - Current point size: rmStateGetPointSize()

6. Copyright assertions added to include/*.h

7. Problem with [rm,rmv,rmaux]/Makefile.w32 - the makes would fail
	if the dest libraries did not exist prior to building new
	ones. This was fixed by adding the "optional" character
	to the del command. EG,

	del $(RMLIB)/lib 
	is replaced with
	-del $(RMLIB)/lib

	Thanks to Paul Bleisch for this one.

8. Missing $RM/lib directory would cause problems with builds.
	This problem has been fixed for both Unix/Linux and Win32
	builds. All makefiles (Makefile.x11 and Makefile.w32) will 
	greedily mkdir $RM/lib.

9. Info: Extraneous warning message from Mesa on Linux. 
	An /etc/mesa.conf file appeared with RedHat 6.2. That conf file
	has an erroneous "mesa-3.1-beta" - when a glx context is
	created, a warning message is issued by Mesa. You can safely
	ignore that warning, or you can either hack on or move the
	/etc/mesa.conf file.

10: New make targets in $RM/Makefile
	The new "docs" target will cause HTML documentation to be
	generated directly from the source code. The resulting documentation
	is placed into $RM/doc/HTML. To view the docs with your browser,
	first cd to $RM, then launch "netscape ./doc/HTML/index.html."

	The new "cleandocs" target will remove all HTML docs from 
	the $RM source tree. You can always regenerate them using the
	"doc" target.

11. About the new nVidia driver & OpenGL - we've not had a chance yet
	to download and try it out. The existing comments about the
	alpha nVidia GLX/OpenGL driver stand for that version, your 
	mileage may vary with the newer version (released 4/25/2000).

12. With Mesa3.2, the first item listed under v1.2.0 remains an
	open bug.

13. Some versions of OpenGL, including Mesa3.2, do odd things when clipping
	n-gons. The trans2d program reveals this problem - drag the circles
	into a corner - each n-gon appears to be triangulized, and the
	gl polygon draw mode (GL_LINE) is applied to each triangle,
	rather than to edges of the new triangles that were a part of
	the original n-gon.

14. The trans2d demo program reveals an OpenGL bug on SGI iR2 systems.
	The circles should be rendered in a dashed line pattern, but
	appear as though rendered with a solid line pattern. Further
	investigation reveals that only on iR2 platforms, when the
	line segments of an n-gon drop below a certain threshold, the
	line stippling algorithm is defeated. Other SGI hardware appears
	to be unaffected.



1 March 2000 v1.2.0
------------

1. glGetError() reports an error when glRectv()'s are collapsed into
	 a display list under Mesa-3.1. A fix will be forthcoming.


2. nVidia OpenGL driver issues

   NOTE: The OpenRM project is not intended to provide support for
   h/w accelerated Linux/OpenGL problems. We are interested in 
   building and deploying h/w accelerated apps under Linux, and the
   information contained herein reflects our experiences and the 
   current state of OpenRM.

   - calling glIsTexture() will crash your X server. there is code inside
   OpenRM that will avoid calling glIsTexture() whenever OpenRM is built
   using Mesa, and a warning message is printed at runtime.

   - the routines glTexImage3D() and glTexSubImage3D() are *missing*
   from the nVidia libGL.so ! there is a file called t3dstubs.c included
   in the OpenRM demonstration programs distribution that you will have
   to compile by hand. Include t3dstubs.o on your link line,
   otherwise your programs will not run at all.

   - there is no h/w support for 3D texturing at this time.

   - multibuffered stereo display not tested on nVidia hardware.

3. Win32 issues
   - no support in Win32 OpenGL for 3D texturing.
   - W2K's OpenGL is unstable.

4. Thread safety
   At this time, OpenRM is not completely thread safe. See FUTUREPLANS.

--EOF--
