glInterleavedArrays

This topic is 4523 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I am currently using Nvidia and gl*Pointer functions to send my vertex data. I as of now have vertex data setup as such
struct Vertex
{
float vx;
float vy;
float vz;
float nx;
float ny;
float nz;
float tx;
float ty;
float tz;
float s;
float t;
};


I know the byte alignment sucks but the tx,ty,tz are for tangent vectors. What would be a better setup for this or is it as good as it gets? I mean 44bytes ugh! Would dropping the tangent and using vertex, normal, texture coords be the way to go? Also how much performance would I see by using the glInterleavedArrays vs. the gl*Pointer functions? I currently have my array tightly indexed with gl*Pointer functions calling a stride amount to index my data. Thanks

Share on other sites
InterleavedArrays offers no advantage over the Pointer functions.

I see no problem with the byte alignment, they are all floats!

One way to improve this may be if you find you dont need all of those attributes, e.g. if some can be derived by the vertex shader, and you are not shader limited, you might benefit from transfering less data at the expense of shader cycles.

Otherwise, this isn't so bad. I've seen a lot worse! With 16 attributes, a vertex can be 64 floats; yours is only 11.

Share on other sites
Quote:
 Original post by goldInterleavedArrays offers no advantage over the Pointer functions.I see no problem with the byte alignment, they are all floats!One way to improve this may be if you find you dont need all of those attributes, e.g. if some can be derived by the vertex shader, and you are not shader limited, you might benefit from transfering less data at the expense of shader cycles.Otherwise, this isn't so bad. I've seen a lot worse! With 16 attributes, a vertex can be 64 floats; yours is only 11.

Thanks for the reply. I am assuming you mean 64bytes for a vertex! ;) 16 * 4 = 64 and 11 * 4 = 44. I seen some info on the net about Nvidia likes the interleaved array function over the gl*Pointer functions... Just wondering how much more or not enough for me to bother recoding my setup functions for rendering...

Thanks again.

Share on other sites
Quote:
 Original post by MARS_999I seen some info on the net about Nvidia likes the interleaved array function over the gl*Pointer functions...

Personally, I'd just trust what Gold is saying [smile]

Share on other sites
Quote:
 Original post by MARS_999Thanks for the reply. I am assuming you mean 64bytes for a vertex! ;) 16 * 4 = 64 and 11 * 4 = 44.

No, I mean 64 floats. You can have 16 attributes per vertex, where an attribute is 4 floats. Hence a vertex can be 64 floats, or 256 bytes! So by comparison, your 44 byte vertex isn't bad. ;-)

Quote:
 I seen some info on the net about Nvidia likes the interleaved array function over the gl*Pointer functions... Just wondering how much more or not enough for me to bother recoding my setup functions for rendering... Thanks again.

Well, lets be clear on this point: InterleavedArrays has two purposes:
1) Data is packed per-vertex instead of per-attribute
2) One API call instead of many

In practice (2) doesn't mean much. The important thing is (1) because it allows for better cache behavior. You can still interleave your data and benefit from the good cache behavior with the Pointer calls, by specifying the base and stride of each attribute. This is basically what InterleavedArrays does internally.

In other words:

float normal[] = {n0, n1, n2, n3, n4, n5, ...};
float vertex[] = {v0, v1, v2, v3, v4, v5, ...};
NormalPointer(FLOAT, 3*sizeof(float), normal);
VertexPointer(3, FLOAT, 3*sizeof(float), vertex);

/* Good */
float vertex[] = {n0, n1, n2, v0, v1, v2, n3, n4, n5, v3, v4, v5, ...};
NormalPointer(FLOAT, 3*sizeof(float), vertex+0);
VertexPointer(3, FLOAT, 3*sizeof(float), vertex+3);

The latter is an interleaved array!

Share on other sites
The best reason to use gl*Pointer functions with interleaved arrays instead of glInterleavedArrays is because you aren't stuck to the very limited selection of vertex formats that glInterleavedArrays supports. Aside from that there really isn't a difference except the few extra function calls with gl*Pointer, which in practice have no performance impact.

Share on other sites
Quote:
Original post by gold
Quote:
 Original post by MARS_999Thanks for the reply. I am assuming you mean 64bytes for a vertex! ;) 16 * 4 = 64 and 11 * 4 = 44.

No, I mean 64 floats. You can have 16 attributes per vertex, where an attribute is 4 floats. Hence a vertex can be 64 floats, or 256 bytes! So by comparison, your 44 byte vertex isn't bad. ;-)

Quote:
 I seen some info on the net about Nvidia likes the interleaved array function over the gl*Pointer functions... Just wondering how much more or not enough for me to bother recoding my setup functions for rendering... Thanks again.

Well, lets be clear on this point: InterleavedArrays has two purposes:
1) Data is packed per-vertex instead of per-attribute
2) One API call instead of many

In practice (2) doesn't mean much. The important thing is (1) because it allows for better cache behavior. You can still interleave your data and benefit from the good cache behavior with the Pointer calls, by specifying the base and stride of each attribute. This is basically what InterleavedArrays does internally.

In other words:

float normal[] = {n0, n1, n2, n3, n4, n5, ...};
float vertex[] = {v0, v1, v2, v3, v4, v5, ...};
NormalPointer(FLOAT, 3*sizeof(float), normal);
VertexPointer(3, FLOAT, 3*sizeof(float), vertex);

/* Good */
float vertex[] = {n0, n1, n2, v0, v1, v2, n3, n4, n5, v3, v4, v5, ...};
NormalPointer(FLOAT, 3*sizeof(float), vertex+0);
VertexPointer(3, FLOAT, 3*sizeof(float), vertex+3);

The latter is an interleaved array!

Thanks gold I got you on the 64, I wasn't thinking of all OpenGL's built in types but my own would end up being 64 if I moved to 16 floats. But with 16 * 4 * 4 yes thats 256. :) Just a miscommunication. I am doing the second one already myself with my pointer functions I provide a stride amount and then a offset amount to the pointer functions. I wasn't sure if glInterleavedArrays was a more optimized way to go e.g. glDrawRangeElements vs. glDrawElements. I been looking at optimizing my code. Thanks for the help.

Share on other sites
Quote:
 Original post by KalidorThe best reason to use gl*Pointer functions with interleaved arrays instead of glInterleavedArrays is because you aren't stuck to the very limited selection of vertex formats that glInterleavedArrays supports.

Right, that's why InterleavedArrays is on the proposed list of APIs to deprecate in a future version of GL. They simply don't scale when more attributes are added to the pipeline, and the same benefits can be achieved as previously described.

Share on other sites
The lack of scaling is why I've been advocating for the past year or two the useage of the gl*Pointer() functions with interleaved data.

Hmmm, it occurs to me, that once the OpenGL ML appears alot of tutorials are going to need rewriting or dumping..

Share on other sites
Quote:
 Original post by phantomThe lack of scaling is why I've been advocating for the past year or two the useage of the gl*Pointer() functions with interleaved data.Hmmm, it occurs to me, that once the OpenGL ML appears alot of tutorials are going to need rewriting or dumping..

Oh yeah, for sure alot of data will need to be dumped to get up to date with the new way of doing things. Not looking forward to this. All this time I spent learning OpenGL hopefully wasn't a waste of time. I am hoping that the code I am working with will similar or useable in the OpenGL LM version.

1. 1
2. 2
frob
15
3. 3
4. 4
5. 5

• 20
• 12
• 13
• 14
• 78
• Forum Statistics

• Total Topics
632142
• Total Posts
3004394

×