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@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@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev