[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
glRotate().
|
|
[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.
cgc
More information about the Pd-list
mailing list