Tom: The big advantage of using quads is when you can use a quadlist. Say for a large particle system. It means you have to specify only 4 indices indices for each quad.
Using a trilist it would be 6 indices, using a tristrip it would be 6 each as well. This means the CPU will have 50% more work copying the indices across.
Now even better, why have indices at all? Each vertex might very well be unique anyway, and the cache certainly isn’t going to help. So you could simply create a vertexarray with all your data, and the CPU will have to copy exactly 0 indices.
Since copying the indices is pretty much the only thing the CPU still has to do (when using VAR) this can be a huge speedup on the CPU side.
>>There is no possibility to explicitly define a quad strip in GL, but there is no need of that.<<
Huh? Of course there is a GL_QUAD_STRIP primitive. And one useful aspect for this is with flat glShadeModel(GL_FLAT) resulting in quads and look nicer than triangle strips in many cases.
>>If you use GL_TRIANGLE_STRIP instead, you draw triangles and you still send only 4 vertices<<
As said above GL_QUADS look diffferent with flat shading and furthermore GL_QUADS are independent primitives, which means you don’t need to call glBegin-glEnd or your vertex arrays drawing command for each one but a batch of multiple which has a lot less overhead.
Yes, emulating GL_QUADS with GL_TRIANGLES is stupid , can result in different rendering results (flat), and any other primitive except real GL_QUAD_STRIPs has more calling overhead.
Originally posted by Relic: …you don’t need to call glBegin-glEnd…
You know what: yesterday, I wanted to post the message I posted one hour ago and I thought: “you stupid crazy, strips need Begin/End so it is likely to be slower !”.
Then, I re-read the thread this morning, think the same thing and … forget to think about it twice !!!
Thanks Relic, and sorry to the others for this non-post…
Regards.
Eric
P.S.: actually, I think I had this idea because I work with quads on a CFD post-processor, and in this case, I use quad strips… That’s why my brain refused to work: for me, I can use quads strips or triangle strips indifferently…
[This message has been edited by Eric (edited 01-10-2002).]
The ideal solution is to create as many triangle strips from your model as possible (from all polygons). This however becomes pointless if your strips only contain a few vertices. The number of calls required to draw each strip in your model seems less sensible than making just a few calls with large amounts of geometry.
If your model does not appreciate strips that much, then the next best solution IMO is to treat all polys as triangles and use one call to draw the entire model with triangles and vertex arrays.
GL_POLYGONS should be avoided at all cost. GL_QUADS give you rendering errors if your polys are non-planar, so you may as well use triangles. Making a strip from a quad is fairly pointless. It’s not going to make much difference in speed other than by enabling you to determine how the quad is split when it hits hardware. The other big issue is why do you want to send a single quad on its own to gl anyway? It’s slow. If you really must use quads then batch them all together and send them in one go, splitting them into strips will just cause problems, and not allow you to do the same batching.
I personally batch polygons via material types. Each material is set, then the geometry is drawn. The main philosophy behind drawing them, is to then make as few calls to draw the geometry as possible. If the average number of verts per triangle strip is below a certain threshold then the entire vertex array is drawn in one go with triangles.
Originally posted by Alain: If you have a flat quad ABCD, then it’s the same as two triangles ABD and DBC. And if you put them in a triangle strip, then you’ll have exactly the same number of vertices to send: 4, and not 6.
Aaarrghh… nooo…
The crucial difference is that in this case you can draw X thousand independent quads WITH ONE CALL. With triangle strips you could only draw one “quad” per call, so you’d need X thousand calls. That’s insane.
There isn’t a canonical metric for the “best” arrangement of a chunk of geometry, but minimizing the number of API calls is typically AT LEAST as important as minimizing the number of vertices.
Originally posted by Rob The Bloke: The other big issue is why do you want to send a single quad on its own to gl anyway?
Drawing uniquely-textured billboards is an obvious example. Though in this case the GL_QUAD vs GL_TRIANGLE_STRIP issue is completely irrelevant when set against the cost of the texture bind.
If the average number of verts per triangle strip is below a certain threshold then the entire vertex array is drawn in one go with triangles.
If the average is low AND the distribution is fairly even, yes. If the distribution isn’t even, it might well be better to draw any “good” strips you can make as strips, and just bundle up the small ones into one big GL_TRIANGLES batch.
MikeC: I know it would be insane in case of X thousand calls. I was thinking about single quads as in your bill-boarding example.
Recently, I had to correct some code (written by somebody else) which tried to optimize rendering by converting all strips of 2 triangles into quads. The bug was that it did not check if the resulting quad was flat, which then produces weird effects.
My experience would make me advise against using quads. I have never seen them giving any advantage, except maybe if you have hardware specially optimized for quads, which is not the case of current PC boards like GeForce 2/3.
The difference is that for both primitives the last “subprimitive” vertex is taken for the filling color.
That is for four vertices the third and fourth for triangle strips and only the fourth for quads.
I didn’t say anything about lighting. And supplying the same normals doesn’t result in the identical flat shaded image either with non-directional lighting or local viewers.
You’re right four Gouraud shading (and still then you have no control about the tesselation of quads into trinangles by the implementation, so your results may vary if the four colors don’t end up to be planar in RGB-space.
, can result in different rendering results (flat), and any other primitive except real GL_QUAD_STRIPs has more calling overhead.