|
OpenGL: Compiled Arrays |
spellcaster
Member #1,493
September 2001
|
This is a newb question. If I have a certain object (let's say a crate) that's drawn lots of times per level without changing and using the same textures all the time but at different locations: does it make sense to use compiled vertex arrays for that object? Do I have to lock the data per draw operation, or do I lock it once then move/rotate/draw the objects then unlock? When should I use compiled arrays as opposed to normal streamed or interleaved arrays? Can the glLockArraysSGI() call be stored in a display list? Lot's of questions.... -- |
Tobias Dammers
Member #2,604
August 2002
|
Generally, it's clever to use vertex arrays for objects where the average vertex is shared by more than 1 polygon (which includes about all solid models). --- |
spellcaster
Member #1,493
September 2001
|
I'm not talking about vertex arrays, but compiled vertex arrays (the SGI extension). -- |
Tobias Dammers
Member #2,604
August 2002
|
Oh dear. Never used these. --- |
Bob
Free Market Evangelist
September 2000
|
I don't see this extension in the SGI extension database. Perhaps it's a discontinued one? There already EXT and ARB versions of this extension: You should seriously consider the use of ARB_vertex_bufer_object (aka VBO), as it'll allow you to place the vertex data on board the video card for fast access (by the GPU). To answer some of your other questions: Quote: does it make sense to use compiled vertex arrays for that object? Yes. Display lists also work, but VBOs are even better. Quote: "Game Programming Gems I" seems to suggest that I should use it if I have an object that's rendered several times. GPG1 is a bit dated That said, if you render an object only once, then it doesn't really matter how you draw it, because there's very little that can be done to make it go faster. If you render an object multiple times, it helps the driver to know that your vertex data hasn't changed (CVAs), or that the vertex data is already on the video card (VBO) so that it doesn't even need to resend it. Quote: Do I have to lock the data per draw operation, or do I lock it once then move/rotate/draw the objects then unlock? The lock for CVAs only applies to the vertex data, and not how it's transformed. So you can safely lock the data, render the object, change the transformation matrices, render again, etc. You only unlock when you need to actually change the vertex data or the vertex pointers. Quote: When should I use compiled arrays as opposed to normal streamed or interleaved arrays? You should VBOs instead. But ifyou must use CVAs, then use them anywhere where you need to draw the object multiple times in a row so that you don't have to unlock/relock the vertex data when switching vertex arrays. Of course, if you put everything in a single big-arse vertex array, then you only need to lock that once, and can render whatever subset of it you chose. Quote: Can the glLockArraysSGI() call be stored in a display list? Since I can't find the specs for that extension, I can't tell you. Searching for LockArraysSGI returns a single (useless) hit on Google... -- |
spellcaster
Member #1,493
September 2001
|
Thanks. -- |
Korval
Member #1,538
September 2001
|
The CVA extension, used extensively by Quake3, was designed to allow for the possibility that a card could T&L the vertices into a buffer and then draw from a pre-T&L'ed copy of the vertex data. If you keep changing the transform matrix, it has to refill the buffer each time. There is another possible way to implement a fast CVA. The implementation can copy the vertex data untransformed to a video-memory, or AGP-memory, buffer. From there, it can simply send the vertices each time the user requests it. Which way is CVA implemented on your drivers? There's no way to tell. In general, you can assume that you get a performance increase in multipass situations. Outside of that, you might get a performance increase. Or, you might get a performance decrease. The only way to tell is to benchmark it. In either case, though, VBO is always the prefered choice. It will always be faster than, or with streamed data, at least as fast as, CVA. |
|