Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Buffer vs immediate

  1. #11
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,183
    Quote Originally Posted by Kopelrativ View Post
    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:
    Code :
            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?
    Last edited by mhagain; 06-26-2012 at 03:45 PM.

  2. #12
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Off-topic, but you could use the offsetof operator if you don't want to abuse NULL pointers this way.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  3. #13
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,183
    Quote Originally Posted by aqnuep View Post
    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.

  4. #14
    Junior Member Regular Contributor Kopelrativ's Avatar
    Join Date
    Apr 2011
    Posts
    214
    Quote Originally Posted by mhagain View Post
    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:
    Code :
            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.

  5. #15
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,183
    What's interesting is to look at the generated assembly for this. It demonstrates that it's entirely a compile-time construct, like so:
    Code :
    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.

  6. #16
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    16
    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)
    Last edited by Beiufin; 06-27-2012 at 08:55 AM.

  7. #17
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,183
    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.

  8. #18
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    16
    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?

  9. #19
    Junior Member Regular Contributor
    Join Date
    Aug 2009
    Location
    Poland
    Posts
    111
    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.

  10. #20
    Junior Member Newbie
    Join Date
    Jun 2012
    Posts
    16
    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •