Does my card turn everything to triangles?

Hello.
I was wondering wether my graphics-card (GeForce2) turns everything into triangles?
I am drawing a lot of quads (particles) and was discussing the fastest method with somebody. He said that GL_TRIANGLE_STRIP would be the fastest because the card wouldn’t have to turn it into triangles anymore. However GL_QUADS turned out to be faster.
Also, when I have GL_LINE for glPolygonMode() I see genuine quads for GL_QUADS and 2xtriangles for GL_TRIANGLE_STRIP. Still I don’t know wether my card draws actual quads.
Well, that was a lot of talking, I hope you remember my question.
Thanks for any reply!

[This message has been edited by B_old (edited 01-22-2003).]

From what I understand graphics cards are faster at drawing triangles but can still draw quads or other polygons. I dont know if it actually turns other polygons into triangles. Thats just seems that It would be expensive computationaly. Someone correct me if I’m wrong because I also do alot of quad drawing and not too many triangles

I’m not certain, but I’d be willing to bet a fair amount on money on the fact that the GeForce 2 turns quads into triangles before rasterizing. I doubt you’ll see a speed increase from switching to tris though.

i keep hearing people saying that they are switching to do things in quads. They seem smart.

I draw all my particles as quads. It seems smarter than triangle strips, since both ways you send as many vertice to the card, but when useng quads you can get away with only one glDrawElements or glBegin/glEnd call. I think this matters more than the card having to split a quad into two triangles, but I’ve never aactually tested this.

-Ilkka

This is old news, but 3Dfx hardware (Voodoo 1-3, at least) only supported triangles (even lines were drawn with triangles, I think). After examining the GLIDE source (open source), I better understood how the hardware works (I even think the triangle setup was performed in SW - i.e. turn triangle vertices into scan line start-stop coordinates - but I may be wrong).

I’m pretty certain that most HW only supports triangles. The OpenGL spec is written in a way so it should be possible to implement all primitives with only triangles (lines/points may be better handled by using dedicated HW though). For instance, only convex polygons are guaranteed to render correctly.

In the end, I think that what really matters is how you pass the vertex information to the driver/card. You can probably think of quads as a special way to draw triangles (like tristrip or trifan). If the calling/data overhead is less with quads than with triangles, it will probably be faster.

It’s just a personal opinion, but…

Quads are evil. So are polygons.

This actually is directly relavent to the topic at hand since most cards that I am familiar with do do some sort of quad-to-triangle conversion, either in the driver or in the hardware itself. This is a problem because there are two equally valid ways to convert a quad to triangles, and many different ways to convert a polygon to triangles. This causes (at least) two types of potentially undesirable behavior.

First, unless you’re very careful to ensure that all four vertices of your quad lie in the same plane, you’ll can get potentially results. Yes, I know you’re not supposed to send non-coplanar vertices, but it can happen if you’re not careful. Since a triangle cannot have three non-coplanar vertices, that’s one fewer thing to worry about.

The next problem can’t be so avoided even if you are careful. Consider the quad with the following colors…

v1=RED v2=BLUE
±-----------------+
| |
| |
| . |
| |
| |
| |
±-----------------+
v0=BLUE v3=RED

What color is at the center of the rasterized quad (the dot in the diagram above)? You really can’t tell, other than to say that it’ll be either solid blue (if the trianglation results in the two triangles v0-v1-v2 and v0-v2-v3) or solid red (if the triangulation results in the two triangles v0-v1-v3 and v1-v2-v3). Things get even worse when the quad starts to get clipped.

I’m sure there are times when quads are the best way to send your geometry, but given the choice I’d go with triangles or triangle strips…

– Ben

Ben,

In extension to your argument, being ‘planar’ does not only mean that geometry coordinates are planar. Colors need to be planar too, tex coords, fog weights, even normals (though it’s hard to explain planar normals right here).

Quads are evil.

A gfx card may rely on the quad being planar and partly skip some triangle setup work, that could explain a performance advantage.

These are good points, but for god’s sake, the guy just wants to do some particles. It’s very easy to get all that stuff planar with them, you propably manage to do it even if you’re not trying to. In general quads should be avoided, but with particles, I think, they’re very acceptable.

-Ilkka

Don’t be afraid of using quads, even 3ds files uses them a lot, you can’t escape that & if you’ll try to do somthing in software you will get even worse. If you have performance problems look at thing like COLLOR_BUFFER_BIT, you can often disable that and you’ll get at least 10+ fps, not 1/10000000000000, by swithing to triangle strips.

i don’t think quad are slower, because the conversion to a triangle strip is VERY simple… even simpler with quad strip -> triangle strip. in fact, a quad strip IS a triangle strip (look at the verticle order…you can replace your gl_quad_strip with gl_triangle_strip, nothing will change)

I even think the triangle setup was performed in SW - i.e. turn triangle vertices into scan line start-stop coordinates - but I may be wrong).

I belive this was the way it was done for the original Voodoo, but the Voodoo2 added hardware triangle setup.

Oh, that were a lot of replys, thanks guys.
Hmmm I know now that quads are evil.

Well seriously I tried to do my particles as triangle strips and it was considerably slower than quads.

I usually send 128 quads packed in a vertex array, if I’d send a triangle strip with the same data I get wrong results.
I think this makes sense because the particles share no vertices. Thus I used immediate mode for the triangle strip benchmark which possibly explains the loss of speed.

PS.: Madman, could you tell me how to use this colorbuffer-thingy?

Thanks alot for the replys!

What Madman means is that if you are covering the entire screen with geometry every frame, for example you are drawing a closed world or a skybox, there is no need to clear the color buffer every frame.
Simply remove the GL_COLOR_BUFFER_BIT from the glClear statement, but keep the depth & stencil clears, and you should see an improvement. I just tried it on my app and got an increase in fps - 50 to 52.

Ah, I think understand!
Thanks, right now I cannot use that though as I indeed don’t have a world at all

I hope I wont forget to skip the ColorBuffer bit later.

i don’t think quad are slower, because the conversion to a triangle strip is VERY simple…

Almost as simple as quad->triangle fan conversions

JustHanging, something you said just struck me as a very good idea. Using quads could be faster, because you can use a single call to glDrawElements, by putting all of your particles into a list first. Of course, if you dont use that optimization, you wont get much or any of a performance difference between tri-strips or quads. Anyway… I think I’m going to change my particle rendering code now.

The difference betweens GL_TRIANGLES and GL_TRIANLGLE_STRIP ist that you only need one new vertex per each call, because the new triagle is setup out of the last two points of the “before” triangle AND the additional new point for your next triangle.
This saves a lot of API calls.

Hi, what Ben said is an potential area for nasty problems. I have a case where a single quad, with colours e.g. red,green,red, green at the vertices can give a different result on different hardware combos.

So, do you get a reddish line or a greenish line down the diagonal?

If I run the program on my SGI O2 or a PC, I get one result. If I run the same program on a remote machine and display the result on my SGI O2, I get a different result. The program gives the same result (as my local running) on the console of the remote machine, OR if displayed via an Xserver on a PC.

The only way to get the same result is to have 2 versions of the program with the colours assigned green,red,green,red.

The reason is that the way a quad may be decomposed by the driver for delivery to the hardware is NOT defined and is up to the vendors to decide.

So, all is well if you run all on the same machine, but you can get problems when displaying the results on the display of a different machine from the one where the decomposition has been done prior to delivery of data to the card.

Rob