• Advertisement
Sign in to follow this  

glInterleavedArrays

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
Share on other sites
Quote:
Original post by gold
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.


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 this post


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


How recent was this information?

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

Share this post


Link to post
Share on other sites
Quote:
Original post by MARS_999
Thanks 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:

/* Bad */
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by gold
Quote:
Original post by MARS_999
Thanks 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:

/* Bad */
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 this post


Link to post
Share on other sites
Quote:
Original post by Kalidor
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.


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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by phantom
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..


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.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Hmmm, it occurs to me, that once the OpenGL LM appears alot of tutorials are going to need rewriting or dumping..
Yeah, it's looking like I'll have to do 2nd editions of my books after all.

We've also bee talking about overhauling the NeHe tutorials to at least pave the way for this.

Share this post


Link to post
Share on other sites
Quote:
Original post by Myopic Rhino
Yeah, it's looking like I'll have to do 2nd editions of my books after all.

We've also bee talking about overhauling the NeHe tutorials to at least pave the way for this.


The NeHe stuff was infact specifically on my mind when I wrote that post [grin]

and mentioning the books reminds me I still havent sent you the code from my chapter, gah, sorry about that... I've had alot on right now and as my computer blew up I cant do it right now, I've made a big post-it note to remind me so it WILL get done.. and then I'll get myself a memory upgrade as apprently mind doesnt work all that well...

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Quote:
Original post by Myopic Rhino
Yeah, it's looking like I'll have to do 2nd editions of my books after all.

We've also bee talking about overhauling the NeHe tutorials to at least pave the way for this.


The NeHe stuff was infact specifically on my mind when I wrote that post [grin]

and mentioning the books reminds me I still havent sent you the code from my chapter, gah, sorry about that... I've had alot on right now and as my computer blew up I cant do it right now, I've made a big post-it note to remind me so it WILL get done.. and then I'll get myself a memory upgrade as apprently mind doesnt work all that well...


LOL yeah I been waiting for that code! :) I don't need it but would be nice to look at yours vs. mine. :)What happened to your PC? What blew up? I just had my RAM go out in mine and was down for a week also.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
and mentioning the books reminds me I still havent sent you the code from my chapter, gah, sorry about that... I've had alot on right now and as my computer blew up I cant do it right now, I've made a big post-it note to remind me so it WILL get done.. and then I'll get myself a memory upgrade as apprently mind doesnt work all that well...
#1 question I get about the book: "Where's the GLSL source code?"

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement