Basic Question

The hardware only accepts triangles (and lines & points), so OpenGL triangulates other polygons anyway. An indexed triangle list, in conjunction with a static vertex buffer, is generally the most efficient way to feed graphics hardware.

I pressume using vertex array with GL_TRIANGLE_STRIP is the fastest way possible. There will be no calculus on CPU side once the vertex array is static.

Triangulate your object offline and then use it so that you don't have to do this step everytime you go and render. Alternatively, you could triangulate it once the first time and then save the results to re-use over and over.

Thanks for the answers!
I have another question: On Windows, opengl32.dll supports OpenGL 1.1, but an ICD can support a higher version. If I use OpenGL 2.1 functions (after checking the version with glGetString()), can I get function pointers for the 2.1 core functions or I need to give wglgetProcAddress() a string containing the equivalent extension function name (for example, "glBindBufferARB" instead og "glBindBuffer")?

[Edited by - Tom Backton on November 27, 2009 8:00:50 AM]

You shall pass a string of the name of the function you want to get. So if you want to get glBindBuffer, you pass "glBindBuffer".

Whether you want the core or the extension function is up to you to decide, but don't check for support for one and get the other. That is, if you only check for proper core version support, then that function is the only one you should ask for, because there are no guarantees the other one will be available.

Thanks for the answer! :)

Another question: ATI suggests each element in a VBO starts on a 32 byte boundary. Does it mean the offset between the VBO's beginning and the element's beninning should be 32*n or that I can have an element start at offset 7 as long as it's 32 bytes long? (my program uses 16 bytes per element, so I'll probably interleave elements to avoid watsing 16B padding for every 16B vertex. The question is whether I should place more frequently used vertices as even-numbered elements so that they get the boost)

And another one: generally - and specifically in games - should I use float texture objects and framebuffer objects or 32-bits-per-color TOs and FBOs? I mean, TOs and FBOs that are used for rendering in every frame or almost every frame and are never updated or rarely updated.

[Edited by - Tom Backton on November 27, 2009 8:19:20 AM]

Quote:

Original post by pescador I pressume using vertex array with GL_TRIANGLE_STRIP is the fastest way possible. There will be no calculus on CPU side once the vertex array is static.

Close, but no cigar. The fastest will typically be indexed triangle lists (i.e. glDrawElements with GL_TRIANGLES), stored in a VBO (vertex buffer object).

Using VBO ensures that your data is actually stored in graphics memory (or as close to as your architecture supports), and the indexing allows you to take advantage of the post-transform vertex cache.

Here's another question: (the two ones in my last post are still unanswered)

http://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_(GLX)

I don't understand something. Before glXGetProcAddress() is called, a dummy context is created, but it is not made current. I thought there has to be a valid current context. Is it a mistake or glXProcAddress() only needs an existing context even if it's not current?
And what about WGL? wglgetProcAddress() can be called only after an RC is made current right? Another question: the OpenGL wiki says an RC cannot be recreated for a window, so after destroying the dummy RC I also need to recreate the window. But somewhere else I read a tutorial that doesn't delete the window. So I'm not sure...does the one-wglCreateContext()-per-window exist?

And a fourth question...
Does OpenGL define a minimal texture size? Or a 2D texture object can be 1x1 ?


[Edited by - Tom Backton on November 27, 2009 10:32:18 AM]

Quote:

Original post by Tom Backton And a fourth question... Does OpenGL define a minimal texture size? Or a 2D texture object can be 1x1 ?

Minimum size is 1 in every dimension (i.e. 1 for 1D, 1x1 for 2D/cubemap and 1x1x1 for 3D). The only time one tends to use such small textures, however, is when reading back the result of a GPGPU calculation from the pixel shader.

Another question...

(there are still another 3 unanswered questions: the first one in my previous reply and the two ones in the reply before the previous one)

What are the definitions of Bool, True, False, XID and None in Xlib, and what are TrueColor and DirectColor visuals? I couldn't find them by searching in Google...I'm sure programmers familiar with GLX can easily answer this...

And another one: If I create a texture object with internal format GL_RGBA and every component's type is GL_UNSIGNED_BYTE, what will OpenGL do with the data? Will it convert the components to float and store them like this, as clamped 32-bit floating-point color components, in the texture memory? Or it will just copy them as ubytes into the texture memory?

See the GLX & Xlib specs for the nuts and bolts of GL/window interfaces on Linux.

Quote:

Original post by Tom Backton And another one: If I create a texture object with internal format GL_RGBA and every component's type is GL_UNSIGNED_BYTE, what will OpenGL do with the data? Will it convert the components to float and store them like this, as clamped 32-bit floating-point color components, in the texture memory? Or it will just copy them as ubytes into the texture memory?

It will convert them to some implementation-designated internal format - most likely one byte per component. You are exceedingly unlikely to get a floating point texture unless you explicitly request it (with an internal format of GL_RGBA16F/GL_RGBA32F/etc.).

Note that shaders treat all textures as if they are floating point, with the difference that integer textures are treated as normalised floating point values in the range [0, 1.0], while floating point textures are not clamped at all.

There is however a newer extension, EXT_texture_integer, which allows integer formats to be treated as integers in shaders.

Thanks for the answer :)

(unanswered questions: ___GetProcAddress() and Xlib definitions. I did read the specifications but the answers aren't there (visual types are an exception but everything else isn't there)

New questions:

When passing data to and from the GPU (vertex arrays, draw pixels, texture image or anything else), at lease in 32-bit systems, the data should be 4Byte-aligned. On 64-bit systems, should the alignment be to 8 bytes instead? In all cases?

http://www.opengl.org/wiki/Common_Mistakes#Misaligned_vertex_formats
Does this rule depend on the unpack alignment setting? If not, should I change the alignment of vertex format components to 8B in 64-bit openGL?

Here's an updated list of questions (icluding all the unanswered ones and some new ones):

1. http://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_(GLX)

I don't understand something. Before glXGetProcAddress() is called, a dummy context is created, but it is not made current. I thought there has to be a valid current context. Is it a mistake or glXProcAddress() only needs an existing context even if it's not current?
And what about WGL? wglgetProcAddress() can be called only after an RC is made current right? Another question: the OpenGL wiki says an RC cannot be recreated for a window, so after destroying the dummy RC I also need to recreate the window. But somewhere else I read a tutorial that doesn't delete the window. So I'm not sure...does the one-wglCreateContext()-per-window exist?

2. What are the definitions of Bool, True, False, XID and None in Xlib?

3. ATI suggests each element in a VBO starts on a 32 byte boundary. Does it mean the offset between the VBO's beginning and the element's beninning should be 32*n or that I can have an element start at offset 7 as long as it's 32 bytes long? (my program uses 16 bytes per element, so I'll probably interleave elements to avoid watsing 16B padding for every 16B vertex. The question is whether I should place more frequently used vertices as even-numbered elements so that they get the boost)

4. When passing data to and from the GPU (vertex arrays, draw pixels, texture image or anything else), at lease in 32-bit systems, the data should be 4Byte-aligned. On 64-bit systems, should the alignment be to 8 bytes instead? In all cases? Do GPUs work in 64-bit mode like CPUs?

5 - ANSWERED. http://www.opengl.org/wiki/Common_Mistakes#Misaligned_vertex_formats
Does this rule depend on the unpack alignment setting? If not, should I change the alignment of vertex format components to 8B in 64-bit openGL?

6 - ANSWERED. Are OpenGL's matrices made of doubles of floats? In other words, if I use glTranslated(), are the parameters converted to float?

[Edited by - Tom Backton on November 30, 2009 11:34:09 AM]

Quote:

Original post by Tom Backton 6. Are OpenGL's matrices made of doubles of floats? In other words, if I use glTranslated(), are the parameters converted to float?

Floats. All the double stuff converts to floats, at least until such time as the hardware actually supports doubles.

Thanks for the answer :)

5 questions left! (until I add more...)

[Edited by - Tom Backton on November 29, 2009 11:47:01 AM]

More questions...

7. What happens if I try to read a uint variable using glGetIntegerv()? Is it simply copied into a RAM uint variable? And what if I read an int64 variable?

8. There is a large set of images. An image is drawn as a texture object, using four (vertex, texcoord) pairs. They are written into a VBO. If they are not written as an array but at "random" offsets, which method is faster/recommended:
A. Save the four indices in an IBO and draw with glDrawRangeElements
B. Save the indices as a ushort array and draw with glDrawRangeElementsIn the first case I need to send the GPU an offset (64-bit integer) while in the second case I send 4 ushort variables (each 16-bit, in total 64 bits). The array length (4) is sent in both cases, so in total the same amount of data is sent. So I'd like to know which method you'd suggest/use...

Quote:

Original post by Tom Backton 5. http://www.opengl.org/wiki/Common_Mistakes#Misaligned_vertex_formats Does this rule depend on the unpack alignment setting? If not, should I change the alignment of vertex format components to 8B in 64-bit openGL?

No, the alignment is for the GPU, not for the CPU.

New questions:
9. So the alignment is 4B in 64-bit OpenGL too? And is the 4B alignment needed in VBO too?

10. Why do I see the parallel axis theorem in all collison detection tutorials? I can't see why it's better/faster than checking for every side of polygon A whether is collides with any side of polygon B. It also works for concave polygons, while the PAT only works for convex ones. If everybody uses PAT I'm probably missing something...

11. Why is dithering enables by default? If I assume the user has a modern video card which support 32-bit colors, is it a good idea to turn off dithering?

[Edited by - Tom Backton on November 30, 2009 12:38:17 PM]