# $Id: OLD-RELEASENOTES,v 1.3 2004/04/18 21:37:02 wes Exp $
# $Revision: 1.3 $
# $Log: OLD-RELEASENOTES,v $
# Revision 1.3  2004/04/18 21:37:02  wes
# Updated for 1.5.2
#
# Revision 1.2  2004/01/17 04:00:07  wes
# Migrated v1.5.0 releasenotes into this file.
#
# Revision 1.1  2003/02/07 14:49:01  wes
# Initial Entry. The RELEASENOTES file was becoming too large, so we've
# partitioned the information into two files.
#
#

January 2004, v1.5.1
--------------------

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

1. Constant-rate, or bounded-rate rendering. Using the new routine
rmPipeSetFrameRate(), you can specify a frames-per-second attribute 
on an RMpipe. The resulting renderings in freely-running applications
will occur at regular time intervals, and no frequently than the frames-per-
second value specific. There are some limits in terms of performance
and accuracy - please refer to the OpenRM Programming Guide for
additional details. This capability was tested on Unix/Linux/Win32 and
it works well on all platforms.

2. Increased pickable limits. In 1.5.1, the new limits are now: 512K nodes, 
128 prims per node. In addition, internal code was rewritten to not build
serial structures that would grow in size in proportion to the size of
the scene graph. Picking is not performed in nearly constant time, and
is no longer related to the size of the scene graph except for the time
required to do rendering.

3. Added support for auto-spin mode. Use rmauxSetSpinEnable(RM_TRUE)
to enable automatic spinning. Spin mode uses the target set by 
rmauxSetGeomTransform(). Spin mode enabled for the following RMdemo 
programs: elev, fpsVis3d, and vis3d. The basic idea is that you can
"fling" an object using the RMAUX interactive transformations, and the
object will spin on its own.

4. Platform-independent access to the OpenGL context. Now, you will only
use the platform-neutral routines rmPipeSetContext and rmPipeGetContext. 
The routine rmxPipeSetContext was changed changed to rmPipeSetContext 
(rmx.c). Added a windows version of rmPipeSetContext (rmwin.c).

5. Improved error detection and reporting in rmText.


6. added -p flag to spriteTest demo to allow testing of picking of
large numbers of objects.

7. rmvJ3ComputeMeshNormals - added a flipNormalsBool parameter.
8. rmvJ3MeshSurface - added a flipNormalsBool parameter
9. rmvJ3ScatterPoint - added a flipNormalsBool parameter
10. added -flip command line argument to vis3d to enable normal-flipping
when generating either a surface mesh (-v 0) or scatter points (-v 8).


11. new demo: fpsVis3d - like vis3d, but only generates a surface mesh. will
rotate the object about the y-axis, and generate fps values integrated over
5 second intervals. Can take a command-line argument that specifies
desired frames per second. The fps values this program generates were
used in testing the accuracy of the constant-rate rendering stuff.

12. New command line argument to the spriteTest program to permit picking,
and to report elapsed time. The new argument is "-p" and it will enable
picking and picking time measurement and reporting.

13. Implemented shared textures. Now, when you assign an RMtexture as a
scene parameter using rmNodeSetSceneTexture, you must not try to delete
the RMtexture; rmNodeSetSceneTexture now just copies the RMtexture pointer
into the RMnode rather than making a copy of the RMtexture. Attempting
to delete an RMtexture that is assigned as a scene parameter to any 
RMnode will fail. With this change, you can use a single instanced RMtexture
at an arbitrary number of scene graph nodes, and there will only be one
OpenGL texture object in use. This feature is best considered a bug fix
rather than a new feature.

14. Modified the textureTest demo to permit creation of an arbitrary
number of textures. Use the "-nt NN" argument to specify the number
of textures generated by the program.

15. Support for FreeBSD. Added build targets and mklib script for 
FreeBSD. Thanks to Igor Pokrovsky for the contribution.

16. Time measurement and manipulation routines. To support constant-rate 
rendering, we implemented a family of rmTime* routines in the rm/rmtime.c 
file. These do things like get the current time, time conversions, time 
object manipulation and implement a high resolution sleep routine.

Bugs Fixed in v1.5.1
--------------------

1. Texture coordinates tweakage in the rmOctmesh rendering function
to avoid rendering bugs encountered on nVidia hardware when using
GL_LINEAR texture interpolation on 3D textures. We need to take
another look at these changes to make sure that (1) they are implemented
on all axes of the octmesh, and (2) that things work OK in a variety
of resolutions and view angles.

2. Fixed buglet in rmNodeGetSceneLight that would result in a segfault
in some circumstances - when requesting an RM_LIGHT* that didn't exist.

3. Octmeshes - added a small epsilon to texture coordinates when rendering
octmeshes to fix an OpenGL rendering (nvidia drivers) buglet that appeared 
when rendering multiple, adjacent octmeshes using the GL_LINEAR texture
filtering mode. This buglet was visible in the Chromium demonstration
programs.

Known Bugs
----------

1. nVidia drivers. The most recent batch of nVidia drivers - 1.0-53.28 
released in Dec 2003 - contain fixes for a number of long standing bugs.
With these drivers, offscreen rendering works (it does the right thing
and won't crash your X server), and the rm2screen demo will exit cleanly
as it should. That's the good news. The bad news is that the 53.28
drivers cause Chromium to crash. Specifically, the psubmit demo crashes.
Since the OpenRM+Chromium demo programs use a similar initialization
sequence, they too will prematurely die. The workaround is to use the
44.96 nVidia drivers for Chromium, and for Chromium+OpenRM.

2. We have not attempted to test the multibuffered stereo OpenGL
context creation code on Windoze platforms.


April 2003, v1.5.0
------------------

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

1. New controls over use of display lists. The new routine
rmPipeSetDisplayListEnable() can be used to control whether or not OpenGL
display lists are used at the RMpipe level. By default, OpenRM will use
display lists, unless instructed to not do so. Use rmPipeGetDisplayListEnable()
to obtain the value of the display list usage parameter at an RMpipe. The
corresponding routine to control use of display lists is used at
the RMprimitive level: rmPrimitiveSetDisplayListEnable(). This routine has
been a part of the API for many revisions, but is now fully operational
(see Fixed Bugs, below). Therefore, you can control generation of OpenGL
display lists for all RMprimitives by making an adjustment at the RMpipe
level, or only at the RMprimitive level.

2. Support for distributed memory rendering using Chromium. 
   a. rmPipeSetCommSize/rmPipeGetCommSize - to set/get the collective size;
   b. rmPipeSetRank/rmPipeGetRank - to set/get the PE rank;
   c. Changes to RMpipe initialization sequence (see below).
   d. rmPipeBarrierCreateCR(), rmPipeBarrierExecCR().

3. New (consistent) behavior for use of RMvisMap in association with
RMimage data. The visualization colormap is used to activate OpenGL
pixel transfer when pixel data transits the OpenGL pipeline. The scope
includes sprites, textures and glDrawPixels calls.

4. RMpipe initialization and API changes.
	deprecated: rmPipeInit, rmInitPipeUsingDisplay
	All applications must now use rmPipeNew().

5. Removed a bunch of unused routines: rmxVisualGetBest

6. New routines for RMprimitive bounding boxes. rmPrimitiveComputeBoundingBox,
rmPrimitiveSetBoundingBox, rmPrimitiveGetBoundingBox.

7. rmMutexDestroy renamed to rmMutexDelete for API consistency.

8. rmNodeMutexDestroy renamed to rmNodeMutexDelete for API consistency.

9. rmImageResize is now operational for 3D images using RM_SOFTWARE.


Bugs Fixed in v1.5.0
--------------------

1. RMV library - isosurface code. Found and fixed a problem in which the 
z-size of the grid wasn't being properly reported to the application-supplied 
grid or data callbacks.

2. RM library - rmPrimitiveSetText() memory leak - fixed.

3. RM library - rmPrimitiveDisplayListEnable() doesn't have an effect upon 
whether or not display lists are generated - fixed. RM would always build 
display lists, regardless of application requests to inhibit display list use 
at a given RMprimitive.

4. RM library - Only the first string in a multi-string RM_TEXT RMprimitive 
would be rendered correctly using the governing text properties set via 
rmNodeSetSceneTextProps(). This problem has been fixed; all text strings
in an RMprimitive are now rendered using the correct text properties.

5. RM library - texturing environment manipulation improvements. 

6. RM library - fixed memory leak: mutexes created in 
private_rmInitComponentManager() were not released when rmFinish()
was callled.

7. RM library - fixed memory leak: RMstates created by rmSceneGraphWalk and
private_rmSceneGraphWalk are now released when those routines finish.

8. RM library - fixed memory leak: the fbClear structure was not freed
during rmNodeDelete().

9. RM library - logic error fixed: node and primitive mutexes were not
unlocked inside rmNodeRemoveChild and rmNodeAddPrimitive when error
conditions were encountered. 

10. RM library - memory leak fixed: the displayLists field of the RMpipe,
which contains data structures used to communicate results between the
view and render traversals (NOT OpenGL display lists) were not released
when the RMpipe is deleted.

11. RM Library - bug in rmNodeComputeBoundingBox fixed that would cause
an occasional bogus bounding box to be generated, depending upon range
of values of input vertices.

12. RM Library - rmClipPlaneSetPointNormal was always returning RM_WHACKED.
(Thanks to A. Yarnos for reporting this problem)

13. RM Library - lighting test buglet fixed in private_rmNodeComputeAttribMask.
(Thanks to A. Yarnos for reporting the problem)


Known Bugs
----------

1. Offscreen rendering and the nVidia Linux OpenGL drivers. The 49.63
nvidia Linux OpenGL drivers have a bug where things encapsulated into
display lists are not actually drawn into GLX pixmaps. The problem was
reported to nvidia several months ago (December 2002), and has existed
for the past couple of driver revisions. The workaround is to use
rmPipeSetDisplayListEnable(p, RM_FALSE) on your RMpipe to turn off
display lists when rendering to offscreen pixmaps.

2. We have not attempted to test the multibuffered stereo OpenGL
context creation code on Windoze platforms.

3. We observed lots of minor problems with Sun's OpenGL for their
new Zulu platform. Unfortunately, the specific list of problems was
rm -rf'd before we could copy contents into this file. I do recall that
elevImage.c was broken in such a way that indicates a problem with
floating point pixel data in the OpenGL pixel pipeline. Solaris OpenGL
on other platforms (FFB3) was OK.



September 22, 2002 v1.4.3
-------------------------

New Features in v1.4.3
----------------------

1. The RM component manager and context cache code have been updated
to support an arbitrary number of objects, limited only by the amount
of RAM and swap you have on your machine. This new feature is brought
to you courtesy of the US Deptartment of Energy via SBIR contract
number DE-FG03-02ER83443. Thanks to Uncle Sam, and please pay your taxes!

2. A new routine: rmComponentManagerPrintStatus(). Will display, using
rmNotice(), the current alloc/free status of the object pools managed
by the component manager. Use this routine to help track down memory
leaks in your application.

3. A new callback routine: rmNodeSetRenderOrderCallback(). This routine
is a cousin to rmNodeSetSwitchCallback() in that it is used to alter
the traversal order of an RMnode's children during the view traversal.
Whereas the switch callback will traverse one and only one child, the
render order callback will allow the application to define the order
in which an RMnode's children are traversed. It is possible to traverse
any number of an RMnode's children, and in any order. It may be possible
to perform perversions such as repeated traversal of a single child, but
we've not tried this out. It is an error to set both a switch and a
render order callback; RM will prevent your appliction from attempting
to set both a switch and render order callback.

Bugs Fixed in v1.4.3
--------------------

1. Added in code that will invoke application-supplied pre- and post-
traversal callbacks during the render traversal. Previous to 1.4.3,
only the view-stage traversal callbacks were honored. See the
documentation for rmNodeSetPreTraversalCallback() and
rmNodeSetPostTraversalCallback(). 

2. Previous to v1.4.3, if the view-stage pre-traversal callback
returned a status <= 0, the view-stage post-traversal callback, if
present, was also invoked. This behavior has been changed - when
the pre-traversal callback returns a status of <= 0, further
processing at that node terminates, and the post-traversal callback,
if present, will NOT be invoked.

3. rmPipeInit will return RM_WHACKED if it can't find the requested visual
type on the the display (e.g, multibuffered stereo). Previously, it
always returned RM_CHILL, even if it was unable to find the requested
visual type (X11) or pixel format (Win32).

4. rmPrimitiveSetVertex3D (and related routines) would mistakenly return
RM_WHACKED even when they succeeded. This has been fixed so they return
RM_CHILL when they success, and RM_WHACKED when they fail.

5. Win32 builds. Use the new win-32-static target to build static LIBs, and
the win-32-dynamic target to build dynamic DLLs. The old win-32 target
will no longer work. DLLs under Win32 last worked in RM v1.3.1; they
are now back!


Known Bugs in v1.4.3
--------------------

1. The return value from the RM_RENDER pre-traversal callback is
presently ignored. This means that it is not possible to perform
early termination with the pre-traversal callback during the render
traversal. Early termination should be performed during the view
traversal. This bug will likely not be fixed in future releases.

2. We have not tried out stereo pixel formats on Win32.

3. The isodrv and isodrv-mt programs reveal buglets in the 31.23
OpenGL drivers from nVidia for Linux. There is a problem in which
large display lists become corrupted, and in some cases, a segfault
occurs deep inside the nVidia driver. nVidia has been notified of
the problem. The workaround is to either use the 29.60 drivers
(May 2002) or turn of display lists completely by changing #define DO_LISTS 1
to #define DO_LISTS 0 inside rm143/rm/rmprivat.h, and rebuilding
the 1.4.3 distribution. This problem does not appear in the 30.82
nVidia drivers for Windows (Aug 2002).


Changes to the RMdemo distribution beween 1.4.2 and 1.4.3
---------------------------------------------------------

1. New RMdemo program: orderTest. The orderTest demo program is used
to exercise the new rmNodeSetRenderOrderCallback. This program is
a variant of the pntcld.c RMdemo in that it generates a bunch of
point RMprimitives positioned at random locations on the surface of
a sphere. The orderTest demo renders all the point primitives during
the transparent 3D rendering pass, and uses the render order callback
to sort the primitives in back-to-front order so that they are
rendered correctly.

2. New RMdemo program: textureTest. The textureTest demo program is
a stress test for the RMtexture object reallocating code in the
component manager and the context cache. Refer to the Demo Programs
documentation page for more information.

3. New RMdemo program: spriteTest. The spriteTest demo program is a 
stress test for the RMimage object reallocating code in the
component manager and the context cache. Refer to the Demo Programs
documentation page for more information.

4. Modified cones.c. Cones will first attempt to create an RMpipe using
a multibuffered stereo visual. If that fails, it will fall back to
red/blue anaglyph for rendering. 1




June 16, 2002 v1.4.2
--------------------

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

1. Texture state management. The internal texture management code
was retooled so that textures are downloaded during the render
traversal. Previously, textures were downloaded immediately when
set by an application call to rmNodeSetSceneTexture(). The internals
now detect if an entirely new texture is being set at the scene
graph node, in which case glTexImage*D is used to build a new
texture. If only the texture image data is being updated, then
glTexSubImage*D is used instead. Note that there may be the possibility
for error if the new images are not the same size as the old
ones. Error checking code will need to be added in a future version
of the code. For now, it is up to the application to ensure consistent
sizes of images - the size of the new texture images must be no
larger than the size of the old images, otherwise an error condition
may result. There are no API changes at the application level
that result from this code improvement.

2. New RMdemo program: dyntmap. This new demo program exercises
the new texture management code. It creates a single quad geometry
object that uses a 2D texture to show slices of volumetric data.
The program loops over slices of volume data, uploading a new
texture for each slice of volume data. The result is a "movie"
or animation.

3. Added support for non-byte texture data in 3D textures. 3D textures
may now be RM_FLOAT, RM_SHORT, etc. There are no API changes at
the application level that result from this code improvement.
This fixes a bug previously reported in which floating point texture
data was not working in 3D textures.

4. Added key handler code to Win32 event loop, along with new
keyfunc.c in rmdemo to use for testing.

5.  rmImageSetVismap will now take NULL as an input parameter for the
vismap. This will allow applications to "clear" the vismap associated
with an RMimage object. This change fixes a bug in which memory
is leaked by rmImageDelete on RMimages that contain visualization colormaps.
There are no API changes at the application level that result from
this code addition.

6. OpenGL state change consolidation and streamlining. Has resulted in
a 10x performance boost on some platforms, will most benefit those
apps that have large numbers of nodes and primitives in the scene graph.

7. Increased the effective amount of space available for use in the
view-render traversal pipeline for matrices and draw opcodes by tying
the amount of space allocated to the maximum number of components
managed by the component manager. This change fixes the symptom, but
does not address the underlying issue, which is that either (1) we need
to figure out how much space is needed for these things (or an upper
bound given a scene graph), or (2) write realloc code. The former is
better, the latter will be slower.

8. Fixed a bug whereby the "unlit color" was not properly surviving
a state push/pop. The unlit color at a node affects the diffuse
material property, as well as setting the current RGBA color. By
changing the mask from GL_CURRENT_BIT, which captures the current
color, to GL_CURRENT_BIT | GL_LIGHTING_BIT, both the current RGBA
color as well as current material colors are captured. This bug
was revealed by the "pickTest" demo.

9. Removed the routines rmFrame_NEW() and rmSubtreeFrame() from
rmpublic.h and from the code base. All applications should now 
use rmFrame() exclusively to invoke the renderer.

10. The RMpick object returned from rmFramePick() MUST NOW BE FREED
after use. In 1.4.1 and earlier, rmFramePick() returned a pointer to
a static hunk of memory. Now, it uses dynamic allocation.

11. Use rmPickDelete() to release the RMpick object(s) returned by
rmFramePick() and rmFramePickList(). rmPickDelete() replaces
rmPickListDelete(), which is no longer in the code base.

12. The internal code that serializes object picking has ben modified
so that it no longer has a fixed size. Now, you can pick objects
from within a scene graph of an almost arbitrary size. The limit is
the lesser of (a) the maximum number of allowable scene graph nodes
and primitives as defined in include/rm/rmcmpmgr.h by the
RM_COMPONENT_POOL_SIZE constant, and 8192 nodes or 128 primitives
per node. Note that 8192 nodes and 128 prims per node applies
only to picking. You can have scene graphs larger than that if
you want.

13. The number of unique objects that may be picked has been 
increased. The new limits are 8192 nodes and 128 primitives per
node. These limits are related to object serialization and
picking uniqueness, not size of the scene graph. If you exceed
these limits, the node and primitive info returned by the pick
will not be correct: if you have 8193 nodes and do a pick, the
pick will correctly detect the intersection with node 8193, but
will return node 1, not node 8193.

14. Fixed a numerical bug that resulted in picking errors for
RMprimitives of type RM_TEXT, RM_BITMAP and RM_SPRITE.

15. Changed RM_COMPONENT_POOL_SIZE from 1024 to 2048 to accomodate
larger scene graph models.



Changes to the RMdemo Distribution between v1.4.1 and v1.4.2
------------------------------------------------------------

1. Dyntmap.c - described above, exercises the new code for texture
state management.

2. keycunc.c - new demo that exercises the key handling callbacks
added to RMaux in Win32.

3. Several rmdemos have a new command line parameter "-s" that will
cause rendering timing information to be measured and printed to
stderr. The rmdemos so affected are: clrball, isodrv, isodrv-mt, jack,
pdb, pntcld, spotlight, tfly.

4. The tfly demo takes a new parameter "-n NNN" that will control
the number of cylinders generated by the demo application. By default,
tfly will generate on the order of 100 cylinders.  Substitute an
integer in place of "NNN" above. At this time (June 2002), the value
of NNN must be less than the maximum number of allowable scene
graph nodes, which is controlled by a constant called 
RM_COMPONENT_POOL_SIZE that is located in rm142/include/rm/rmcmpmgr.h.

5. pickTest.c and pickListTest.c - these two new demo programs exercise
picking. Each creates a cloud of objects, and places them on the surface
of a 3D ellipsoid. Each object consists of a sphere and some text.
When you pick an object, it turns yellow. pickTest uses rmFramePick to
select the object closest to the viewer. pickListTest uses rmFramePickList
to discover all objects that intersect a given (x,y) pixel location,
prints the entire list to stdout, then changes the color of the
frontmost object to yellow.

6. elevImage.c - demonstration of use of Visualization Colormaps and
pixel scale/bias in RMimage objects using digital elevation data as
the input source.

Known Bugs in v1.4.2
--------------------

1. Limited number of objects - defined by limits in rmcmpmgr.h.

2. Not all types of objects are frame-accurate in multistage rendering.
Only transformations are copied/duplicated. This shortcoming affects
only the parallel rendering modes of RM_PIPE_MULTISTAGE_PARALLEL and
RM_PIPE_MULTISTAGE_VIEW_PARALLEL.


October 14, 2001 v1.4.1
-----------------------

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

There have been no changes to the OpenRM API between 1.4.0 and 1.4.1.
There has been the addition of a new routine (rmPipeSetOffscreenWindow)
and a minor change in the behavior of an RMaux routine. There have been
a significant number of bugs fixed in the 1.4.1 release, and improvements
in behavior of existing routines.

1. RM: rmPipeSetOffscreenWindow() is used to assign an offscreen drawable.
This new routine is a sibling to rmPipeSetWindow, which assigns a
viewable window handle to an RMpipe. This routine was added because:

2. RM: rmPipeDelete() will now close its associated window, and free its
associated OpenGL rendering context, context cache, and other
data structures.

3. Fixed $RM141/Makefile so that win-32-clean target does 
"the right thing" for the rmi directory (does "clean" now rather than 
"win32"). Modified Makefile.w32 in each directory so that more files 
were deleted during clean and pristine targets.

4. RM: rmImageMirror() now works for both horizontal & vertical mirroring
of 2D images. No support exists at this time for 3D images. 

5. New RMdemo program: fogtest. This program exercises OpenGL fogging,
using a combination of surface geometry, vectors, bitmaps and sprites.
Unfortunately, not all OpenGL implementations do "the right thing"
when fogging bitmaps and image data. See "Fogging" in Known Bugs in 1.4.1
(below) for more information about our testing results.

6. RM: OpenRM 1.4.1 implements some under-the-hood cleanup of retained
mode structures (display lists, texture objects). The cleanup code
is "lazy", and is not executed immediately. All retained mode structures
are owned by the context cache, and access to them is mediated by
the component manager. Taking RMprimitives as an example, the
display list inside the context cache associated with that RMprimitive
is not actually freed inside OpenGL until two things happen: 1) 
that RMprimitive is realloced off the component manager free list,
and 2) that RMprimitive is rendered. A similar strategy is used for
other retained mode structures: textures, textprops, etc.

7. RMaux: The return status of the idle function will now affect exit from
the event loop. Non-zero return values continue execution of the
event loop; a zero return value will terminate execution.

8. Win32: Pthreads for Win32.

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

1. RM: Added src for a fake_gluScaleImage to be used by rmImageResize.
We encountered problems with gluScaleImage in version 3.5 of Mesa
in which output pixels were not in the same range as input pixels
when the images were of the same type. Instead, they were 
normalized.

2. RM: rmTextProps internals changes - some older code still used
malloc/free, when it should have been using component manager
constructs. This fix was prompted by bugs in programs that make
extensive use of text properties changes over the lifetime of
the program. The bug that showed up was an occasional failure for
the new text properties to take effect.

2. Win32: crashes on Win98 & ME resulting from PeekMessage call
during WM_MOVE mouse events. PeekMessage does not crash WinNT or 2K
systems. It does appear to occasionally crash 98, 95 and ME systems.
The purpose of that code block was to remove WM_MOUSEMOVE events
that had been queued up during lengthy rendering operations.

3. Win32: crashes during minimization of rendering window. This
resulted because Win32 generates a window resize event whenever
you minimize the window. The size of the new window is (0,0), and
the default response callback (rmauxDefaultResizeFunc) will attempt
to reset the aspect ratio, which in turn produced a divide-by-zero
error. 

4. RM: Fixed bug in private_rmDCFromWC2(), affects display of sprite primitives.

5. RMaux: Added button4 and button5 - these are defined as part of X,
and this stuff was added in response to user reports of crashes
when the wheel  on a wheel-enabled mouse was twiddled. The wheel
appears to map to button5, and the default behavior for buttons
is rmauxEventNoOp. Buttons 4 and 5 can have callbacks attached
with rmauxSetButtonDownFunc(), etc.

Known Bugs in 1.4.1
-------------------

1. Button5 and Button6 don't have any direct representation in
Win32. The RMaux event loop, in Win32, only knows about buttons 1-3.

2. Fogging - the fogtest demo reveals bugs in how many OpenGL
implemenations fog image data, specifically bitmap and pixel data.
In the table below, we list our test platforms, and whether or
not the fogtest demo was free of errors. If a platform is not
listed, we have no information about whether or not the fogtest
demo works:

Results		Platform + OpenGL version or driver
---------------------------------------------------
OK		WinNT 4SP6a, nVidia Detonator 6.5
?OK		WinNT, generic implementation
?OK		Win98, nVidia Detonator 6.5
?OK		WinME, generic

?OK		Unix, Mesa 3.5
OK		Irix 6.5

Fail		Linux, nVidia 1251 OpenGL drivers
Fail		Solaris, OpenGL 1.2.2



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