[GEM-dev] I went into the kitchen to make dinner and ended up with...

[cgc at humboldtblvd.com]

A New GEM Render method.

All of the recent discussion about Cyrille's cool new tubes object has prompted
me to reveal what I have been working on the past six weeks a little early.  I
have added vertex arrays to the GEM render chain.  This allows for client side
CPU processing of vertex, color, normal, and texture coordinate data.  The
advantage is instead of a Geo issue drawing commands directly via glVertex etc,
the vertex, color, texcoord and normal data is passed via GemState for
manipulation of the data by other objects.  The final part of the chain is a
drawing object that uses glDrawArrays to send the arrays to the card all at
once.  This is a big optimization for most platforms, so in addition to far more
flexibility, GEM also gets a nice speed boost in many situations.  

Here's an example chain of objects I have already written:

vertex_model - loads a .obj model into vertex, color, normal and texcoord arrays
|
|
vertex_offset - adds an offset value to a single vertex, a range of vertices or
the entire array
|
|
color_set - sets the RGBA color of a single vertex, a range or the entire array
|
|
vertex_draw - draws the array 

This chain allows the individual vertices and their color data to be changed.  A
single vertex can be moved and it's color (including alpha) can be set.  If
vertex_quad was used instead of vertex_model then the quad could be pushed into
a parallelogram or rhombus shape quite easily.  Of course the more complex the
object the more intricate the possible manipulations.  RIght now I use a counter
connected to vertex_offset to translate each vertex one at a time in space,
which for the venus.obj model looks like the object is moved piece by piece
between positions.  It is also possible to have shifting gradients of color and
transparency with a few color_set objects in the chain.  All the standard
rotate, translate, and scale objects work as well.

other objects coded to this point:
vertex_grid : a variable 2D grid of vertices (probably will be a 3D version too)
vertex_quad : a simple quad 
vertex_combine : blends/morphs two vertex arrays (potentially very slick)
vertex_info : give some info about the arrays
plus more...

The structure of the arrays is as follows:

VertexArray : an array of x,y,z,w values for each vertex
ColorArray : an array of r,g,b,a values for each vertex color
NormalArray : an array of the three normal values (not much done on this yet)
TexCoordArray : an array of s,t values for each vertex

You will notice that the vertex array has the 4th w value - this is almost
purely for the purpose of making SIMD processing code easier to write.  I'm sure
w has some useful function (it scales values using value/w), but it will make
Altivec coding that much faster with a 16 byte data structure vs a 12 byte
x,y,z.  There will be a ton of Altivec written for these processing objects as
it was a major part of the design decisions so far.  Color is naturally 16 bytes
and TexCoords can be easily paired.  I don't foresee doing an excessive amount
of coding for normal manipulation objects, but I might well be wrong about that.
 There are some other flags and values passed via GemState like the vertex array
length, stride and a flag for which arrays have been enabled.

I think all of this directly relates to the tube/cylinder object issue for two
reasons: 1) all of the glu functions (sphere, cylinder, disk) have to be
replaced with vertex array compatible objects. 2) The manipulation of the
cylinder/tube length and size could either be a part of the vertex_tube object
or possibly implemented as a separate processing object (vertex_bend or stretch
??).  

As with any new feature there are lots of questions, and some thought needs to
be put forth into their resolution.  I'm not sure about my initial naming
convention - vertex_ color_ normal_ etc.  My thought is that each object should
have the name of which array it uses, but this leads to some semi-redundancy
like [vertex_offset], [color_offset] and so on.  Perhaps more general objects
could be written?  The problem I see is how to distinguish them from other GEM
and non-GEM objects (like [scale]).  

Also, the data in these arrays should be displayed in some graphic manner that's
not the final gemwin output.  Pd's current structures like array are far too
inadequate for our purposes.  The only way I see to make any acceptable data
visualization for such data is using OpenGL.  This would require multiple
windows attached to the context and it will cause some hassles to implement.  I
would love to hear any alternate methods of efficient data display.

The array data needs a buffering system similar to pix_buffer that multiple
render chains can write to and read from in order to make complex objects and
scenes.  The combining, concatenation, and removal of specific array sections
will further allow users to get away from the current static structures in GEM.  

Of course this system adds complexity, which requires clarity in the
implementation and thorough documentation.  The degree of flexibility that I
hope this offers GEM users should be quite liberating.  The current features
start to put GEM closer to serious content creation applications like Maya, yet
are tuned for the speed required for real-time use.  I plan on writing a routine
to save .obj files back to disk using glm, which will allow the saving of render
chain data, and remove the need for a 3D content creation app for model creation
(although Maya and the others are very nice tools).

I had not planned to bring this up until after the release of 0.888, but it
seems appropriate given the current discussion.  I will not commit any of the
code to CVS until 0.888 is out since it adds to the basic structure of GemState
and gemhead which have not been tested for long term stability.  Nothing is
changed or removed from the current Geos or classes - this is an addition not a
replacement for the current objects.

Give this a little time to sink in and perhaps check out the Red Book section of
Vertex Arrays (it's in the first 100 pages) to start getting a grasp on the
possibilities.  I have already done some pretty exciting stuff with the
primitive (pardon the pun) objects created thus far.  

cgc

ps - the subject line was Jamie's idea. ;)