GL_QUADS are very useful for things like particle systems and many billboarded distant objects (like trees) packed in a single draw call. It is also useful for drawing of text (each letter is one quad).
GL_QUADS allows us to avoid redundant index array - we would replace an indexed GL_TRIANGLES (with indices 0-1-2-0-2-3 -4-5-6-4-6-7 …) with a non-indexed GL_QUADS
If necessary clarify in the specification that they are actually 2 triangles (or even rename it to GL_TRIANGLE_COUPLES if needed).
Also if necessary, do not allow GL_QUADS to be indexed (that is glDrawElements generate error if GL_QUADS is passed to it)
I only speak about GL_QUADS and not about GL_QUAD_STRIP and GL_POLYGON. I don’t have objections about the deprecation of the latter.
I think the reason for the ARB to deprecate quads is, that they are indeed handled differently than 2 triangles. For example in wireframe they do not have the additional edge, that 2 triangles would have. This makes it more complicated to support in hardware.
I would not have any problems, if gl would simply turn quads into 2 triangles, even in wireframe mode. It would be better, than having no quads at all.
My guess is that there is an overhead in the drivers : it converts the quad to 2 triangles. Since it is fast, I guess they pregenerate an index buffer or something of the sort.
I did see someone mentioning QUADS are supported on workstation cards but I doubt it.
About the wireframe mode, i dont think anyone cares so much about it; it is mostly a debug functionality.
They could state in the specification that the implementation is free to do whatever it want in this case: it can remove the diagonal edges if it wishes so, but it is not required to.
A triangle is always on one plane, so there’s never an error. A quad can have an error (0,0,0) (1,0,0) (1,1,0) (0,1,92)
Does not lie on a plane and is broken. I guess they didn’t want to support that possibility.
This is not an issue.
The specification have never had any requirements about the way the implementations can choose to handle polygons except that the polygon’s projection on the screen should lie withing the convex hull of the projection of the vertices.
In practice all implementations regard the quads as 2 triangles.
No one needs and no one provides any special support for “broken” (i.e. non-coplanar) quads.
In the case where you pass 4 non-coplanar vertices you just get 2 non-coplanar triangles and thats all. Not a big deal.
Actually I can’t think of what would such a special support do.
Try to somehow make the quad coplanar or what?
Why do you imply that moving forward and keeping the quads are mutually exclusive?
Lets move forward AND keep the quads!
Of course if the quads are somehow an obstackle for the progress, we better get rid of them. But if this is not the case, why should we drop such a convenient feature?
Do you know of a reason why the quads can be a trouble for the vendors to implement? AFAIK both ATI and NVIDIA already have hardware support for it.
“may not” is different from “will not”
Exactly this was my point with this suggestion thread.
I was giving reasons why it would be good to retain the quads, hoping to influence the decision of the ARB and/or the HW vendors to deprecate them.
At this point “moving forward” does not exclude quads yet.
Even in the future if they really drop the quads from the hardware, they can still reintroduce them again later.
In any case you can’t just label certain feature “incompatible with the future” without very good reason. And there is no good reason for labeling the quads this way.
But not by the CPU. The post T&L subsystems of the hardware understand QUADS and can turn them into triangles with little if any performance penalty. The question is how long they will continue to have that hardware in place.
Why converting them to triangles? The quadrilateral interpolation might be useful if supported. However this is somewhat rarely used stuff so taking it away from the core and putting it into an extension seems reasonable. Personally, I would use something else for particles e.g. point sprites or a geometry shader emitting two triangles (this might be one of the cases the geometry shaders are optimized for).
And without pretending to be very competent in the hardware design matters, i think that a hardware support for this feature is very cheap in terms of transistor count, die size, etc. for the today’s standards. It is nothing when compared to the hundreds of stream processors, each consisting of many-bit wide ALUs with fat dividers, multipliers and what not.
I think the usefulness of this feature absolutely well justifies the extremely tiny percent of the GPU die that it costs.
Of course if they anyway have HW support for someting better than converting to 2 triangles, they will use it.
Personally, I would use something else for particles e.g. point sprites or a geometry shader emitting two triangles (this might be one of the cases the geometry shaders are optimized for).
Point sprites are not useful if your particles aren’t camera-facing (as are ours).
Geometry shaders - i havent got the time to read about them yet, so i dont know
Now that you mention it, the GSs may indeed be able to do the job of the quads.
If this is the case, that would invalidate my objections about the deprecation of quads.
I should read about the GSs soon.