ARBvbo posted

http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt

There will also be a presentation on the OpenGL.org web site soon that Kurt Akeley gave at GDC 2 weeks ago.

Good news indeed reading it now.

Nice! When will we see it in the extension string?

It’s in NVIDIA beta drivers now, and it may show up in shipping drivers before the string appears in the extensions. Best way to check is to try to initialize the entry points.

Thanks -
Cass

great news, thanks for the info, cass

Just great!

Very cool. This is one of the last things I needed to be able to remove all vendor-specific extensions from my programs

– Zeno

[This message has been edited by Zeno (edited 03-17-2003).]

sooooo sweeeet!!!

Originally posted by Zeno:
[b]Very cool. This is one of the last things I needed to be able to remove all vendor-specific extensions from my programs

– Zeno

[This message has been edited by Zeno (edited 03-17-2003).][/b]

next thing is rendertexture without wgl stuff, and i’m happy

Originally posted by cass:

It’s in NVIDIA beta drivers now.

Is it in 43.03 drivers?
If so, when do we get a linux upgrade?

Good news, indeed!

Julien.

Originally posted by davepermen:
next thing is rendertexture without wgl stuff, and i’m happy

I actually would have prefered a new render texture extension than this, but I guess it doesn’t matter THAT much.

After reading the Issues section, one can truly see the amount of work undertaken by the working group.
Once again, great job!
Can’t wait to grab drivers implementing this :wink:

For those of you that are eager to look at Kurt’s slides, I have put them at:
http://www.r3.nu/~cass/gdc_slides/GDC2003_OGL_BufferObjects.ppt

I’ll leave them up there, but the OpenGL.org webmaster will be putting them up on this site soon too.

Thanks -
Cass

YEAH baby!!!

And it looks good too… Where are thoose drivers cass?!

Do those slides contain any useful info that is not in the spec itself? And if so, is there a PDF version?

Do buffer objects survive screen resolution changes, etc.?

    RESOLVED: YES.  This is not mentioned in the spec, so by default they behave just like other OpenGL state, like texture objects -- the data is unmodified by external events like modeswitches, switching the system into standby or hibernate mode, etc.

Have you talked to MS about this? AFAIK OpenGL cannot survive modechanges in XP because of XP’s design (the OS invalidates the WNDOBJ handler when not in the same resolution the WNDOBJ was created in), and MS acknowledges that shortcoming.

No sensible app should keep an OpenGL context alive across a modechange (unfortunately, there are some non sensible apps floating around). That statement in the issues part of the spec encourages faulty programming.

Care to comment?

[This message has been edited by evanGLizr (edited 03-17-2003).]

Originally posted by KRONOS:
[b]YEAH baby!!!

And it looks good too… Where are thoose drivers cass?!

[/b]

yes and where to get headers?
thanks!

Originally posted by tellaman:
where to get headers?

http://cvs1.nvidia.com/inc/GL/glext.h

Sweet! Working with offsets instead of direct pointers is a bit awkward at first, but other than that it works like a charm.

My GF4 Ti 4200 seems to strand at around 33 MTris/sec (using STATIC_DRAW, tristrips of about 1000 tris each, 1 million triangles total, index arrays also in a buffer object). Does that sound about right? If so, it seems a bit slower than VAR (SphereMark can reach 43 MTris/sec on my machine).

– Tom

What about NV10s and NV20s MAX_VERTEX_ARRAY_RANGE_ELEMENT_NV of 65535 and 1048575 limits.
Can we render objects that have more indicies than those limits above with GL_ARB_vertex_buffer_object? I mean can we render tham fast enough without spliting models on more parts? There are no implementation details or some restrictions of this kind in the VBO spec.

Thanks!