I'm curious why they have abandoned the previous method of binding GLmem to array, as shown in the GDC03 presentation . After adoption of that older method into the language of the newer proposal, we would get:IMO the original binding method is better then newer one, because:glBindBufferARB(GL_ARRAY_BUFFER_ARB, theVBO);
glAttachMem(GL_ARRAY_BUFFER_ARB, theGLmem, whatever);
glVertexPointer(4, GL_FLOAT, your_stride_if_you_insist, offset);
1. it seems to be more consequent with the rest of SB: you attach the GLmem thing to some existing, currently bound GL object (texture, FB, VB), rather than directly to the GL_VERTEX/COLOR/etc_ARRAY targets. (As far as I understand the spirit of the proposal, GLmem is not intended as a new kind of GL object, but as a holder of contents of *other* objects - otherwise I don't see justification for the new GLmem type, separate namespace, and lack of glGen)
2. it's easier to use: *only* initialization code is changed with SB (glAttachMem vs. glBufferData), but later you use all VBOs in exactly the same way.
3. there is no need for new gl(Multi)DrawElements() functions
4. the stride problem disappears: you set the stride as in regular VBO (although I'm not terribly convinced about the need of the stride in render-to-vertex-array usage)
So I'm curious, what adventages of the new binding method (glVertexArrayMem) outweighted these 4 above, as I simply can't imagine any...
[This message has been edited by MZ (edited 08-20-2003).]