Quads vs Tris - Impact on Hardware Rendering?

[The Lamb]

I noticed an article ages ago, here on B3D I think, which mentioned a future move to using quads instead of triangles for general 3D hardware acceleration.
I vaguely recall efficiency or ease of programming being mentioned as the reason for this.

I wonder if anyone could enlighten me further. This question came up on the Chumbalum-soft Milkshape3D forums, and the first place I thought of for clarification was here!

Thanks!

 

[Tahir2]

I thought the quad idea was dead as a dodo. :?

 

[Humus]

Depends on what you mean. If you mean quads such as in glBegin(GL_QUADS); ... glEnd(); then I don't see quads as being dead in any way. I'm actually slightly annoyed that DirectX even at version 9 still do not support quad primitives.

 

[KimB]

Quads are very useful in specific circumstances.

But quads replacing triangles as the basic primitive is just a bad idea. Quads just aren't good for representing every kind of primitive, and you'd be forced to send the GPU lots of degenerate quads for lots of geometry, increasing bus traffic.

 

[Tagrineth]

Quadratic primitives... whoo... look at Sega Saturn for the most famous implementation of those.

There are good reasons for them being dropped in favour of triangles.

The one advantage they really have is that they can represent 100% accurate curves...

 

[Ostsol]

One good use for them over triangles is that it takes less indices to draw a single square with them. With triangles a square takes six vertex indices, unless one uses triangle strips or fans. In the latter two cases, though, one must draw each strip or fan individually with a separate render call. Using individual triangles or quads one can simply use a single call to draw the entire list, but it takes less indices using quads. Of course, a quad where the vertices are not co-planar is merely turned into a pair of triangles. . .

 

[Tagrineth]

Of course, a quad where the vertices are not co-planar is merely turned into a pair of triangles. . .

...that depends on your primitive support.

 

[Ostsol]

Of course, a quad where the vertices are not co-planar is merely turned into a pair of triangles. . .

...that depends on your primitive support.

I'm talking about current hardware. Frankly, I'd rather see hardware support for NURBS rather than curved quads.

 

[KimB]

One good use for them over triangles is that it takes less indices to draw a single square with them. With triangles a square takes six vertex indices, unless one uses triangle strips or fans. In the latter two cases, though, one must draw each strip or fan individually with a separate render call. Using individual triangles or quads one can simply use a single call to draw the entire list, but it takes less indices using quads. Of course, a quad where the vertices are not co-planar is merely turned into a pair of triangles. . .

A Quad strip and a triangle strip will pass the exact same number of vertices for rendering.

Only with triangle and quad lists will the triangles require more, but the bus traffic becomes inconsequential for indexed lists, and vertex caches will take care of the added number of vertices referenced.

 

[Ostsol]

A Quad strip and a triangle strip will pass the exact same number of vertices for rendering.

Only with triangle and quad lists will the triangles require more, but the bus traffic becomes inconsequential for indexed lists, and vertex caches will take care of the added number of vertices referenced.

Yep, I know that the vertex count is the same, but the index count isn't. That's one problem I encountered when I was using element arrays for my terrain rendering. That's >6 MB for the indices for a 512x512 terrain segment, using triangles. If I use quads that's reduced to 4 MB. It's a moot point right now, though, since I think I'm going to change my engine even further and use a quadtree instead of an octree. That way, I can just reuse my indices for each terrain segment.

 

[Nappe1]

something from the past...

Quads from Direct 3D / Glide accelerated game from year 1999:
http://rp-design.totalnfs.net/pics/mcssnow.gif

that mesh as well as making the editor editing it, has took a way too much of my free time, and most likely will take as well in the future.

 

[KimB]

Yep, I know that the vertex count is the same, but the index count isn't. That's one problem I encountered when I was using element arrays for my terrain rendering.

Shouldn't it be easy to use strips for terrain rendering? With this, there would be no difference between quads or tris.

 

[Colourless]

Problem with curved quads is the same as n-patches... how do you interpolate. How do you know how curvy a quad should actually be, and additionally with quads, you need to know which way the curve goes, convex or concave.

 

[Simon F]

One good use for them over triangles is that it takes less indices to draw a single square with them. With triangles a square takes six vertex indices, unless one uses triangle strips or fans.

And since most systems now support either strips and/or indexed meshes that point it pretty much moot.

Assuming the quads are planar, the question is what form of interpolation of texture/shading coordinates are used. If the texture/shading values are also coplanar then the system can re-use the existing triangle texture mapping HW. In this situation, the advantage of quads over two triangles would be that the shared edge would be eliminated which'd lead to slightly better efficiency when texturing.

If the quad is not planar (in any dimension), then it could be considered to be a bilinear patch, in which case you might as well handle it as a higher order surface.

 

[PSarge]

Quadrilaterals (4 sided polygons) != Quadratic Patches

 

[Dio]

If you assume they are flat then the rasteriser can handle them quickly - but if they aren't flat things can go wrong. Determining if they're flat is non-trivial... not least because of rounding issues which makes the whole idea of 'flat' pretty vague when you get near edge-on. You also have to handle barycentrics (a form of primitive-space coordinates) with 4 coordinates instead of 3 (or whatever your equivalent interpolation model is).

As a result, the rasteriser seems likely to get both more expensive and more complex, so do your interpolators, and the gains are pretty nebulous - access coherency and granularity losses improve a bit, don't know if there's any others. So why bother?

 

[Simon F]

FWIW, the original Tomb Raider code had triangles and planar quads as primitives. In the PVR port, I tested each quad to see if the texturing and lighting was also 'planar', and if so sent it to the HW as a 'quad'.

If the texturing was non linear, then I split it into two triangles. It would have been better to convert them into 4 triangles but, hey, this was running on a 90Mhz P90!

 

[K.I.L.E.R]

Of course, a quad where the vertices are not co-planar is merely turned into a pair of triangles. . .

...that depends on your primitive support.

LOL! I bet that was an intended pun.

 

[LeStoffer]

Frankly, I'd rather see hardware support for NURBS rather than curved quads.

Well, with the growing support and use of Sub-division surfaces I have a strong feeling that we won't see hardware support beyond the good old polygons (and triangles over quads) for a forseeable future.

We won't have silicon to spare to implement these features with all the shader ops power we will need in this timeframe IMHO.

 

[Ostsol]

Yep, I know that the vertex count is the same, but the index count isn't. That's one problem I encountered when I was using element arrays for my terrain rendering.

Shouldn't it be easy to use strips for terrain rendering? With this, there would be no difference between quads or tris.

Technically, yes, but it takes more effort to make it work with octrees. I'd have to go through alot of work to combine triangles into strips, which is made more difficult by the fact that a single octree node could have several patches of terrain, the very tops of several peaks. For quadtrees it'd be pretty easy, of course, which is another reason why I'm moving towards them.