This page needs an enema. The glh stuff needs to go away; this is a site for OpenGL, not someone's random helper library for OpenGL. Several of these "questions" are poorly asked and poorly answered. I'm not a big fan of a large FAQ to begin with, and this one isn't helping matters. Alfonse 09:01, 15 August 2009 (UTC)
- There is also a lot, lot of information that is just flat-out wrong. Some of it is out-of-date, but others is just wrong. Alfonse 18:12, 16 September 2009 (UTC)
- The FAQ is indeed horrible. Working on this page makes me want to can the whole thing. The correctness of the information, the wording, the section headers, the formatting - it's all sub-optimal to be diplomatic. Do we really want this page? If so, we should either attempt to really fix it once and for all or to do a complete rewrite. thokra (talk) 01:25, 27 September 2012 (PDT)
- I'd feel uncomfortable with making any major changes without V-Man's involvement, since he basically writes and maintains it (to the degree that it is maintained beyond simply being a junk drawer). He also links to parts of it frequently on the forums, so any major restructuring will break those links. Alfonse (talk) 09:54, 27 September 2012 (PDT)
- The question is, what good are valid links to partly invalid pieces of information? Yes, an overhaul will make a lot of links useless but we'll end up with something much more valuable. I'm not seeking to diminish V-Man's efforts on this page - however, we can do a lot better than this. I've sent a PM to him in hopes that he'll take part in the discussion. thokra (talk) 04:59, 28 September 2012 (PDT)
Nooo, this page has been really useful to me! It makes things clear like too few FAQ pages do. Mowsala 11:20, 21 April 2010 (UTC)
I removed the following text, since it is entirely speculative, and therefore not appropriate for a FAQ.
GL has supported GL_QUADS and GL_QUAD_STRIP since version 1.0, but as you already might know, this doesn't necessarily reflect what the hardware is capable of. Pretty much all GPU only support GL_POINTS (probably with pixel size 1 only), GL_LINES (probably with pixel size 1 only), GL_TRIANGLE_STRIP and GL_TRIANGLES. GL_TRIANGLE_FAN has also been a candidate for dropping support for. GL_POINTS with pixel size bigger than 1 are emulated. Probably by rendering triangles. GL_LINES with pixel size bigger than 1 are emulated. Probably by rendering triangles. GL_QUADS are emulated by breaking the quad into 2 GL_TRIANGLES or 1 GL_TRIANGLE_STRIP. The same applies to GL_QUAD_STRIP. This is because the primitive assembler doesn't understand quads. The rest of the GPU pipeline isn't designed to deal with quads either (the interpolators of the GPU). Triangles are preferred because there are well known and very fast hardware algorithms to render them. That is the reason why in GL 3.0, quads became deprecated. It is highly recommended that you render your triangles as GL_TRIANGLES. It is highly recommended that you use glDrawElements or glDrawRangeElements. This way, you can render a large mesh made up of thousands of triangles with a single call to glDrawElements or glDrawRangeElements (if all those triangles need the same shader and the same textures). For the case of GL_TRIANGLE_STRIP, GL 3.1 makes a new feature available called primitive restart (glEnable(GL_PRIMITIVE_RESTART) and glPrimitiveRestartIndex). With that, you can render an entire mesh made of many triangle strips with just a single call to glDrawElements or glDrawRangeElements. For GL_TRIANGLE_STRIP, you would need a triangle stripper such as NvTriStipper. There is also Forsyth's algorithm. We recommend that you search the forums here at www.opengl.org or do some reading since it is a complex topic. For GL_TRIANGLES, you would also have to optimize your index and vertex arrays.
- For an example of speculative text, there is no evidence that the primitive assembler in hardware "doesn't understand quads". Indeed, it most certainly does. It is the rasterizer that does not understand quads. The rasterizer must convert quads into triangles. So it is highly unlikely that this was "the reason why in GL 3.0, quads became deprecated" Alfonse 13:38, 11 March 2011 (CST)
Things that shouldn't be here
I copied a section of this FAQ to the Performance article. The original is still here, since the question after doesn't make sense without it, and I am not sure what to do with that one. There are more things here that doesn't belong in a FAQ, but are still useful. They should be moved into other articles.
EDIT: I removed it, and moved the following question to the performance article as well. There are still a lot of things here that should be moved elsewhere. Some of them could be moved to the Common Mistakes page, but that one is already a mess.
There are sections here that aren't really answers to questions. Some explain common mistakes (but the common mistakes article is a big mess, no need to move things there as it is now), and some just give general tips. --Zyx 2000 11:15, 14 June 2011 (CDT)
If we are going to do a restructuring of this page, then we need to have a discussion about what that entails. Personally, I don't much like FAQ pages, but that's neither here nor there.
One thing we should keep to is the Wikipedia style guide for section names. Specifically, not having punctuation in section titles. And while rewriting this stuff, don't forget our own style guide. (feel free to edit or discuss it if you don't like some of the rules). Alfonse (talk) 16:52, 28 September 2012 (PDT)
- For the section names, I don't think it would make much sense to not have punctuation in there since it is a FAQ. Normally, FAQs have a few section that are in the style of "question" and "answer". See the old FAQ http://www.opengl.org/archives/resources/faq/technical/. Pretty much every section is a question. V-man (talk) 03:35, 30 September 2012 (PDT)