glMultiDrawArraysExt

[Ozzy]

Well, i would like to use glMultiDrawArrays ext (with CVA and VAR) to draw several prims (triStrips)using the same material for instance, but…
As i’m using T&L my vertice are stored untransformed of course and before drawing each primitive i need to specify its associated matrix (GL_MODELVIEW mode)

So what? most of the time prims using the same material etc etc wouldn’t share the same MODELVIEW matrix, thus, i don’t understand what glMultiDrawArrays is used for?? i mean, for untransformed data drawing several prims using the same MODELVIEW matrix sounds really strange bcoz it simply could be concatened in a single prim eh?
Maybe this EXT has to be used with pre-transformed vertice… i dunno ;))

Perhaps i’ve missed something… :)=

Any help?

[zeckensack]

What if you have an object that can’t be converted to one triangle strip?
Ok, I’ve never used this particular extension but it sounds quite nice to have around. I don’t like the idea of degenerate triangles just for the sake of better stripification at all, and this extension could potentially eliminate the overhead.

[Ozzy]

Well, my objects/blocks are already made with 1 prim = 1 strip!
So, it sounds that this extension isn’t useable for me…

[system]

Its good for super large structures and environments. You don’t transform those. You just transforms objects like people, cars, dogs and cats and you (the camera) so you keep those little things in separate arrays or you make separate calls.

GL_EXT_multi_draw_arrays <-- what cards have this extension?

V-man

[Ozzy]

New Nvidia drivers support this ext.

[zeckensack]

It’s more or less NVIDIA only.
Look here .

[Ozzy]

really nice link thx!

[Ozzy]

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:

1. to prevent rastertime overhead due to multiple calls when using the standart glDrawArrays?
2. 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).]

[jacklm]

The original motivation for the multi draw arrays extension was to reduce the overhead of a series of small primitives with no state changes in-between them.

For each call to glDrawArrays there is some minimum amount of overhead (in some cases it is just the cost of the function call). Sending multiple primitives gives better performance because the total overhead is reduced.

[mcraighead]

This extension is strictly for reducing function call overhead.

Trying to work in state changes like that would make the API a lot more complicated with little to no real benefit.

• Matt