vertical sync; try to disable in driver settings...

but note, that there are still issues with ATI and gl_FragCoord and FBOs...

BTW, is there info available somewehre about current and previous HW generation (at least for NVidia and ATI) post-transform vertex cache sizes?

Keep in mind, that there still seems to be problems with gl_FragCoord on ATI systems when used in FBOs... :-(

But all of them do support the S3TC compression scheme, so they shoud already have corresponding licenses...

Haven't got the chance to download the specs yet, but what about the fixed function pipeline? Is it still in there or have it been eventually removed?

So you suggest to calculate the min/max values based on ping-ponging between 2 textures?

I already do that with success, but I thought the glGetMinmax() function could do that more efficiently...

Can someone confirm this?

But still not fixed for FireGL mobility cards; at least not for the current driver for the IBM W500 ThinkPad... :-(

Does ATI support LUMINANCE32F and ...16F color attachments for FBOs? After reading back the content after rendering into the FBO, all values are clamped to [0, 1]. The same code works as expected...

Use also a vertex array for your normals. Yes, you have to replicate each normal 4 times to match the vertices they belong to. And best would be to pad them with a 4th (unused float) to align the...

use the GL_EXT_transform_feedback: http://www.opengl.org/registry/specs/EXT/transform_feedback.txt

When do you set the viewport for the FBO? Before or after activating it?

you should use the "stencil color buffer" as a teexture; hence the reference to render-to-texture. you can use that additional texture with a full screen quad...

Would have been good if pixel ownership test had been marked as deprecated in OpenGL 3.0...

Is there a reason, you use your own clamp() function instead of the builtin GLSL one?

What does that mean? We use one rendering context for "normal" interactive viewing and for example for creating a "large scale" snapshot of the current scene we create an additional pbuffer and call...

@NVidia: an update to this document to include GF8 would be fine. :-)

Apple writes much of the GL drivers for Macs. They basically use OpenGL the way Microsoft uses Direct3D: they write much of the client code, and then shell out to a much simpler API that ATi/nVidia...

Would it also be possible to use this driver with and Apple MacBook Pro with an 8600M GT running Vista32 (with the inf-mod mentioned above)?

Are there any infos about the Siggraph OpenGL 3 BOF available yet?

Hi noncopyable! Could you talk about this police call? Seems to be more interesting than the OGL3.0 thingy...

oh, must have slept half a year: must be April 1st...

aehm, have you read the first post of this thread!?!?

Use 4 byte color instead and take care of 16, 32 or 64 byte alignment of your vertex data; e.g., for position and color only use something like:



struct VertexData {
Vector3f pos; // 12...