I think it depends on how much you use ie: the blending..
I''m no expert in anything here, but this sounds the most reasonable =) Well, if you''re going to drive 10 miles you dont fill enough gas for 5 miles, and then stop on the gas station there and fill enough to drive the next 5 miles.. and then again fill =)
or?

Kenneth Wilhelmsen
Try my little 3D Engine project, and mail me the FPS. WEngine
--------------------------
He who joyfully marches to music in rank and file has already earned my contempt. He has
been given a large brain by mistake, since for him the spinal cord would fully suffice. This
disgrace to civilization should be done away with at once. Heroism at command, senseless
brutality, deplorable love-of-country stance, how violently I hate all this, how despicable and ignoble war is; I would rather be torn to shreds than be a part of so base an action! It is my conviction that killing under the cloak of war is nothing but an act of murder

From what I've read all state changes create a performance hit. The thing is you can't possibly leave blending on all the time or else everything would be blended right? So you have to enable it only when you want something blended.

But a reduction in the number of state changes is always desired to optimize your code. I do not however know how much of a performace advantage you'll get.

One of the overlooked problems of performance involves REDUNDANT state changes. This can really slow you down bad and accomplish nothing. Meaning if you have to change a state for an effect that is fine, but doing it more than once gains you nothing and is a big performance hit.

Take a look at this thread in the OpenGL.org forums to see what I mean:
redundant state changes


Edited by - element2001 on November 20, 2001 3:49:02 AM

Hmm... I think you speak to one point I am asking me often, too.
If I''m understanding you right, you are thinking about the default state, and if your function is called that draws e.g. a piece of glass, if it should assume that blending is enabled or disabled.
I think a good point to start is the default state of OpenGL, so you allways assume that this is set. A function that uses Blending is called like this (because Blending is disabled by default):

int drawGlass(){  glEnable(GL_BLEND);  // draw some stuff  glDisable(GL_BLEND);  // restore the default state}

But you allways have to keep in mind that this produces a little overhead.
Especially if you have a loop where a lot of pieces of glass are drawn, this would be not good. So you should do sth. like this there

int drawGlass(){  // draw some stuff  }int main(void){  glEnable(GL_BLEND);  while(condition)    drawGlass();  glDisable(GL_BLEND);  //rest of prog}

But if you e.g. draw everything blended you should change the default state, and perhaps make a comment at the top of your document, which states differ from the default.
Another way would be to check the state before drawing, and changing it when neccesary. But because I don''t know wheter it is faster to simply change the state, or check it and perhaps change it, I can''t give you any advise here.
Note that you will really face this problem if you''re dealing with classes. If you have a class called CGlass, which has a draw function, every call of this must enable blending (for every instance), because the class shouldn''t know anything about it outer world, and shouldn''t depend on it.
One way to work around this would be to offer the static methods glPrepareDraw and glAfterDraw to CGlass, which does all the initialization and, sets the state back after drawing.

class CGlass{  static void glPrepareDraw() {glEnable(GL_BLEND);}  static void glAfterDraw() {glDisable(GL_BLEND);}  void draw() {//...};};int main(void){  CGlass pieces[1000];  CGlass::glPrepareDraw();  for(int=0; i<1000;++i)    pieces.draw();  CGlass::glAfterDraw();}

If you assume the default OpenGL state as your default one in all your progs, you can simply carry your function/ classes from one prog to the other without touching the code.
So it would be easy to reuse, and you can simply exchange code with everyone else who follows these specification.

Greetings Ben