GEM ONLINE DOCUMENTATION CHAPTER 5: RELEASE NOTES

---------------------------------------------------------------
---------------------------- 0.74 -----------------------------
I replaced the images in the example directory with JPGs.  They
are alot smaller.  However, in gemMoveImages.pd, you can see
the effect that the compression has.  Look at the red dancer. All
of the "black" should be alpha masked out, yet there are little
bits which get all jaggy.

Got gltt-1.8  Looks like it fixes a bunch of bugs.

Finally put an alpha test into the alpha object.  This means that
if the alpha of a pixel == 0., then it won't be put written into
the frame buffer.  Look at the example file gemMoveImages.pd for
an example of this.  Notice that the dancer is texture mapped to
a sphere, yet you can always see her correctly.  You can disable
this behavior by sending a 'test 0' to the alpha object.

Oh boy, were my texture coordinates off.  Unknown to me, my reference
image (dancer.tif) was actually upside down.  This meant that all
of the texture coordinates in the Geos objects were compensating
for the rotation.  Sorry if this messes anyone up, but it is now
correct for all of the geos.

I also now load in images in OpenGL format.  This means that
data[0][0] == lower-left corner.  This shouldn't have any effect
on anyone unless you are doing position sensitive image processing.

Fixed the orientation problem when using pix_draw.

imageVert handles gray8 pixes

Fixed a problem if pix_multiimage loaded in images that were different
formats or sizes.

GEM supports search paths!  Basically, GEM will look for auxiliary
files (images, models, fonts, etc.) from whatever directory the
patch is in (unless you use an absolute path name with '/').

---------------------------------------------------------------
---------------------------- 0.73 -----------------------------
Fixed profiling on Unix

Added text2d, text3d, textoutline.  The text objects will render
a truetype font (I have provided a couple fonts in gem/examples).
text2d renders a flat bitmap...no rotation or Z movement.  text3d is
full polygonal text, so you can translate and rotate.  textoutline
is also polygonal, it is just a vectored outline.
    PS text2d has some problems...

JPEG and SGI image file formats are supported!  Depending on the number
of color components, GEM will automatically convert them to grayscale
or RGBA (just like TIFF files).

pix_video is working slightly on WinNT.  There are still some
serious problems, so consider this version a complete pre-alpha.  I'm
releasing a version now to find out if it even works on other systems.
I am using a Connectix QuickCam2.

Shifted all of the auxilary libraries into a common directory.  Considering
that I'm currently using 6 outside packages, it is just easier.

---------------------------------------------------------------
---------------------------- 0.72 -----------------------------

Did a bunch of cleaning so that the Linux compile is happier (and easier).
This involved getting rid of some warning messages and changing
the makefiles slightly.

The strange core dump on WinNT went away...

All of the code and extra files are under source code control (CVS).
You can just ignore the CVS directories. Eventually, I try to keep them
out of the release build.

Added profiling.  If you send 'profile 1' to gemwin, then normal profiling
is turned on (GEM displays the number of milliseconds per frame).  If you 
send 'profile 2', then images will not be cached (ie, the pixes will always
be processed).  If you send 'profile 0', then profiling is turned off.

pix_multiply multiplies the color components of two images together.
It doesn't modify the alpha channel.

Optimized pix code.

Because Miller is removing the INT type, I have slowly been moving it
out of the code.  If any objects have stopped working, please let me know.
I redid the construction macros in CPPExtern to reflect this change. 
If you have made any new GEM objects, you will probably need to
change to the new macro format.

Most of the dual input pix objects will process gray8 and RGBA data
gracefully.

---------------------------------------------------------------
---------------------------- 0.71 -----------------------------

Guenter got GEM working under Linux!  The biggest impact is that I
have changed all of the #ifdef __sgi to #ifdef _UNIX_ If specific versions
of Un*x need certain things, then they can be #ifdef'ed with __sgi,
or LINUX, or whatever.

Fixed a bug in polygon and curve.  I'm not sure why it ever worked on
the SGI...

All pix objects accept a 0 or 1 to turn on and off their processing.
The 0 or 1 should just be sent to the first inlet.

The inlets were backwards for colorRGB.

Fixed a bug in turning on and off texture mapping in pix_texture.

GemMan::initGem is now called from Gem_setup.  There seems to be a problem
with Linux creating the dummy static class to initialize GEM.

Changes pix_texture so that it deal with OpenGL 1.1, GL_EXT_texture_obj,
and base OpenGL 1.0  I think that every OS has the texture_obj
extension, but just in case, I also have the OpenGL 1.0 technique of display
lists.

Removed some spurious print outs.

I looked into using GL_BGRA_EXT for images on Windows.  It is faster
in the software version, but my Intergraph card doesn't support it.
It only makes a difference for OpenGL in software...and texture
download time isn't the primary problem then.  With a 512x512 image
using glDrawPixels in software, I got 6 frames/sec with RGBA and 7
frames/sec with BGRA_EXT.  Older SGIs like ABGR_EXT, but the newer machines
want RGBA.  Looks like I'm going to stick with RGBA for a while.

You can now load in Gray8 and RGBA images and they will retain their
format.  Before, everything was slammed into an RGBA image, with A == 255.
This means that you can have alpha masks on images, etc. The only pix
object which can currently handle a gray8 is pix_mask.  All of the other
pixes throw errors if they get a gray8.  This will slowly be fixed.

Added some new functions to GemPixUtil (from a paper by Alvy Ray Smith).
They should speed things up. Currently, only pix_composite is using them.

The color channels of pixels should be gotten by the const ints that
are in GemPixUtil (for instance, chRed, chGreen, etc).  Using hard coded
offsets like 0 or 2 for red and blue is asking for trouble.

gemheads no longer push and pop the entire matrix state when renderGL is
called. This should be faster (push/pop is slow on some platforms).  Also,
all objects are required to "reset" the OpenGL state when they are done,
so it shouldn't be neccessary.

Strangeness: There is an unreferenced memory exception on WinNT when you
quit Pd. However, it only happens if you use pix_image.  It doesn't
happen while you are using Pd, only when you quit...

---------------------------------------------------------------
---------------------------- 0.70 -----------------------------

All geos can now accept a size argument (they default to 1.0)

I cleaned up the texture coordinate mapping.  The order was slightly
random before. The order is more logical now; it is counterclockwise
starting at 0, 0.  If you use pix_coordinate any where, you will need
to fix the values.

Fixed a bug in translateXYZ.  The inlets where backwards.

You can now move the GEM window under NT.  NT doesn't automatically
take care of the basic window functions unless you pass the messages
through (unlike X Windows).

Texture mapping can be turned on and off by sending a 0 or 1 to pix_texture

Texture mapping defaults to GL_LINEAR.  Send a quality message to pix_texture
to change this. A "quality 0" means GL_NEAREST, "quality 1" means GL_LINEAR.

---------------------------------------------------------------
---------------------------- 0.69 -----------------------------

Fixed a bunch of bugs in imageVert.

Cleaned up some lingering problems in various objects (the open message to 
pix_multiimage didn't work as advertised for instance).

Setting window color is now dynamic.

multimodel now exists.  Works just like pix_multiimage, only it reads in 
Alias/Wavefront files.  It also has a caching mechanism.

---------------------------------------------------------------
---------------------------- 0.68 -----------------------------

fixed pix_2grey so it uses real color weights, instead of just averaging
the three colors.

pix_image now works the same way as pix_multiimage.  If you load in an
image which another pix_image has already loaded, they will share the
image.  This means that if you create a bunch of dummy pix_image
objects, you can send an open message to pix_images which have a gemhead
connected to them and get instantaneous image changes.

Found a MAJOR bug in the NT version of pix_texture.  Basically, if you
used it, the program would core dump.

Found another bug in square.  It involved texture mapping and texture
coordinates (mainly when you don't designate them).

Changed the default values for scaleXYZ (to 1, 1, 1) and translateXYZ
(to 0, 0, 0)

---------------------------------------------------------------
---------------------------- 0.67 -----------------------------

Forgot to add the arguments for the scale object.  This has been fixed.

Added translateXYZ, scaleXYZ, and colorRGB.  These create three inlets
which you can modify, instead of having to mess with vector messages.

Fixed a bug in pix_image and pix_multiimage (or more, an unacceptable
response to user error).  Basically, if you started rendering without
an image being loaded (or if an image failed to load, then you were
_VERY_ likely to core dump.  A check has been added, so this shouldn't
be a problem anymore.

pix_multiimage HAS CHANGED!  It accepts up to four arguments:

filename, number : will load the image files from 0 up to AND INCLUDING
the number

filename, lownum, highnum : will load the image files from the lownum up
to AND INCLUDING the highnum

filename, lownum, highnum, skiprate : will load the image files from
the low num up to AND INCLUDING the highnum, but incrementing the counter
by the skiprate, not by one.

No matter how many images are loaded, you can change which image is
displayed by sending a number.  The number must be between 0 and the
number of images which were loaded (notice that this number may not be
the highnum!)  If you try to display an image out of range, you will
get an error.

pix_multiimage now uses a shared cache.  Basically, if you give two
pix_multiimage objects the EXACT same values (filename, base number,
top number and skip number), then they will use the same collection of
images.  This will save massive amounts of memory if there is any
commonality between pix_multiimages.

pix_flip - see help file

---------------------------------------------------------------
---------------------------- 0.66 -----------------------------

Finished the port to NT (mainly had to get images working).

Made pix_colormatrix - This is really good for things like saturation,
hue rotate, etc.  I will eventually include a bunch of matrices to do
cool stuff.  Check out Paul Haeberli's paper on color matrices at
http://www.sgi.com/grafica/index.html

I removed pix_color.  It was a hold over from earlier days and I
don't think that anyone (including myself) is using it any more.

I got a title bar onto the graphics window, but you still can't move it
around.  I am not certain why this is the case, but I'll keep looking.

I made general speed ups to most of the pix objects.  Mainly, I have
been removing GetPixel() and SetPixel() functions (they have a lot
of overhead).  I will continue to use Get/SetPixel() while I'm developing
because they make things easy to deal with, but as objects get finished,
I will remove them.

Some of the manipulators (color, rotate, and translate) accept arguments.
For instance, if you do color 1 0 0, it will automatically set the
color to red.  The objects try to be intelligent about their arguments.
For instance, if color receives three args, it sets RGB, but if it
gets 4, it sets RGBA.  If rotate or translate get 3 args, then they just
set the vector, but if they get 4, then they set both the vector and
the value.

---------------------------------------------------------------
---------------------------- 0.65 -----------------------------

GEM works under NT!  I got the port working last night.  I had to make some
major changes to the underlying classes (specifically CPPExtern) because
MS VisC++ puts the vtable pointer in the first four bytes...no matter what.
This is a different behavior than SGI's compiler (and I think that it requires
more work for MS VisC++'s compiler).  While it was a pain to change things, it
is good in the long run.  The C++ standard doesn't say where the vtable is 
located, so this would have bitten me at some point.

---------------------------------------------------------------
---------------------------- 0.64 -----------------------------

Because MS VisC++ really wants files to end in .cpp (how stupid...),
I renamed all of the C++ files.

I looked into making all of the pixes be float, instead of unsigned char. This
would give increased flexibility because we could use negative numbers, not
worry about wrap around on the unsigned char, etc. In running performance
tests on an SGI O2, the performance difference is fairly great.  If GEM
was only an image processing program (ie, PhotoShop), then I would definetely
have pixes be floats.  However, since GEM is meant for real-time, I will 
continue to use unsigned chars to represent pixels.

For the tech heads...I used to generate the rendering by creating a 
linked list of the GEM objects.  The problem was that objects like
separator weren't possible because it wasn't a true DAG.  That is now
fixed so that tree/leaf graphs are possible.

Made render_trigger so you can know exactly when the rendering is occuring.

Made pix_multiimage! Just give it a file with a * (like myfiles*.tif) and an
integer for a range (the number of images).

Made pix_invert, separator

---------------------------------------------------------------
---------------------------- 0.63 -----------------------------

The src directory has been made into a tree.

Made pix_add and pix_subtract
Added a scale object

---------------------------------------------------------------
---------------------------- 0.62 -----------------------------

A dummy glxContext is created at startup.  What this means is that
in the constructors of objects, OpenGL calls can be made, display
lists can be constructed, etc.  Eventually, I would like to have a 
single window which is always in existance that can change between
single and double buffering, but that may be a little while.

I put Sam Leffler's tiff library back in.  All image files must be in
TIFF format again.  Basically, I think that Win NT would have trouble
making SGI .rgb files, while anyone can make TIFF formats.  Currently
there is some code bloat because libtiff does more than just read in a
TIFF file.

The pix_coordinate object allows users to set the S,T texture coordinates
for geos.  For instance, by giving pix_coordinate 4 S,T pairs, the texture
coordinates for a square can be changed on the fly.  Not all of the geos
can support this ability right now (currently only square, triangle, and
polygon, but this will change in the near future).

A FAQ has been started, but there really aren't any questions in it yet.
As people think of them, please let me know and I'll add them.

---------------------------------------------------------------
---------------------------- 0.61 -----------------------------

Cocoon html help files for developers have been created.

GEM now uses an internally generated DAG for rendering.  This 
removes a serious bug where by objects could still try to reference
dangling pointers.  GEM objects act like the tidle objects do
from a users point of view.  Even if you break a connection
in a GEM chain, the GEM objects will continue to work.  This
means that it is safe to edit patches while a GEM chain is 
running.  To rebuild the GEM patch, rendering must be turned
off and then back on (just like the tilde objects).

Using the td library from Evans & Sutherland by Nate Robbins to display
Alias/Wavefront files (.obj).  It also takes care of image
loading, although it is only .rgb.  If people complain enough,
then I may return to the Sam's libTiff library, but it is so
big that the td library is better.  The td library can also be
compiled on Windows (or else I wouldn't have used it).  The new
object is called model (although it may change its name some day).

There is a new object which maps the color of a pix to the Z of
a polygon.  It is isn't overly useful right now, but it is a cool
demo.  It is called imageVert.

---------------------------------------------------------------
---------------------------- 0.60 -----------------------------

Major changes to the internals of GEM.  gemwin is now only
an access point to the window manager, instead of actually
being the window manager.  This should make it easier to have
multiple graphics windows.

While I was getting the O2 video camera to work, I seem to
have broken the Indycam object...

---------------------------------------------------------------
---------------------------- 0.50 -----------------------------

Made the port from Max over to Pd.  Redesigned the class 
heirarchy somewhat.

