Still something i haven’t understand yet is primitives initialisations for texture coords,normals etc… coz when you specify them like this :
glEnableClientState(GL_VERTEX_ARRAY_EXT);
glVertexPointer(3,GL_SHORT,sizePrim,ptr);
glEnableClientState(GL_COLOR_ARRAY_EXT);
glColorPointer(4,GL_UNSIGNED_BYTE,sizePrim,ptr+0x0c);
glEnableClientState(GL_NORMAL_ARRAY_EXT);
glNormalPointer(GL_BYTE,sizePrim,ptr+0x08);
etc… etc… you must set the current list ptr.
So i don’t understand how glMultiDrawArrays is aware about the new list start address?
bcoz this kind of init is only specified once eh?
perhaps lists have to be contiguous or what?
if anyone has made an example!!
Anyhow, as a conclusion with this subject i would like to add that this extension should be completed and more detailed about what is it intended for?
I mean, is this EXT should be used:
- to prevent rastertime overhead due to multiple calls when using the standart glDrawArrays?
- or is it a way to reduce primitives intitialisation process time? Ideally, it could be cool if the EXT could reduce this high cost primitive init as the cost of 1 prim init for a multiple list ;)) (what a dream eh?!!)
But anyway, it seems that this extension could be completed bcoz it could be nice to use this extension to draw multiple lists using same materials,same lights configs and so on and so forth but which are not within the same object.
What is missing then is the possibility to add the corresponding primitive matrix.
So it could look like this ->
//At the primitive level…
glEnableClientState(GL_MATRIX_ARRAY_EXT);
glMatrixPointer(1,GL_MATRIX,pMatrice,nbPrims);
//which is simply like pushing the matrix in the MODELVIEW stack.
thus, glMultiDrawArrays could be aware that each primitive has got its own MODELVIEW matrix and could internally pop between each of them!
That’s it! i think that this kind of modification could be really useful for everyone who is using pre-buffered lists!
[This message has been edited by Ozzy (edited 05-13-2002).]