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

[Cyrille Henry]

woww,
yes, there are lots of questions, but all my crasy dream are reality now...
that's a very good idea, and can be a very powerfull tool...

thanks
Cyrille

cgc at humboldtblvd.com wrote:

>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. ;)
>
>_______________________________________________
>GEM-dev mailing list
>GEM-dev at iem.at
>http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>
>
>  
>