environment color vs. primary color

This is very outdated, I know, but please write your opinion. Which color do you think is better for use in a TU, if you can use both equally well. I can’t find anything on google.

My take: if primary colors are specified, they are interpolated, but the environment color is constant so it may be better to use environment color.

Which color do you think is better for use in a TU, if you can use both equally well.

What do you mean by “better?”

The environment color is a constant. The per-vertex color is per-vertex. Which you use is a matter of what you’re doing.

Some hardware in recent memory (the Imagination MBX) has issues with the environment color:

  • the environment color should be unique for each texture unit, but isn’t.
  • the environment color is stored in lower precision than the primary color.

So, it depends on your use pattern. But environment color has some disadvantages on some hardware.

  • the environment color is stored in lower precision than the primary color.

Really? Where do the GL specs specify this?

I’ve already heard about the MBX oddity, but with that GPU, there are only 2 TUs, so you can use primary color for one TU and the environment color for another.

Alfonse, I specified: if you can use both equally well. That is, you can choose to either use the environment color or the primary color to achieve the same result.

Where do the GL specs specify this?

They don’t; he’s talking about the vagaries of a particular piece of hardware.

Alfonse, I specified: if you can use both equally well. That is, you can choose to either use the environment color or the primary color to achieve the same result.

“If you can use both equally well” means that the per-vertex color is a constant. Therefore, you are passing per-vertex data that is not necessary. If you’re rendering with vertex arrays, this means having to pull extra data for every vertex. That’s a waste of space and bandwidth for every draw call.

Even if he is talking about the specifics of the MBX GPU, his statement needs to have come from some specs.

“If you can use both equally well” means that the per-vertex color is a constant. Therefore, you are passing per-vertex data that is not necessary. If you’re rendering with vertex arrays, this means having to pull extra data for every vertex. That’s a waste of space and bandwidth for every draw call.

What if you call glColor*() instead?

Even if he is talking about the specifics of the MBX GPU, his statement needs to have come from some specs.

No they don’t. They could come from personal experience. Or a post on a forum. There’s nothing in any specification that says immediate mode is slower than using vertex arrays for rendering, but it’s almost guaranteed to be true.

There’s a lot of unspecified knowledge you need when dealing with hardware like GPUs.

What if you call glColor*() instead?

If it’s part of immediate mode, then you’re using immediate mode. Since you have chosen to use immediate mode, performance must clearly not be much of a concern. So the difference is irrelevant.

If it’s part of array rendering, using a constant attribute with arrays, then it’s implementation dependent. However, it is clear that this kind of thing is not done often by users, so it’s not likely to be a case that driver writers optimize for. Benchmark it if you want, but you probably won’t find any performance improvements.

No they don’t. They could come from personal experience. Or a post on a forum. There’s nothing in any specification that says immediate mode is slower than using vertex arrays for rendering, but it’s almost guaranteed to be true.

Sometimes they do. The environment color limitation of the MBX is well documented.

glColor*() is not necessarily part of the immediate mode. You can call it outside of the glBegin()/glEnd() code block.

That’s not really relevant, you can call glNormal, glTexCoord, etc outside of a Begin/End block too. All that that they do is specify a current colour/normal/texcoord which is then picked up and transferred to the GPU when you call glVertex.

But on the other hand, you can also use these functions with vertex arrays if you wish, and they’ll work fine. Obviously you won’t be able to use per-vertex colours/normals/texcoords but if doing so floats your boat…

I don’t know if they work with VBOs and nor do I feel inclined to find out. :wink:

I don’t know if they work with VBOs and nor do I feel inclined to find out. wink

They do.

They do.

Yes, but you asked for what works “better” (a term you still have yet to clarify). Since pretty much no one mixes immediate mode state settings with array calls, the answer is exactly as stated. It will probably function, but there’s every likelihood that it will be no faster than just setting regular texture environment state.

Of course they do, you generalize too much. Check out the opengl es 1 man pages:

http://www.khronos.org/opengles/sdk/1.1/docs/man/

There you’ll see it glColor*() and the rest, but no immediate mode support.

Yet I agree with you on one thing: the fixed pipeline is a waste of time, with GLSL being as widely supported as it has been for some time now; I hope the fixed pipeline will disappear soon even from mobile and embedded devices.

There you’ll see it glColor*() and the rest, but no immediate mode support.

First of all, I was given to believe that this was a conversation about OpenGL. OpenGL ES is a different animal.

Second, regular OpenGL can do that too. Even in 3.x+ core; the glVertexAttrib* functions still exist, which are the attribute equivalents of glColor*. The fact that these are around doesn’t mean it’s a good idea to actually use them.

First of all, I was given to believe that this was a conversation about OpenGL. OpenGL ES is a different animal.

Not at all. You can easily develop for OpenGL, with an eye towards the GL ES capabilities, then compile your source for a mobile/embedded device. I’ve done it on many occasions.

Second, regular OpenGL can do that too. Even in 3.x+ core; the glVertexAttrib* functions still exist, which are the attribute equivalents of glColor*. The fact that these are around doesn’t mean it’s a good idea to actually use them.

Exactly and with the help of the compatibility profile into GL 4+. About whether it’s a good idea to use them or not: sometimes people don’t have a choice. But I agree on that. We have needlessly waded into the territory of shaders here.