Efficiently Read The Average Color of The Screen Content Rendered by Xbmc

Keep the biggest values from source AND destination (bitwise OR) in OpenGL ES 2.0

I must admit I was not so clear in my question. Anyway, I will refine the problem and present a resolution to it here.

I have many different kind of arbitrary shapes (the user can create as many of them he wants and crazily deform them) and I want to develop a method to detect from the color of a pixel on the screen how many of the shapes the user picked (the user has just touched on that pixel).

So, I color code the shapes with let's say some kind of color ids. I work in the binary level:
the first shape on the screen has color id 00000001 the second shape has id 00000010 and so on. So, with a byte (in the red channel let's say) I can store up to 8 different color ids. The max number of shapes is 32 if I use an RGBA8888 format.

The algorithm that I initially developed was doing blending between the source color id and the destination color id with a glBlendFunc(GL_ONE, GL_ONE), and everything seemed to work fine. So if a touched pixel with color 00010101, then it meant that the first, third and fifth shapes were touched. BUT, there are some non-convex shapes (if this is the right word for folding shapes) that can be created by the user. In this case if the shape with color id 00000001 is folded by the user then the overlapping pixels will get id 00000010, because the shape writes 00000001 when it is first drawn on the framebuffer and then the overlapping pixels of the same shape add another 00000001 due to blending.

So, if in some way I could do a BITWISE OR (NOT logical as I initially mentioned in my question) between the color ids that were written in the framebuffer then the problem would be solved. Indeed this is the case with OpenGL ES 1.1, by using the glLogicOp(GL_OR) function. UNFORTUNATELY this is not available on OpenGL ES 2.0 and again one shader, one more pass etc must be created which I think is overkill and difficult to maintain.

The solution for OpenGL ES 2.0 is this:

  1. Clear the color of RenderTexture B to glClearColor(0,0,0,0)
  2. FOR each shape
  3. Clear the color of Rendertexture A to glClearColor(0,0,0,0)
  4. Draw the shape on Rendertexture A using a fragment shader that writes as a color its color id.
  5. Blend with GL_ONE, GL_ONE the Rendertexture A with the contents of Rendertexture B
  6. END FOR
  7. RenderTexture B has all the info we need.
  8. When the user touches the screen, sample the corresponding pixel from RenderTexture B using glReadPixel and find out from the binary code the touched shapes.

Best

Why would glBindFramebuffer(GL_FRAMEBUFFER, 0) result in blank screen in cocos2D-iphone?

The Problem was that either iOS or Cocos2D (or both) can have a unique framebuffer.
The handle of that unique frame buffer would be different than 0, and may be different each time.

To solve this, I have to grab the current FBO's handle, do my custom Framebuffer stuff and then re-apply the FBO's handle after I'm done.

Creates a variable to reference the original Frame Buffer Object

GLint oldFBO;

Assigns the currently used FBO's handle (which is a 'GLint') to the variable 'oldFBO'

glGetIntegerv(GL_FRAMEBUFFER_BINDING, &oldFBO);

//here is when you would create or manipulate custom framebuffers.//

After that, You set the original FBO as the current Framebuffer

glBindFramebuffer(GL_FRAMEBUFFER, oldFBO);

How does glClear() improve performance?

It is most likely related to tile-based rendering, which divides the whole viewport to tiles (smaller windows, can be typically of size 32x32) and these tiles are kept in faster memories. The copy operations between this smaller memory and the real framebuffer can take some time (memory operations are a lot slower than arithmetic operations). By issuing a glClear command, you are telling the hardware that you do not need previous buffer content, thus it does not need to copy the color/depth/whatever from the framebuffer to the smaller tile memory.



Related Topics



Leave a reply



Submit