# $Id: OLD-RELEASENOTES,v 1.4 2005/05/16 02:02:48 wes Exp $ # $Revision: 1.4 $ # $Log: OLD-RELEASENOTES,v $ # Revision 1.4 2005/05/16 02:02:48 wes # Updates for 1.6.0. # # 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. # # April 18 2004, v1.5.2 --------------------- New Features and API Changes in v1.5.2 -------------------------------------- 1. Addition of several new indexed primitive types. These include: - RM_INDEXED_QUADS - RM_INDEXED_TRIANGLES - RM_INDEXED_TRIANGLE_STRIP - RM_INDEXED_TRIANGLES - RM_INDEXED_TRIANGLE_STRIP 2. Addition of the (long overdue) RM_QUAD_STRIP primitive. 3. New API routine: int rmPipeGetFrameNumber(const RMpipe *) Returns an integer value that is incremented each time you call rmFrame on a given RMpipe. 4. New API routine: RMenum rmNodeRemoveAllPrims(RMnode *toModify) Will remove all RMprimitives from an RMnode in one call. 5. Minor code enhancements (thanks to D. Bunzli for suggesting them) - rmVismapDup - added check for NULL from rmVismapNew, report failure with rmError is one occurs and return NULL. - rmCamera3DNew - added a call to rmDefaultCamera3D so that all fields are initialized to valid values. 6. new RMdemo program named indexedPrims2D that exercises each of the above new indexed primitive types. 7. Updated the RMdemo program tfly to be much more visually appealing and to test the new RM_QUAD_STRIP primitive. 8. New Gordo demo program "lightModes" that exercises the light attenuation parameter, as well as exercising lots of other lighting parameters. 9. Support for additional build targets: - linux-x86_64, linux_x86-64_debug - linux-x86_32, linux_x64-32_debug Note: linux-x86_32 is the 32-bit ABI on 64-bit Linux distros. 10. Extensive overhaul of the RMdemo configure script to support builds on all currently supported platforms. - old -irixarch command-line arg replaced with -abi=[] arg. - new -abi=[] command line argument to select ABIs. Valid arguments to -abi are -abi=irix6-32 -abi=irix6-n32-mips3 -abi=irix6-n32-mips4 -abi=irix6-64 -abi=linux-x86_64 -abi=linux-x86_32 11. Irix builds: tweaked CFLAGS flags on irix to ignore more warnings - disabled warnings about variables declared but never used. 12. RM core builds - addition of a "make install" target. - Addition of "install" target. Default location is /usr/local/rm152. If you want to do an install somewhere else, edit $RM/Makefile and change INSTALL_DIR=/usr/local/rm152 to the desired value. The install target will copy over libs, headers and documentation. Bugs Fixed in v1.5.2 -------------------- 1. Repaired and tested MacOSX-X11 build targets. Both RM and RMdemo were compiled and tested on MacOSX-X11 for 1.5.2. 2. In-code documentation repairs (thanks to D. Bunzli for pointing them out) - rmiWriteJPEG() - fixed manpage documentation errors. - rmauxDefaultKeyFunc() - fixed manpage documentation errors. - rmVismapGetSize() - updated documentation. - rmVismapGetAlpha() - corrected documentation. - rmFinish() - fixed manpage documentation errors. 3. Lighting environment enhancement - activated the light attenuation parameter. Previously, you could modify the light attenuation, but the parameter setting was not honored during rendering. 4. Constant-rate rendering buglet - specifying a small number of frames per second, like one frame per second, would result in some incorrect and erratic frame timing. This issue has been fixed. Known Bugs ---------- 1. It is possible to overflow texture memory by using a texture that doesn't fit into memory. This condition will silently produce an error. 2. The tfly RMdemo doesn't propogate new window dimensions to the static "fly struct" inside rmauxFlyUI. Therefore, if you resize the window after the application starts, the resulting display will be incorrect. One approach is to create a new rmauxFlyResize function that fixes the camera and the cached window geometry dims. 3. nVidia drivers. The most recent batch of nVidia drivers - 1.0-53.36 released in Jan 2004 - 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.36 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. 4. We have not attempted to test the multibuffered stereo OpenGL context creation code on Windoze platforms. ToDo in 1.6.0: -------------- The next version will be 1.6.0 due to some expected small but noticeable changes to the API. - cleanse API for easier error detection. E.g., rmVismapGetAlpha returns a float value even if there's an error. It would be better to unify the return values from routines so that all return RM_CHILL on success or RM_WHACKED on failure. - change API on loader functions to use a fd rather than a filename (thanks to D. Bunzli for the excellent suggestion) - Fix problem where window resize in tfly doesn't propogate new window dims to the static fly struct inside rmauxFlyUI. One approach is to create a new rmauxFlyResize function that fixes the camera and the cached window geometry dims. - There has been a request for multitexturing support. - The callbacks attached to RMpipes should include an RMpipe * as part of the callback parameter list. - GLUT+RM demonstration programs and chapter in the RM Programming Guide. 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--