Posts: 1,066
Joined: 2004.07
Post: #1
When it comes to textures and blending, what is the point of enabling it, drawing everything and disabling it only to come back to the top and enable it again? Is there a downside to simply enabling it during init and never disabling it (besides not being able to not blend or texture)? I know it works with blending and I'm planning on using it with texturing. I do this for code organization. I don't like having the glEnable/glDisable code in my RenderScene() function so I just put the glEnable code in the init and it works. Is there a good reason to not do this? There probably is and I don't know it.
Quote this message in a reply
Posts: 72
Joined: 2006.10
Post: #2
It's really a simple mathematics question. When you activate blending, you "blend in" every single fragment. This is obviously heavier that simply overwritting the value.The same is true for texturing.

Of course, if every single polygon in your scene is blended in ( a somewhat unlikely situation ), then simply activating it in your init methos works well. For texturing, it makes more sense. Also, this doesn't prevent you from disabling texturing when you don't need it and reenable it afterwards.

This said, there could be an argument for not doing so: standardisation. Keeping your enables in your init codes imply that you have to "remember" that they are there. For a single project, this doesn't make much sense, but consider this: for a couple of months, you work assuming that blending is enabled at all times. Eventually, you start a new project wich doesn't have blending enabled in the init code. It's surprisingly easy to become confused because of the reflexes you developped.

In conclusion, IMHO, develop a personnal standard of "enables in init" for yourself: ( i.e. Textures, Depth testing and Lighting ) that you keep constant troughout your projects. Oh, and for blending, I suggest highly against it because of the reasons above.

- Sohta
Quote this message in a reply
Posts: 1,066
Joined: 2004.07
Post: #3
ok. I think I'm going to go with the enabling and such in the render code to keep it lighter.
Quote this message in a reply
Posts: 1,234
Joined: 2002.10
Post: #4
Keeping any function enabled (lighting, texturing, fogging, testing, blending, etc) has an associated cost. Some operations like texturing are well optimized on current video cards, but for example with blending, for every pixel drawn to the screen, the current pixel in the framebuffer must be read to feed into the blending equation, and this roughly halves your fillrate. So it is to your advantage to disable any functionality you are not using.

Of course, enabling/disabling is a *state change* and this also has an associated cost. (Internally, the GL may need to flush certain buffers when you change state, but the details depend on the video card and are hidden from you.) So you also want to minimize your state changes-- don't rebind textures around every single quad, for example.

What you enable depends entirely on what sort of stuff you're trying to draw. It's best to figure out what type of things you're drawing and then batch them by state. For example, draw all untextured stuff, then all textured stuff, then all blended textured stuff. You also have to worry about the Z order though, so sometimes you have to make compromises.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Enabling vsync with Pygame/PyOpenGL cecilkorik 4 11,218 Apr 12, 2010 07:40 PM
Last Post: manifest020
  Enabling OGL fog in shaders kordova 7 8,702 Jul 12, 2006 10:12 AM
Last Post: kordova