[PD] [Gem] delay line for geos?

[Peter Todd]

> 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',

Neither did I, really ;-).  Thanks for the corrected explenation (now my 
erroneous one hopefully won't get the chance to mis-educate or otherwise 
confuse anyone).

> 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.

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 
> 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.

I might take try to take a look at that.  Sounds promising, anyway.

Cheers
Peter
>
> cgc
>