[PD] [Gem] delay line for geos?

chris clepper cgc at humboldtblvd.com
Thu Dec 9 03:23:39 CET 2004

On Dec 8, 2004, at 10:14 AM, Peter Todd wrote:
>  What I can say, is that the 'gemlist' is a pointer to the data in the 
> graphics hardware (I'm not clear of details here), rather than 
> actually the data itself.

I don't know what you mean exactly by 'pointer to the data in the 
graphics hardware', but here's a simple little chain with some 
descriptions of what the objects do:

[gemhead] - resets the matrices using push/pop GL calls and zeros out 
some other data
[rotate] - tells the GPU to rotate the entire current matrix using 
[color] - changes the draw color for every drawing command after it.
[cube] - draws a cube using immediate mode calls.  all drawing is done 
inside this object.

In this chain, GEM doesn't need to pass any data between objects as it 
simply issues instructions to the GPU state machine, which are 
processed in order.  The [gemhead] resets the matrices to the origin 
(0,0,0), and [rotate] will transform the entire matrix data around the 
origin, so anything drawn in this chain will be transformed this way.  
The [color] objects tells the GPU to draw every vertex from that point 
on the same color until another glColor() command is sent.  All of the 
Geos do their drawing in a self-contained block of calls, which is 
known as immediate mode ([model] is the exception in that it uses a 
display list).  Because the drawing is self-contained, there is no 
vertex and color data passed between objects, which is why users can't 
get to those individual values.  in addition, immediate mode is the 
slowest method of drawing in OpenGL and most applications that need 
real-time performance have moved beyond it.  The [polygon] object does 
allow for the user to create a Geo by specifying each vertex, but the 
drawing still happens in immediate mode.

Texture coordinates are the only thing that GEM sends down the chain, 
and the [pix_texture] object initializes the values based on the 
dimensions of the texture.  []pix_coordinate] can change the texture 
coordinate data as it is represented by 4 x,y pairs.  Geos will then 
internally map that texture data to each vertex, and again this data is 
not accessible to the user.

The GEM CVS does have a set of objects in the vertex_array branch that 
adds a new drawing model which allows for extensive user manipulations. 
  These objects do pass vertex, normal, color and texture coordinate 
data around, and the user can manipulate them using a variety of 
objects much like the pix_ ones.  This system does correspond more 
closely to the description of 'a pointer to the data in the graphics 
hardware' because the arrays get uploaded all at once, straight to the 
card through a simple set of calls, and the client side arrays do have 
a 1:1 correspondence to the data on the GPU.  The vertex_array system 
still requires a great deal of  work to make it all viable, and 
currently there is no planned date for final release.


More information about the Pd-list mailing list