Talk:FAQ

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)

Purely speculative.

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)

Restructuring

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)

The reason Wikipedia forbids the use of punctuation in section titles is that it makes them easier to link to. If this page is going to become something more than just an random bag of information, then that information needs to be easily indexable. If I know the section name, I shouldn't have to find the wiki page and go to that section just to find out what oddball characters Wikipedia replaces the "?" with. I should just be able to type "Page Name#Section Name", just as I do with regular pages.

As for the original FAQ, I don't care. What was done on the original site is irrelevant; what matters is what works best for our needs. Alfonse (talk) 08:33, 30 September 2012 (PDT)

Is it always the case that Wikimedia replaces "?" with ".3F" http://www.opengl.org/wiki/FAQ#What_is_GLU.3F? Is that browser independent? I've not much experience with Mediawiki yet so I'm puzzled that they themselves provide a FAQ.

MediaWiki and Wikipedia are different things. MediaWiki provides the software for Wikipedia, but Wikipedia has its own additions/modifications as well as its own rules. Also, I'm sure the escape characters are not browser-specific; otherwise, links wouldn't work correctly. They just don't use the established HTML standard. Alfonse (talk) 08:59, 1 October 2012 (PDT)

If we don't want punctuation but still want to call the page a FAQ, we could reinstate the questions within the subsections. Not pretty, obviously but at least we achieve both, consistent referral and showing questions to answer to. On the other hand, we could factor the whole thing into pages that explain the same stuff non-FAQ style and link to that. If people are looking for something specific they're probably use the search function anyway in which case it should be irrelevant if it a section heading is formulated as a question or a statement. This would basically solve all our problems. In any case, we'd have to rewrite major portions anyway so why not put the whole thing to rest and reuse stuff that's currently good and rewrite the rest? thokra (talk) 06:39, 1 October 2012 (PDT)

The problem for me is a purely technical one: the conversion of '?' into something else. If you want a section title to be in the form of a question, that's fine (as long as it doesn't leak into non-FAQ areas of the wiki). It's the use of punctuation that's the problem. I don't believe that people should have to know what arbitrary escape sequences MediaWiki uses for punctuation in section names. Alfonse (talk) 08:59, 1 October 2012 (PDT)

That's fine with me. But it still leaves the question of how to make the page appear as a FAQ without punctuation if we can't work around the special characters. Therefore my suggestion would be to distribute the useable info in FAQ across suitable existing topics or create new ones. Also, we would need to rewrite the not so glorious stuff. thokra (talk) 09:29, 1 October 2012 (PDT)

That goes back to the question of having a FAQ to begin with. The point of a FAQ (to the degree that there is a point to having one) is to have the information be easily indexable and queriable. You can link someone directly to what they're looking for. I can't see this kind of information being well integrated into the more documentation style stuff found on the rest of the Wiki. We're talking about the difference between "providing information" and "solving someone's specific problem."

For example, What 3D file format should I use? OpenGL doesn't handle file format processing, so none of the documentation pages would ever cover it. Where would it go? On some page about suggested practices? And what about the question on common build errors, like unresolved externals and such? That's really a general programming question, yet there it is. The question is one of organization; much of the stuff on this page is here because they are frequently asked questions. Scattering the information across the wiki would make it harder to find, thus defeating the purpose in building a FAQ to begin with. Alfonse (talk) 00:06, 2 October 2012 (PDT)

I'm not quite sure if we're on the same page here (no pun intended). As far as I understand you, your technical concerns are related to web indexing, as done by search engines and probably the wiki engine itself, and manual linking by adding links to known (by you) pages during posting to the forums - especially the latter being simplified by leaving out special characters so "Page#Section" is applicable when knowing the section title. Correct?

Technical difficulties aside, we can already go ahead and improve the current content without touching the sections or the general organization of the page - the information will stay valid and will be useful no matter what we decide to do in the end.

You were asking about "distribute the useable info in FAQ across suitable existing topics or create new ones", which is very different from merely improving the current content of the page. You don't need permission to edit some particular FAQ entry, so long as the changes are valid. You gave the impression that we were discussing something more substantial. Alfonse (talk) 14:58, 2 October 2012 (PDT)

One other thing that struck me as inconvenient is that the way of reaching the FAQ via the main page, by clicking through the wiki that is, may need two indirections, i.e. Main->Getting Started->(maybe)Getting Started#FAQ->FAQ. Also, it is debatable if the FAQ should be linked to in "Getting Started" as most questions usually pop up after you've already started. How about linking to the FAQ on the main page instead? thokra (talk) 02:24, 2 October 2012 (PDT)

I was about to say that you could do that yourself, but then I remembered that the front page is protected from editing by anyone without admin privileges. Personally, there's a lot to dislike about the front page (the Wiki is not a FAQ dumping ground). I'll see what I can do. Alfonse (talk) 14:58, 2 October 2012 (PDT)

Rendering a Cube is terrible advice.

I'm removing the following:

---

This question comes up often since there seems to be a lot of users rendering a lot of cubes. Just like the above section explains, OpenGL supports one index for a Vertex Attribute (a vertex attribute is position, normal, texcoord, etc).

Since a cube's face is flat, a user would want flat shading on each face. This means having 1 normal per face. However, GL wants 1 normal per vertex. The best solution is as the above section explains, duplicate the vertex because once one of the attributes is different, it is considered a completely different vertex. Another alternative is to do the following :

//The following code is for GL 2.0
//Render face 1
glNormal3fv(mynormal1);  //Set your face normal
glBindBuffer(GL_ARRAY_BUFFER, VertexVBOID);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, sizeof(MyVertex), BUFFER_OFFSET(0));   //The starting point of the VBO, for the vertices
glClientActiveTexture(GL_TEXTURE0);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2, GL_FLOAT, sizeof(MyVertex), BUFFER_OFFSET(12));   //The starting point of texcoords, 12 bytes away
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, IndexVBOID);  //Bind the IBO
glDrawElements(GL_QUADS, 4, GL_UNSIGNED_SHORT, BUFFER_OFFSET(0));

//Render face 2
glNormal3fv(mynormal2);  //Set your face normal
//We can just call glDrawElements since the rest of the setup is already done above
glDrawElements(GL_QUADS, 4, GL_UNSIGNED_SHORT, BUFFER_OFFSET(16));

//.... and render face 3 and 4 and 5 and 6

In the above code, the disadvantage becomes clear. We can only render 1 quad at a time. It requires 6 calls to glDrawElements just to render a single cube. Another problem is that you are using glNormal3fv which doesn't fetch its data from a VBO!

So what are the savings? For each face, you only needed memory space for 1 normal. Your savings are = 3 normals * 3 floats * 4 bytes_per_float * 6 faces = 216 bytes saved per cube.

---

This is just terrible advice. Alfonse (talk) 02:09, 21 September 2017 (UTC)