Quads vs Tris - Impact on Hardware Rendering?

[The Lamb]

The original article I read covering this was posted before programmable vertex shaders and the like where on the scene, so I can see how the direction of accelerated 3D has changed since then.

Many thanks guys, this has been most informative!

 

[fresh]

There's no point to have specific quad support. As Simon F said, you cant guarantee that a quad is planar and then all your interpolators are f'd. You can emulate a quad with a trifan, which is what I suspect most (all?)hardware does. It's still a bit of a problem though cause you can draw a quad 2 different ways as a trifan, and they would look slightly different with interpolated shading.

 

[psurge]

I think that's why Simon F said it would be better to split into a quad into 4 triangles (presumably using the quad center as an extra vertex?)

Serge

 

[Humus]

There's no point to have specific quad support. As Simon F said, you cant guarantee that a quad is planar and then all your interpolators are f'd. You can emulate a quad with a trifan, which is what I suspect most (all?)hardware does. It's still a bit of a problem though cause you can draw a quad 2 different ways as a trifan, and they would look slightly different with interpolated shading.

Well, if you're using quad lists then you can save many indices.
Something I'd like to see would be automatic quadification (just invented that word ), that is, the last vertex for each quad is not stored but instead evaluated as v1 + v2 - v0. Would save 25% bandwidth and storage space for quads.

 

[Simon F]

Well, if you're using quad lists then you can save many indices.
Something I'd like to see would be automatic quadification (just invented that word ), that is, the last vertex for each quad is not stored but instead evaluated as v1 + v2 - v0. Would save 25% bandwidth and storage space for quads.

Humus,
I'm assuming that these would then be converted to strips and, if so, there's a couple of things in that scheme that I'm not keen on. Each implied vertex would depend on all the previously defined vertices and so (a)You'd run the risk of accumulated errors and (b) you wouldn't have random access (should you need it).

I think that's why Simon F said it would be better to split into a quad into 4 triangles (presumably using the quad center as an extra vertex?)

You beat me to it I see.
Actually, even for geometrically planar quads this is useful for cases where the texturing is non-linear.

 

[KimB]

I still don't see any reason not to go strips for terrain.

There are two reasons for this:

1. It seems to me that the simplest thing to do would be to always render an entire terrain mesh, that is composed of a single strip (using degenerate quads/tris at edges). This list would be used solely for rendering, and a separate triangle list may be used if random access becomes necessary.

2. As long as the strip is only used for rendering, and is always rendered as a whole, I can't think of any situation where this would be cumbersome in programming. Collision detection, for example, could use a separate list that is optimized for that purpose.

 

[Dio]

Something I'd like to see would be automatic quadification (just invented that word ), that is, the last vertex for each quad is not stored but instead evaluated as v1 + v2 - v0. Would save 25% bandwidth and storage space for quads.

That's potentially an interesting idea.... but I'm wondering if the mesh would crack and / or texture seams would appear...

 

[Simon F]

Humus,
Thinking a bit more about your suggestion, it now seems overly restrictive. You're limiting the primitive to being a parallelogram where in fact the 4th point need only be a linear combination of the first 3 (as long as the result is still convex, of course !!)

 

[Humus]

Well, I didn't suggest that all ways of defining quads that currently exist should be removed. It was just an idea of how one can optimize a very common special case.

 

[Humus]

Humus,
I'm assuming that these would then be converted to strips and, if so, there's a couple of things in that scheme that I'm not keen on. Each implied vertex would depend on all the previously defined vertices and so (a)You'd run the risk of accumulated errors and (b) you wouldn't have random access (should you need it).

I was mostly thinking of plain quad lists, not strips. For strips you'd have to use another scheme:

v0 -- v2 ------- v3 -- v5 --- ...
 |     |          |     |
v1 -- implied -- v4 -- implied - ...

 

[Humus]

Something I'd like to see would be automatic quadification (just invented that word ), that is, the last vertex for each quad is not stored but instead evaluated as v1 + v2 - v0. Would save 25% bandwidth and storage space for quads.

That's potentially an interesting idea.... but I'm wondering if the mesh would crack and / or texture seams would appear...

It should be fine for quad strips as shown above. It should also be fine for anything that's indexed unless I'm overlooking something. For unindexed quad lists it may cause some pixel leakage though I suppose since an implied and actual vertex may not match.

 

[Simon F]

I was mostly thinking of plain quad lists, not strips. For strips you'd have to use another scheme:

v0 -- v2 ------- v3 -- v5 --- ...
 |     |          |     |
v1 -- implied -- v4 -- implied - ...

I've got my doubts with this too. If the system is 'symmetrical' then the first 'implied' vertex would have to satisfy
V1+V2-V0 = V4+V2-V3 => V1-V0 = V4-V3

and so all the 'vertical' edges of the strip would have to be parallel and the same length. I suppose you could relax the conditions so that only the first of every pair was a parallelogram but you'd still have the condition that vertical edges would have to be parallel... but that'd be a general restriction for quad strips anyway.

That's also only achieving 1 quad every two vertices which is the same as triangle strips.

 

[KimB]

That's also only achieving 1 quad every two vertices which is the same as triangle strips.

No, that's 1 quad every 1.5 vertices (alternating two and one required vertex per added quad).

 

[Simon F]

That's also only achieving 1 quad every two vertices which is the same as triangle strips.

No, that's 1 quad every 1.5 vertices (alternating two and one required vertex per added quad).

Oops!
/me goes off to get more coffee.....

 

[Rodéric]

useless plug.
At last something worth the read.

 

[Humus]

I was mostly thinking of plain quad lists, not strips. For strips you'd have to use another scheme:

v0 -- v2 ------- v3 -- v5 --- ...
 |     |          |     |
v1 -- implied -- v4 -- implied - ...

I've got my doubts with this too. If the system is 'symmetrical' then the first 'implied' vertex would have to satisfy
V1+V2-V0 = V4+V2-V3 => V1-V0 = V4-V3

and so all the 'vertical' edges of the strip would have to be parallel and the same length. I suppose you could relax the conditions so that only the first of every pair was a parallelogram but you'd still have the condition that vertical edges would have to be parallel... but that'd be a general restriction for quad strips anyway.

I don't see the problem with these requirements. It would still cover the most common cases where quadsstrips where to be used.

 

[Dio]

Something I'd like to see would be automatic quadification (just invented that word ), that is, the last vertex for each quad is not stored but instead evaluated as v1 + v2 - v0. Would save 25% bandwidth and storage space for quads.

That's potentially an interesting idea.... but I'm wondering if the mesh would crack and / or texture seams would appear...

It should be fine for quad strips as shown above. It should also be fine for anything that's indexed unless I'm overlooking something. For unindexed quad lists it may cause some pixel leakage though I suppose since an implied and actual vertex may not match.

Not sure again.

(I had to lose the | markers because I couldn't get them to work)

v0 ----- v2 ------ v3 ----- v5 --- ...
v1 -- implied1 -- v4 -- implied2 - ...

if you think the next line

v1 -- implied1a -- v4 -- implied1b - ...
v10 --- v11 ------ v12 ---- v13 - ...

Then to generate without cracks, the implied vertices generated by v0, v1, v2 must be the same as those generated by v1, v10, v11.... which isn't guaranteed even if they are indexed quad strips.

 

[KimB]

(I had to lose the | markers because I couldn't get them to work)

Try putting them within a

 block.

Anyway, as for the times when quad strips are used, I'm not entirely sure, Humus.  It looks to me that this technique would only be useful for drawing cylinders.  Terrain wouldn't work, I don't think, as even if the x/y coordinates could be interpolated in this fashion, the z coordinate could not.

 

[Dio]

Goes to show what a great programmer I am.

 

[Humus]

Well, a little brainstorming never hurts, but I suppose the benefits of this are too small to try to patch all the problems it would give. Maybe wasn't as useful as I initially thought.