Is OpenGL bad?

[kaalus]

Suppose, I want to draw ten thousand separate triangles, each one having one corner red, one corner green and one corner blue.

Suppose that I don't want to use ColorMaterial, because there is more than one component of each of 3 materials that I want to change per vertex.

For my best knowledge, in OpenGL there is no way of doing this without switching materials at least twice a triangle - this makes 20000 material switches a frame, although I have only 3 different materials in scene.

Switching materials in OpenGL is painfully slow (I don't know why), it takes more time than transforming and lighting several triangles.

Thus, using OpenGL I'm unable to draw these bloody 10000 triangles at smooth framerates, even using GeForce 2 Ultra.
If this is true, OpenGL seems to be a not-well-thinked-over API.

In DirectX I would need exactly 3 material changes a scene in such a situation, not 20000, because process of transformation and lighting can be separated from drawing in DirectX. So, I can first transform and light all vertices using material #1, then all vertices using material #2 and so on. Then I can draw all the triangles without any more processing and material-switching.
In OpenGL I can't do it, or at least don't know how to do it.

If anybody knows, please let me know.

Kaalus

[Eric]

The fact that DirectX allows you to separate T&L and drawing does not mean that the graphics card does... I would be surprised if a graphics card could draw things this way.

I believe that whatever way you specify your scene, there will be 3 material changes per triangle (i.e. in DirectX case, the driver will take care about that)...

Have you benchmarked a DX version of your app ???? If I am right, the only performance difference I see is the overhead in calling glMaterial from your app....

I suppose some people will answer that better...

Regards.

Eric

[Roderic (Ingenu)]

First the topic is not good, it's stupid to ask such a question in an OpenGL support Forum.
Second OpenGL is way best thought than any other API out there because many engineers from many companies have thought it.

Third :
Use glColorMaterial it's way faster.
If you deactivate Lighting you can use glColor, but then you will have to compute your own lighting.
You can also use a texture for your 3 colors.

I doubt Direct3D can do what you told.
(I mean your code might be ok, but the hardware won't do what you think)
The hardware will probably do what you ask him to do with OpenGL even using Direct3D, so performances should be the same.

If this is not the case I would like to hear about it, and I'll think about how it can be achieved.

[Tom Nuydens]

Originally posted by kaalus:
In DirectX I would need exactly 3 material changes a scene in such a situation, not 20000, because process of transformation and lighting can be separated from drawing in DirectX. So, I can first transform and light all vertices using material #1, then all vertices using material #2 and so on. Then I can draw all the triangles without any more processing and material-switching.

I agree with Eric and Ingenu: I don't think your hardware is doing what you think it is. What you describe above implies that the T&L is not being done by your 3D card. AFAIK, there is no way to ask your card to transform and light first, then render. Doing so would pretty much break the whole 'pipeline' idea.

As an alternative, consider switching the lighting off to draw the red/green/blue triangles, then doing the lighting in a second pass.

BTW, why would you want to change anything other than the diffuse/ambient colors on a per-vertex basis? I really don't think you'll see the difference between per-vertex and per-triangle changes in shininess, for example.

- Tom

[mcraighead]

Whatever you do, _don't_ change your material inside a Begin/End. It was a horrible design decision of OpenGL that that was allowed.

- Matt

[robosport]

I would have done this with a single texture (with the color blending pre-computed) and not changed the properties at all during the render loop.

[Jan]

I assume you are using immediate mode? (glBegin....glEnd) ?

If so, you are using the slowest method possible, so don´t complain about anything.

Jan.

[rgpc]

Before you start bagging Opengl, learn a little more about it.

glColorPointer() (and a bit of preprocessing) would be all you need.

[Humus]

*cough* Three year old thread *cough*

[rgpc]

D'oh! It has to happen at least once a month doesn't it...

:D