Buffer vs immediate

[mhagain]

It should be &bufpoints->position and &bufpoints->color, shouldn't it? That will give you the offset, instead of referencing a value near 0.

No, because of array/pointer "equivalence" - but good to call on it, because if you have a single unsigned int (representing an RGBA colour) you will need to use & on it.

In another piece of code, I have:

        surfacevert *svert = NULL;
 
        glBindBuffer (GL_ARRAY_BUFFER, blahwhatever);
 
        glVertexAttribPointer (0, 3, GL_FLOAT, GL_FALSE, sizeof (surfacevert), svert->position);
        glVertexAttribPointer (1, 2, GL_FLOAT, GL_FALSE, sizeof (surfacevert), svert->texcoord0);
        glVertexAttribPointer (2, 3, GL_FLOAT, GL_FALSE, sizeof (surfacevert), svert->texcoord1);

Viewing in the debugger, we can see that svert->position is 0x00, svert->texcoord0 is 0x0c and svert->texcoord1 is 0x14, which correctly correspond to buffer offsets of 0, 12 and 20 for this vertex type.

Not 100% certain of the portability of this trick though - it works fine on Windows with MSVC and is great for decoupling your struct layout from your gl*Pointer calls, not to mention a darn sight nicer to read than the more usually seen BUFFER_OFFSET macro, but what about other platforms?

[aqnuep]

Off-topic, but you could use the offsetof operator if you don't want to abuse NULL pointers this way.

[mhagain]

Off-topic, but you could use the offsetof operator if you don't want to abuse NULL pointers this way.

That one's new to me, but it's interesting to know. I do note that the "traditional" implementation given on the Wiki page you linked involves similar NULL pointer abuse though, but you could write your own version that casts a chunk of scratch memory to your struct type then evaluates the offset.

[Kopelrativ]

No, because of array/pointer "equivalence" - but good to call on it, because if you have a single unsigned int (representing an RGBA colour) you will need to use & on it.

In another piece of code, I have:

        surfacevert *svert = NULL;
 
        glBindBuffer (GL_ARRAY_BUFFER, blahwhatever);
 
        glVertexAttribPointer (0, 3, GL_FLOAT, GL_FALSE, sizeof (surfacevert), svert->position);
        glVertexAttribPointer (1, 2, GL_FLOAT, GL_FALSE, sizeof (surfacevert), svert->texcoord0);
        glVertexAttribPointer (2, 3, GL_FLOAT, GL_FALSE, sizeof (surfacevert), svert->texcoord1);

Viewing in the debugger, we can see that svert->position is 0x00, svert->texcoord0 is 0x0c and svert->texcoord1 is 0x14, which correctly correspond to buffer offsets of 0, 12 and 20 for this vertex type.

Not 100% certain of the portability of this trick though - it works fine on Windows with MSVC and is great for decoupling your struct layout from your gl*Pointer calls, not to mention a darn sight nicer to read than the more usually seen BUFFER_OFFSET macro, but what about other platforms?

I see, you are right, of course, I didn't realize they were arrays. I use it in Linux with gcc, it should be portable. This is a little tricky sometimes, if the type of svert->position is "hidden" data type (which it wasn't in your example). For example, if you use glm::vec3, is that an array or not? In that case, I usually do "&svert->position[0]". Willoffsetof help for this situation?

I also do not like the BUFFER_OFFSET macro.

[mhagain]

What's interesting is to look at the generated assembly for this. It demonstrates that it's entirely a compile-time construct, like so:

004950F7  mov         eax,dword ptr [svert] 
004950FA  add         eax,14h 
004950FD  push        eax  
004950FE  push        20h  
00495100  push        0    
00495102  push        1406h 
00495107  push        3    
00495109  push        2    
0049510B  call        dword ptr [___glewVertexAttribPointer (56035Ch)]

I do have to agree that it can be a little frightening to look at, though.

Regarding offsetof, because it's defined as a size_t it means that you need to do a (void *) cast in order to use it. &stvert->position[0] works perfectly fine though and also doesn't cause a NULL pointer dereference (it generates the very same asm, in fact).

Either way, there is definitely no perfect solution here. The traditional BUFFER_OFFSET, however, is quite nasty because it requires your draw setup to have knowledge of the struct layout, packing, alignment, etc.

[Beiufin]

Turns out I only have access to OpenGL 1.4 with ARB extenstions. Should I skip VBO and just use standard vertex arrays?

(glBindBuffer, GL_ARRAY_BUFFER, and a few others are undefined in this version as I do not have access to glew.h)

[mhagain]

Probably best to stick with standard vertex arrays, yes. There's a good chance that you don't have hardware T&L either, so you won't get much benefit from VBOs even if you could find a driver that supported them.

[Beiufin]

I have an overlayed grid that only changes when a zoom in or out occurs. Drawing it requires only about 1000 vertices. Whats the most efficient way of drawing these rarely updating verticies (The grid contains a series of lines and points)? Or should I just add to the VertexArray Im using to draw the constantly deque of points?

[kowal]

I bet that display lists are best for static geometry in legacy OpenGL.
Pack Your grid into display list and rebuild list when You change zoom settings.

[Beiufin]

Ah display list is simple enough and looks like it will suit my needs perfectly!

I have a couple more questions about efficiency though (I hate to keep bothering you guys with these "newbie" questions, if there is a good place for me to learn the various efficiency values of various c/c++/OpenGl calculations please let me know!).

Is it more efficient to check and exclude off screen points from the VertexArray or just add them all?

Also, as this program has a zoom, when zoomed out a lot of the points may overlap due to lack of pixels. Is it more efficient to check and only include points that are far enough appart to be unique on screen or should I just add every single point regardless of overlaps?
(I have this currently implemented, fully zoomed out it can reduce the VertexArray order of magnitude by 3 or 4 (800000 points would be reduced to around 2000) but it does require me to perform a distance calculation each time a point is added, and a distance calculation on every single point if the user zooms in or out)