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