[PD] [Gem] delay line for geos?
peter_todd82 at yahoo.co.uk
Thu Dec 9 11:13:15 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
Neither did I, really ;-). Thanks for the corrected explenation (now my
erroneous one hopefully won't get the chance to mis-educate or otherwise
> 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.
Right, ok. I guess it's not so far from what I thought.
> 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
> 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.
I might take try to take a look at that. Sounds promising, anyway.
More information about the Pd-list