#### Archived

This topic is now archived and is closed to further replies.

# Skybox vertex array?

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

## Recommended Posts

I''m trying to eliminate all glBegins and glEnds in my program, but the skybox is giving me trouble. With vertex arrays, how would I specify the texture coordinates properly, as each vertex has several different texCoords depending on which quad is being drawn. Its my understanding that a GL_TEXTURE_COORD_ARRAY has one tex coord per vertex, but maybe I''m wrong there? My vertex array has just the 8 vertexes of the cube right now, like the one in the redbook (which they don''t texture). Also, is there any good way to draw text to the screen without using glBegin and glEnd? I am using the bitmap font, which is compiled display lists, but its still immediate mode...

##### Share on other sites
Funniest thing is that somtimes vertex arrays give -1, 0, +1 fps difference. Note that -1!
You could create 1 custom texture & render the box as one tristrip.
BTW, is there some point in using color/normal arrays if I have 20+ equal elements, or it's better to call glColor3f(1,1,1); once? And is there some way to specify 2 normals at corners?

______________________________

[edited by - _Madman_ on May 7, 2003 11:10:31 AM]

##### Share on other sites
Basically, if two vertices have the same coordinates but different color/texture coords, consider they are two *different* vertices. So, to make your cube you''ll need 6*4=24 vertices. Some will have the same coordinates. Yes, it''s a bit redundant but it''s how you''re supposed to do.

##### Share on other sites
quote:

I''m trying to eliminate all glBegins and glEnds in my program, but the skybox is giving me trouble.

My advice: forget about it. Vertex arrays are faster than glBegin/End only from a certain number of faces/vertices on. There is a break even point, since vertex arrays have an inherent setup overhead. If you are below that face number (which is highly hardware dependent, but generally somewhere around 20 to 30 faces), then glBegin/End will be faster than vertex arrays.

For a skybox with 8 vertices, as well as for text rendering (GL_QUADS, I suppose ?), you can safely use glBegin/end. If you are really obsessed by performance, then you should wrap them into a display list. But don''t bother putting them into VA''s, not if the face count is that low.

##### Share on other sites
yup, agreed. skyboxes are simple enuf that dumping em into a display list is probably more worth the time and performance than putting it into a vertex array. its a different issue with a skydome though

##### Share on other sites
Forget that shi* about skybox in display list! I had that & because of depttest I had 3 fps, out of display list 80! Plus display lists are real a hole in vp/fp!
Moreover I havn''t seen ANY improvement in performance by using them!

______________________________

##### Share on other sites
quote:

its a different issue with a skydome though

Definitely true. That''s where VA''s get interesting again.

##### Share on other sites
hrm, i wonder y would dephttest screw up the display list form of the skybox. anyway, i usually disable depth writing when rendering the skybox (NOTE: depth writing and depth testing are 2 different things). I suppose disabling depth writing could/should improve performance. but i dunno how its implemented so i may be wrong. but seriously.. y would the display list give that huge a difference? i neva got that before.

##### Share on other sites
quote:

I suppose disabling depth writing could/should improve performance.

Yes, it does. It will reduce the amount of memory bandwidth required, and thus lower the impact on fillrate.

quote:

but seriously.. y would the display list give that huge a difference? i neva got that before.

Probably a problem with his code. Display lists will never make you lose performance (assuming you wrap more than a single call). Worst thing that can happen, is that you don''t get a difference at all.

##### Share on other sites
Donnow, but state changes causes reall mess in display lists, texture bindings don''t work well on anything except NV hw. And vp, must do a lot of matrix binding that is impossible in lists!

______________________________

##### Share on other sites
state changes may be problematic, but i suppose its clearly documented wat goes and doesnt go in display lists. besides, as long as u''re careful to keep track of em and restore them before the list ends, it shud be fine.

but wat about vp? i assume u''re talking bout vertex programs. we didnt mention those, but i doubt u can even put them in display lists. or could you?

##### Share on other sites
You can''t but you must pass modelview etc. matrices to vp & if you are performing transformations in display list mess goes there!

______________________________

• ### Forum Statistics

• Total Topics
628645
• Total Posts
2984026

• 9
• 9
• 9
• 10
• 21