question about glGenBuffers()

  • Follow


Hi, I'm writing a simple program making use of VBO, but I'm having some 
trouble with the glGenBuffers() function.  The following is the code 
snippet.

     glEnableClientState(GL_VERTEX_ARRAY);
     glGenBuffers(1, &bn);
     printf("bn = %u\n", bn);
     printf("err = %u\n", glGetError());

The variable bn doesn't seem to get changed by glGenBuffers(), and 
glGetError() is always 0.  Am I missing something simple?

Thanks.
0
Reply Hai 3/10/2006 12:14:33 AM

On 2006-03-10, Hai Huang <haih@engin.umich.edu> wrote:
>
>      glEnableClientState(GL_VERTEX_ARRAY);

You do not need to call glEnableClientState at this point, you only need
to do that prior to rendering whatever it is that you render.

>      glGenBuffers(1, &bn);
>      printf("bn = %u\n", bn);
>      printf("err = %u\n", glGetError());
>
> The variable bn doesn't seem to get changed by glGenBuffers(), and 
> glGetError() is always 0.  Am I missing something simple?

If glGetError returns 0 (GL_NO_ERROR) then what exactly is your problem?
You say that the value of bn doesn't change, but you didn't mention
either its initial value, or what it is after the call to glGenBuffers.
Please be more specific, otherwise we won't be able to help you.

-- 
John Tsiombikas (Nuclear / Mindlapse)
nuclear@siggraph.org
http://nuclear.demoscene.gr/
0
Reply John 3/10/2006 1:12:57 AM


"Hai Huang" <haih@engin.umich.edu> wrote in message 
news:Pine.GSO.4.63.0603091909440.24997@lapis.engin.umich.edu...
>
> Hi, I'm writing a simple program making use of VBO, but I'm having some 
> trouble with the glGenBuffers() function.  The following is the code 
> snippet.
>
>     glEnableClientState(GL_VERTEX_ARRAY);
>     glGenBuffers(1, &bn);
>     printf("bn = %u\n", bn);
>     printf("err = %u\n", glGetError());
>
> The variable bn doesn't seem to get changed by glGenBuffers(), and 
> glGetError() is always 0.  Am I missing something simple?
>
> Thanks.

Do you have an active OpenGL context ?
jbw


0
Reply jbwest 3/10/2006 1:32:46 AM

Thanks for your reply.

>>      glGenBuffers(1, &bn);
>>      printf("bn = %u\n", bn);
>>      printf("err = %u\n", glGetError());
>>
>> The variable bn doesn't seem to get changed by glGenBuffers(), and
>> glGetError() is always 0.  Am I missing something simple?
>
> If glGetError returns 0 (GL_NO_ERROR) then what exactly is your problem?
> You say that the value of bn doesn't change, but you didn't mention
> either its initial value, or what it is after the call to glGenBuffers.
> Please be more specific, otherwise we won't be able to help you.

I didn't initialize bn because I thought bn is suppose to be an output 
value of the glGenBuffers() function.  Anyway, I tried to set bn to 
various values (really big values and even negative values), and after 
glGenBuffers() is called, its value is never changed.

>
> -- 
> John Tsiombikas (Nuclear / Mindlapse)
> nuclear@siggraph.org
> http://nuclear.demoscene.gr/
>
0
Reply Hai 3/10/2006 2:25:39 AM

Thanks for your reply.

>>     glEnableClientState(GL_VERTEX_ARRAY);
>>     glGenBuffers(1, &bn);
>>     printf("bn = %u\n", bn);
>>     printf("err = %u\n", glGetError());
>>
>> The variable bn doesn't seem to get changed by glGenBuffers(), and
>> glGetError() is always 0.  Am I missing something simple?
>>
>> Thanks.
>
> Do you have an active OpenGL context ?

I'm not sure.  I called glutCreateWindow() before the above snippet.  When 
the compiled program ran, I did see the window that glutCreateWindow() 
created, but I also got a warning message saying "freeglut (./a): Unable to 
create direct context rendering for window 'blah'".  I'm not sure if 
that's relevant to the problem I was seeing.

0
Reply Hai 3/10/2006 2:30:23 AM

"Hai Huang" <haih@engin.umich.edu> wrote in message 
news:Pine.GSO.4.63.0603092125480.7610@lapis.engin.umich.edu...
> Thanks for your reply.
>
>>>     glEnableClientState(GL_VERTEX_ARRAY);
>>>     glGenBuffers(1, &bn);
>>>     printf("bn = %u\n", bn);
>>>     printf("err = %u\n", glGetError());
>>>
>>> The variable bn doesn't seem to get changed by glGenBuffers(), and
>>> glGetError() is always 0.  Am I missing something simple?
>>>
>>> Thanks.
>>
>> Do you have an active OpenGL context ?
>
> I'm not sure.  I called glutCreateWindow() before the above snippet.  When 
> the compiled program ran, I did see the window that glutCreateWindow() 
> created, but I also got a warning message saying "freeglut (./a): Unable 
> to create direct context rendering for window 'blah'".  I'm not sure if 
> that's relevant to the problem I was seeing.
>

You won't have a context, as far as I know, until your display routine is 
called for the 1st time.
Build your display lists, texture objects, VBO's & etc there inside an "if 
(first) {" block.

The warning means that you don't have an accelerated driver. Linux I presume 
?
You should install the appropriate dirver for your card if possible.

-jbw


0
Reply jbwest 3/10/2006 2:36:59 AM

On 2006-03-10, jbwest <jbwest@comcast.net> wrote:
>> I'm not sure.  I called glutCreateWindow() before the above snippet.  When 
>> the compiled program ran, I did see the window that glutCreateWindow() 
>> created, but I also got a warning message saying "freeglut (./a): Unable 
>> to create direct context rendering for window 'blah'".  I'm not sure if 
>> that's relevant to the problem I was seeing.
>>
>
> You won't have a context, as far as I know, until your display routine is 
> called for the 1st time.
> Build your display lists, texture objects, VBO's & etc there inside an "if 
> (first) {" block.

No that's not true, you should have a context just after the call to
glutCreateWindow(), the usual sequence is: glutInit()
glutInitDisplayMode(), glutCreateWindow(), glutWhateverFunc(), and then
start calling gl functions.

> The warning means that you don't have an accelerated driver. Linux I
> presume ?  You should install the appropriate dirver for your card if
> possible.

Yes, the warning means that either there is no direct rendering driver
installed, or otherwise it is bypassed by f.e. having DISPLAY point to
an X server other than the local one, or having LIBGL_ALWAYS_INDIRECT
set to 1.

That shouldn't affect anything other than performance.

-- 
John Tsiombikas (Nuclear / Mindlapse)
nuclear@siggraph.org
http://nuclear.demoscene.gr/
0
Reply John 3/10/2006 7:08:35 AM

On 2006-03-10, Hai Huang <haih@engin.umich.edu> wrote:
>> If glGetError returns 0 (GL_NO_ERROR) then what exactly is your problem?
>> You say that the value of bn doesn't change, but you didn't mention
>> either its initial value, or what it is after the call to glGenBuffers.
>> Please be more specific, otherwise we won't be able to help you.
>
> I didn't initialize bn because I thought bn is suppose to be an output 
> value of the glGenBuffers() function.

That is absolutely true, I just wondered how do you know it doesn't
change if you don't know the initial value.

> Anyway, I tried to set bn to various values (really big values and
> even negative values), and after glGenBuffers() is called, its value
> is never changed.

If it is at all possible, please post a minimal compilable source code
that demonstrates the problem, the problem is not in the call of
glGenBuffers, that is for sure, it is somewhere in the rest of the code
that you do not show us. So it's very difficult to make any guesses by
this code fragment.

To make sure that you do have a rendering context, try using a function
that you know cannot fail as the first gl call of the program after glut
init. For example glGetString(GL_RENDERER); or something. If you get a
null you can be (almost?) certain that the problem is with the gl
context.

-- 
John Tsiombikas (Nuclear / Mindlapse)
nuclear@siggraph.org
http://nuclear.demoscene.gr/
0
Reply John 3/10/2006 7:18:21 AM

Code is as follows.  It doesn't get simpler than this.

void display(void)
{
     glClear(GL_COLOR_BUFFER_BIT);
     glFlush();
}

int main(int argc, char** argv)
{
     unsigned int bn;
     glutInit(&argc, argv);
     glutInitDisplayMode(GLUT_RGB);
     glutCreateWindow("My Window");

     bn = 0; // I assigned bn to be other values too
     glGenBuffers(1, &bn); // but this function never changes bn

     glutDisplayFunc(display);
     glutMainLoop();
     return 0;
}

It's compiled as `gcc -o test test.c -lglut` without any errors.  I'm 
using Mesa 6.2.1 which supports OpenGL 1.5.

> To make sure that you do have a rendering context, try using a function
> that you know cannot fail as the first gl call of the program after glut
> init. For example glGetString(GL_RENDERER); or something. If you get a
> null you can be (almost?) certain that the problem is with the gl
> context.
>

glGetString(GL_*) works.  It returns "Mesa GLX Indirect".

Thanks.
0
Reply Hai 3/10/2006 3:33:55 PM

Hi Hai Huang,
I am not sure your Mesa driver support GL_ARB_vertex_buffer_object. It
should be included in OpenGL 1.5 though. I think you already did, but
make sure glxinfo shows GL_ARB_vertex_buffer_object extension.

Here is my VBO note. At the bottom, there is an example code to
download. I include a makefile for Linux, so try to compile it on your
system.
http://www.songho.ca/opengl/gl_vbo.html

0
Reply song 3/10/2006 3:56:47 PM

On 2006-03-10, Hai Huang <haih@engin.umich.edu> wrote:
>
> Code is as follows.  It doesn't get simpler than this.
.... [snip] ...
> It's compiled as `gcc -o test test.c -lglut` without any errors.  I'm 
> using Mesa 6.2.1 which supports OpenGL 1.5.

I just compiled your program and it works here perfectly, bn becomes 1.
(GNU/Linux, nvidia proprietary drivers).

Did you actually check that Mesa provides the extension? if so, maybe
you should submit a bug report.

-- 
John Tsiombikas (Nuclear / Mindlapse)
nuclear@siggraph.org
http://nuclear.demoscene.gr/
0
Reply John 3/10/2006 4:02:33 PM

Hi,

Hmm, glxinfo doesn't show that VBO object is supported on my system.  It 
might be something to do with I'm running vnc over X.  Thanks for 
the link.  The teapot program always shows that VBO is off.

BTW, if I get this VBO issue resolved later, how big or how much 
video memory space am I able to use through glBufferData(), approximately 
on a 128/256/512MB video card?

-
Hai

On Fri, 10 Mar 2006, song wrote:

> Hi Hai Huang,
> I am not sure your Mesa driver support GL_ARB_vertex_buffer_object. It
> should be included in OpenGL 1.5 though. I think you already did, but
> make sure glxinfo shows GL_ARB_vertex_buffer_object extension.
>
> Here is my VBO note. At the bottom, there is an example code to
> download. I include a makefile for Linux, so try to compile it on your
> system.
> http://www.songho.ca/opengl/gl_vbo.html
>
>
0
Reply Hai 3/10/2006 5:57:44 PM

> On 2006-03-10, Hai Huang <haih@engin.umich.edu> wrote:
>>
>> Code is as follows.  It doesn't get simpler than this.
> ... [snip] ...
>> It's compiled as `gcc -o test test.c -lglut` without any errors.  I'm
>> using Mesa 6.2.1 which supports OpenGL 1.5.
>
> I just compiled your program and it works here perfectly, bn becomes 1.
> (GNU/Linux, nvidia proprietary drivers).

Thanks for checking up on it.  I think the issue might be that I'm running 
the program on vnc, which doesn't use the primary display of X, so some 
features are not enabled.  I'll check up on it and will write back later. 
Thanks for all the help.

0
Reply Hai 3/10/2006 6:00:48 PM

Hai,
GL_ARB_vertex_buffer_object extension is included as OpenGL v1.5 core
part. If glxinfo shows 1.5 in "OpenGL version string:", then VBO
extension should be included.

However, the version number is not really important. VBO can be even
supported in lower version if the driver supports it. My old Radeon
7200 supports VBO in software mode, but the version of OpenGL is 1.3
and 1.4 in Mesa(Linux). The program in the above link simply checks the
extension string, "GL_ARB_vertex_buffer_object" in order to determine
if it is supported or not.

And, VBO does not always use video memory. It can be video memory,
system memory or AGP memory. VBO memory manager will decide the best
place based on user's "hint". I think bigger memory is better :)
==song==

0
Reply song 3/10/2006 6:33:59 PM

13 Replies
487 Views

(page loaded in 0.176 seconds)

Similiar Articles:
















7/23/2012 6:17:55 AM


Reply: