Vertex Buffer Objects performance problems

[Niels]

Thx tomb...

I now see what's going on :oops:

I've specified numbers for glDrawRangeElements that I thought were the first and last value in the index array I was about to draw, but really told GL I was using some strange vertex range, and then told it to start from offset 0 and draw all faces. Doing this once for each material would account for the overdraw. (I did wonder why it needed both a range AND offset + count :roll:)

So the point of glDrawRangeElements is to help GL select which vertices to prefetch from the vertex array.

I still find it odd that glDrawElements takes offset in bytes and count in number of unsigned shorts, but I guess that's a matter of preference.

[tomb]

The offset in glDrawElement is actually a c pointer. It makes only sense to define pointers as having a byte offset.

[Niels]

Agreed, but I'm not currently programming in C ...

Anyway, as long as I know, it's ok, and I fully understand and agree with the reasoning behind keeping LWJGL a 1:1 mapping of OGL.

It's just an easy place to stumble, that's all.

[princec]

I took me a while to figure out what exactly glDrawRangeElements actually was doing and why. What it does is allow the driver to block copy a chunk of your vertex data into AGP RAM immediately and then reference them from there (as it knows the upper and lower bounds of any vertex indices that you are going to use in that call). It supercedes the old and defunct glLockArraysEXT/glUnlockArraysEXT methods, which did a similar function but in rather less defined and awkward way.

Cas