GEM ONLINE DOCUMENTATION CHAPTER 5: RELEASE NOTES

---------------------------------------------------------------
---------------------------- 0.79 -----------------------------
The example patches have been organized a little bit.  There is 
now a collection of directories which are installed with GEM.
Eventually, they will be fleshed out a lot more (I hope), but for
the time being, at least there is some order to them.

The model and multimodel objects accept a "rescale 0" or "rescale 1"
message.  In previous versions, the model objects would resize your
model to fit within the unit cube (all vertices where within -1 to 1).
This made it dificult to coordinate diferent model files together,
because they would all be resized by diferent factors.  Now, if you
send a "rescale 0" message into model or multimodel, it will not
do resizing for any _SUBSEQUENT_ loading.  In other words, if you
have already loaded in a model, and you send a "rescale 0", the
currently loaded model (or models) will not change.  Look at the
example patch gem_advanced/gemModelRescale.pd for how this works.
The left model chain is much larger and a scaleXYZ object with a
value of .1 is needed to even get the model into the viewport.
The model and multimodel objects default to "rescale 1" so that it
doesn't break any existing patches.

The middle and right buttons work in gemtablet now.  The outlets
are all pretty close together now, so until you can resize objects,
it will be difficult to select the correct outlet.  Look in
examples/gemTablet.pd for all of the outlets.

I have upgraded to Visual C++ 6.0.  I doubt that the GEM library
is backwards compatible for people who are writing their own
libraries.  Sorry, but the IDE is a little less painful in 6.0.

I removed the position inlet from the light object.  If you want
to move/rotate a world_light/light, then just put a translate
or rotate object into the chain.  It was broken before, but now
there is no reason for the position inlet.

light and world_light accept a "debug" message with a value of
1 or 0.  Look at the gemLightSphere.pd patch for an example.
It was too hard to figure out where the light is, and this turns on
a sphere for the light object (since it is a point light), and 
a cone for the world_light object (since it is a directional
light).  The world_light is NOT a spot light, even though
its icon is a cone.  The icons are the color of the light.

MarkEx has been merged into GEM.  I was tired of maintaining
two libraries.  Also, people didn't seem to be downloading
MarkEx, and there are a lot of good objects in there, IMHO.

The camera object is finally useable.  It has an inlet for the
translation and rotation vectors.  Anyone who was using it
before is now broken, but the change was very necessary.

gemwin can accept a perspective message.  This will set up the
viewing paramaters for the window.  You need to pass in 6 floats
with the "perspective" message, for the left, right, bottom,
top, front, and back.  The defaults are -1., 1., -1., 1., 1., 20.
If you send a reset message to gemwin, it will reset the perspective
values as well.

The big change in this release is a particle system.  It is based
on code from David McAllister.  There are many new object, all
of which interact in certain ways.  One design issue is that
there are far too many controls and variables to be able to 
expose directly in GEM.  People who want to get complete control
over all aspects of the particle system are going to need to
write their own externals.  However, most people should be fine with
the particle objects.  The new objects are:

CREATION
--------
part_head - The start of a particle group
part_color - Set the range of colors for the new particles
part_size - Set the size of new particles
part_velsphere - Set the velocity based on a sphere distribution
				 You need 4 args - xvel, yvel, zvel, and radius
part_velcone - Set the velocity based on a cone distribution

part_source - Generate particles

MANIP
-----
part_follow - Particles will follow each other like a snake
part_gravity - Have the particles accelerate in a direction
part_killold - Remove particles past a certain age
part_killslow - Remove particles below a certain speed
part_orbitpoint - Orbit the particles around a specified point

part_draw - Apply the actions and render the particles.  Accepts a
	message "draw line" or "draw point" to change the drawing style.

Look in the example files to get some idea how to use the particle
objects.  Notice that you still need a gemhead starting off the
chain, but after that, you just use the part_* objects.  Regular
GEM manips like rotate, translateXYZ, and scale will affect the
particles.  In general, you start with part_head, then modify
the particle parameters with the creation objects like part_color
and part_velocity. Then use part_source to actual generate the
particles.  Next in the chain, use the manip objects to control 
the particles behavior.  When you actually want to display the
particles, use part_draw.  Make sure that you remove particles as
well.  The best method is probably with part_killold.  If you 
don't remove particles, then you will eventually not be able to
add any new ones (the default number of particles at once is
1000, set by part_head).  You can also slow down the rate of the
particle generation with the part_source object.

---------------------------------------------------------------
---------------------------- 0.78 -----------------------------
If you don't want GEM to take control of the tablet if it finds 
one, set the environment variable GEM_NO_TABLET to the
value "1" (no quotes of course).  There will be a print out if
GEM finds the environment variable.

I added a few more setup access function so that people who
use "-lib gem" or "-lib GEM" will work correctly.

Lighting will now work under single buffer mode, but you have
to destroy then create the graphics window to change the mode.  This
will not work with the GEM_SINGLE_CONTEXT variable.

pix_data is a new object.  It outputs color information from a pix.
    The first inlet accepts a bang to trigger it.
    The second inlet accepts a gem list (probably from pix_image)
    The third inlet is the x position (between 0 and 1)
    The fourth inlet is the y position (between 0 and 1)
    The first outlet is the gem list
    The second outlet is the color (an RGB list)
    The third outlet is the gray scale value (a float)
  See the example patches gemPixDataSimple.pd and gemPixDataComplex.pd
for possible use.

Fixed a pretty bad bug in the SGI image loading.  Basically, unless
the image was RGBA, it was going to core dump.  Also, the orientation
was wrong.

---------------------------------------------------------------
---------------------------- 0.77 -----------------------------
GEM is now under the Gnu Public License.  This should not affect
any one.  I also cleaned up the license information for the AuxLibs.
All of the license and usage information can be found in
GEM.LICENSE.TERMS

GEM has a new home - http://www.danks.org/mark/GEM

gemorb - a new object to interface with the SpaceTec SpaceOrb360.
It is a 6DoF ball with 6 buttons that connects to your serial port.
It is a very cool device, and is relatively cheap ($50 US).  If gemorb
is able to connect, it will print out a message, or an error if there
is a problem.  John Stone wrote the library.

There is a particle system with a number of new objects.  The system
uses a library by David McAllister.
ps I haven't had time to bring all of the objects online.  particle
is the only object right now.  It just creates a fountain.

accumrotate was added - three inlets to control the rotation.  Each
time a new value is sent in, it increases the rotation.  Sending
'reset' to the leftmost inlet sets the rotation matrix to
identity (ie, it resets it to no rotation).

rotateXYZ was added - three inlets to control the rotation.  Order
is X rotation, then Y, then Z.

The tablet cleanup is a little better now on WinNT.  There are still
some bugs, like it doesn't return to normal mouse usage after GEM exits.
However, the DLL is being released correctly...I just need to reset
to the default state somehow.

Cone and sphere have changed behavior as of 0.77.  The middle inlet
is now the size and the right inlet is the number of slices.

depth used to be sending '1' would turn on depth testing, but this
was conceptually wrong.  It should be 1 to turn on the depth
object (which would disable depth testing).  This is now the
current behavior.

ortho was added.  It changes the viewing from perspective to
orthogonal.  The size is the size of the window with (0, 0) 
being the lower left corner.  I made this object for creating
a background the size of the window, but you can probably
find other uses for it.

There is a matrix class for those who are writing objects.
It is in src/Base/Matrix.

---------------------------------------------------------------
---------------------------- 0.76 -----------------------------
Fixed a bug in spline-path.  I wasn't doing the knot logic 
correctly.  Thanks to Patrick Rost for finding this.

A bunch of internal changes to get GEM working with Pd 0.22
All instances of A_INT went away and the inlets and outlets are
created in the correct "logical" order now.

---------------------------------------------------------------
---------------------------- 0.75 -----------------------------
You can resize the window under WinNT and the viewport will change
to reflect the new size.

Also, the correct aspect ratio is maintained no matter what the
width/height ratio is for the GEM window.  The ratio is 
x:y -> (width/height):1.  This is currently only under WinNT.

gemmouse and gemtablet are new objects.  They currently only
work in WinNT.  You should be able to create the object in
the Irix/Linux versions, but you won't get any output.  See
gemmouse.pd and gemtablet.pd for examples.
gemmouse outputs the current mouse position and button up/down
for the GEM window.
gemtablet outputs the current pen position, pressure, orientation,
and pen up/down, with the GEM window mapped to the tablet.  If
GEM can connect to your tablet, a message will be printed at startup.
If you don't see a message at startup from GEM about connecting to
the tablet, then gemtablet will not output any values.  You must
have the wintab32.dll library installed.  Your tablet's installation
should do this.

Added a bunch of utility functions (spline, bias functions, etc).

linear_path and spline_path are new objects.  If you give them
an array, then they will generate a point from an index.  linear_path
will linearly interpolate between points.  spline_path uses the
points as knots for a curve.  See gemSplinePath.pd and
gemLinearPath.pd for examples.

Added __declspec declarations for Windows.  This should
make it easy for people to use GEM as a dll.

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

