For those of you that are eager to look at Kurt’s slides, I have put them at:
Cass, what’s wrong with you? You just got done with ARB_VBO, which means we can finally be satisfied. But no, you go and bring that up to tempt us more with even greater power, flexibility, and, dare I say, easy and trivial Render-to-texture functionality.
What’s the ETA on the full ARB_“Uber_Buffer” extension (or extensions)?
No sensible app should keep an OpenGL context alive across a modechange
As soon as you figure out a way to transfer across an embedded Internet Explorer child window (with all state/context) to a newly created window on mode change, you might be able to claim this 
However, as that isn’t really an option right now (and there seems to be no immediate plan to make it so), there are certainly legitimate reasons to re-use main windows after mode switches.
Originally posted by JONSKI:
What kind of power curve can I expect with these new headers? Can you post a dyno sheet?
Say wha? This is a C/C++ header file not a car engine.
-SirKnight
Originally posted by SirKnight:
[b]Say wha? This is a C/C++ header file not a car engine.
-SirKnight[/b]
Bad joke, have a sense of humor. 
Originally posted by jra101:
Power curve? Dyno sheet?
Hes talking bout dinos sh*t. Didnt You know?
I think I came across a bug in the drivers! I think…
My render procedure is something like this:
//create the buffer objects
for(i=0; inumMeshes; i++)
{
GlGenBuffersARB(1,&Modelo->Meshes[i].bufferID);
GlBindBufferARB(GL_ARRAY_BUFFER_ARB, Modelo->Meshes[i].bufferID);
GlBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(MD5Vertex)*Modelo->Meshes[i].numVert, NULL, GL_DYNAMIC_DRAW_ARB);buffer=GlMapBufferARB(GL_ARRAY_BUFFER_ARB,GL_WRITE_ONLY_ARB);
memcpy(buffer,Modelo->Meshes[i].geomCopy,sizeof(MD5Vertex)*Modelo->Meshes[i].numVert);
GlUnmapBufferARB(GL_ARRAY_BUFFER_ARB);
}//do some other stuff
//draw to depth
for(i=0; inumMeshes; i++)
{
MD5Mesh& mesh=Modelo->Meshes[i];
if (mesh.materialShader->transparent)
continue;
GlBindBufferARB(GL_ARRAY_BUFFER_ARB,mesh.bufferID);
GlVertexPointer(3,GL_FLOAT,sizeof(MD5Vertex),calcOffset(mesh.geomRender,&mesh.geomRender->pos));
GlDrawRangeElements(GL_TRIANGLES,0,mesh.numVert,mesh.numTri*3,GL_UNSIGNED_INT,mesh.Indices);
}
//render some more//do the animation
MD5SetFrame(Modelo,frame);
for(i=0; inumMeshes; i++)
{
GlBindBufferARB(GL_ARRAY_BUFFER_ARB, Modelo->Meshes[i].bufferID);
buffer=GlMapBufferARB(GL_ARRAY_BUFFER_ARB,GL_WRITE_ONLY_ARB);
memcpy(buffer,Modelo->Meshes[i].geomCopy,sizeof(MD5Vertex)*Modelo->Meshes[i].numVert);
GlUnmapBufferARB(GL_ARRAY_BUFFER_ARB);
}
GlGenBuffersARB return a valid number, so does GlMapBufferARB, and so on…
But this creates some artifacts. Unless I put glFinish after MD5SetFrame and before mapping the buffers, it doesn’t work.
I believe the driver should do all the syncronization work, right? So, where am I doing things wrong or is it a driver bug being worked out?
The drivers are beta.
Originally posted by KRONOS:
I think I came across a bug in the drivers!
What drivers are you using?
Originally posted by sanjo:
[b]does anyone know how to fix the det. 43.30
resolution and refresh rate issue?
with 43.00 i could get near any resolution and refresh rates above 100 Hz.
now with 43.30 the resolutions are restricted to some. and i get max 85 Hz. refresh rate.
thanks[/b]
sorry to bother you again.
but i would really appreciate any answer to this problem.
or simply, is it even possible to change the settings anyhow ?
thanks
Originally posted by JD:
You know what would be nice? A html file with links pointing to split extension specification text files.
I once did a bit more readable version of the registry, by genrating a CHM of the registry. i just updated the file, and you can download it under: http://userpage.fu-berlin.de/~larswo/OpenGL-Extensions.chm
It is not perfect, some extensions where a bit failformated. Also it does not include cross references yet (usefull for the dependency section or some function references) but maybe i do this sometime.
Lars
Sorry, forget to mention that! 
I’m using the Detonator 43.30…
KRONOS, aren’t you supposed to check the return value of glUnmapBufferARB?
Maybe you should look into that first.
Skipping the maps/memcpys/unmaps and just using glBufferDataARB (with non-NULL parameter) might be worth a shot too.
Originally posted by NitroGL:
Bad joke, have a sense of humor.
I’m sorry you thought I was making a joke but I was not. Power curves and dyno sheets have to do with performance of engines and the like, beit a car engine, motorcycle, or whatever kind of engine, even wind turbines. I guess I can see how you thought I was making a joke there, but trust me, if I were it WOULD be funnier than that.
See here is an example of a dyno sheet: http://www.suprastore.com/800rwhpclub.html
How you can make one for a header file I don’t know.
Here it talks about power curve a little for a dirtbike: http://www.onoffroad.com/dubach.html
DISCLAIMER: I am not trying to be funny with all of this. I just don’t see how a power curve and a dyno sheet has to do with a header file.
Maybe it was meant that he wanted a graph comparing the performance of VAR/VAO with VBO?
-SirKnight
[This message has been edited by SirKnight (edited 03-19-2003).]
How you can make one for a header file I don’t know.
I can’t believe there is so little overlap between computer and car people. The joke was referring to the new “headers” that go with this extension, i.e. glext.h. On a car, headers are the tubes that the exhaust goes through when it exits the engine. Replacing stock headers with more free flowing ones can increase engine horsepower by reducing back pressure. Get it? ha ha
– Zeno
Actually, I don’t have to worry about headers. I drive a turbo rotary, so all I have to worry about are those nVidia detonators. I’ve seen many a turbine and rotor housing suffer from its ill effects.
Oh yeah,
The RX-7 club knows about you.
Thanks to me, they also know about the new VBO.
Haha. So when can we expect new RX-7’s with these new VBO headers? I bet they will beat everything else on the road. 
-SirKnight
KRONOS, aren’t you supposed to check the return value of glUnmapBufferARB?
Maybe you should look into that first.
Skipping the maps/memcpys/unmaps and just using glBufferDataARB (with non-NULL parameter) might be worth a shot too.
I check it, and it returns TRUE. I just didn’t put it there to make the example simpler. And I do not want to upload the data once. I want to change it every frame.
I create the buffers once, then enter the rendering loop where I draw and then change the data.
Originally posted by KRONOS:
I want to change it every frame.
I create the buffers once, then enter the rendering loop where I draw and then change the data.
I can’t think of any reason why calling BufferData would be any worse off than doing the map / unmap for each update. In fact, I can think of a lot of reasons why it might be better.
As said in Kurt’s presentation, there are very few times you’ll need to use map / unmap. If you’re completely respecifying the contents of a buffer you’re better off with BufferData.
– Ben
[This message has been edited by bashbaug (edited 03-19-2003).]
Why is it that you can only render from one vertex buffer? Why is the spec written to be so limitting in terms of swapping components (wanting to render a model using the same x,y’s, but using a completely different set of z-values. Mainly for heightmaps).
Originally posted by Korval:
Why is it that you can only render from one vertex buffer? Why is the spec written to be so limitting in terms of swapping components (wanting to render a model using the same x,y’s, but using a completely different set of z-values. Mainly for heightmaps).
ARB_vbo isn’t any more or less restrictive than conventional OpenGL vertex arrays. That is, you can’t specify different components of a vertex attribute from different arrays, but you certainly can specify different vertex attributes in different buffer objects. This would be useful to draw the same model with different colors or texture coordinates or whatever. It’s admittedly a stupid example, but consider:
BindBufferARB(ARRAY_BUFFER_ARB, vertexBufID);
VertexPointer(…);BindBufferARB(ARRAY_BUFFER_ARB, colorBufID1);
ColorPointer(…);// draw the model -
// vertex data comes from vertexBufID, color data from colorBufID1
DrawElements(…); // draw the modelBindBufferARB(ARRAY_BUFFER_ARB, colorBufID2);
ColorPointer(…);// draw the model again -
// vertex data still comes from vertexBufID, color data from colorBufID2
DrawElements(…);
– Ben
Is VBO going to be supported on Radeon 7500, 8500?
Thanks