FBO | using FBO to render particles in THREE.js | Graphics library

If you are reading a 32-bit per component texture you need a highp sampler and you need to store the result in a highp variable.

Currently you are specifying a mediump for usample2D and the default int precision is also mediump. For integers mediump is specified as "at least" 16-bit, so either of these may result in your 32-bit value being truncated.

Note the "at least" - it's legal for an implementation to store this at a higher precision - so you may find "it happens to work" on some implementations (like the emulator) because that implementation chooses to use a wider type.

Turns out that I wasn't clearing my vector of render submissions, so I was adding a new mesh to draw every frame.

Your function createEmptyTexture binds the texture it creates to the (implicitly) activated texture unit 0, and leaves it bound. So if you want to read from the texture of the first framebuffer you'll need to bind that before rendering with program 2. That being said, usually you'd setup all the vertex-, index- and framebuffers with their respective textures and programs upfront during initialization, your render loop then emits bind, draw and attribute pointer calls.

I solved this issue using glSubTexImage2D.

First create a opengl texture and bind it to GL_TEXTURE_2D. Then use glEGLImageTargetTexture2DOES to bind texture to EGLImageKHR created from EGLClientBuffer. This is similar to glTexImage2D. Any subsequent call to glTexImage2D will break the relationship between the texture and EGLClientBuffer.

refer: https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt

However glSubTexImage2D preserves the relationship. Hence we can load data with this API and store it in AHardwareBuffer.

PS: This might me one way and if there are other ways i'll be accepting the answer.

There's a bunch of problems in your code, and that's without even seeing the core of the problem yet, since it's in the // ... part:

• You don't use glfwSwapBuffers when you're trying to render in a headless setup, that's only needed when you render to the context back buffer and want to swap it to screen.

• You don't want both glGetTexImage and glReadPixels, they both read data from graphics memory to system memory. In your case you're reading the texture data in buffer then overwriting it with the backbuffer data, which should be empty since you never wrote to it.

• You definitely do not want glBlitFramebuffer, that's for copying from video memory to video memory. You seriously need to stop and read the documentation, throwing random functions at your video driver is a sure way to make it crash.

• You need to enable OpenGL's debug layer validation, especially while trying all these random functions. And related, you need to check your frame buffer setup (glCheckFramebufferStatusEXT), I'm willing to bet money you didn't, but you don't show your code.

• You don't show your frame buffer bindings, so I can't tell if you're doing this for sure or not, but you need to bind the frame buffer as "read" (GL_READ_FRAMEBUFFER) before reading from it. I only see a "draw" frame buffer binding, and you're only randomly clearing it.

• And lastly, you should never stall the CPU on a read operation from video memory, especially when you have things you should be doing, like video encoding. Use pixel buffer objects in a round-robin fashion to double or triple buffer the transfer, so there's no stall.

This happens when you over-draw a semi-transparent image over itself multiple times. The white pixels become whiter, the blue pixels become bluer, and, consequently, the anti-aliased edge disappears over a couple iterations.

I therefore deduce that your 'transparent framebuffer' already contains the blue line and the black grid lines. The solution thus will be to clear the 'transparent framebuffer' before you proceed with drawing the red line into in.

This ended up being a problem with Regl and WebViz. I was calling React.useState to set the whatever resource that regl uses for the texture. For some reason, this seems like it was invoked, which "resets" the texture to an empty 1x1.

I'm looking at the output of both your renderTargetA and B, and it looks like one is outputting data at the top row of the image, while the second one is at the bottom row. My best guess is that your "ping-pong" effect is working, but you see a flicker because your mesh is reading data from the same row, which is empty 1/2 of the time.

Frame buffer 0 (Data at top):

Frame buffer 1 (Data at bottom):

You cannot render to two separate and incompatible FBOs. And what you're trying to do amounts to rasterizing triangles twice, using different viewports for different depth buffers.

You can achieve something similar to what you're trying to do by using layered rendering. You can create an array texture for your depth buffer, attach it to the FBO as a layered image, and set multiple viewports for them, then use a GS to output multiple copies of the same triangle to the different layers that will be differently rasterized for the layered depth buffers.

But this also requires a layered color buffer, even though you're not using the color component for the other rasterized image. And the layers in your depth array texture cannot be of different sizes, so you'll have to pick the union of the dimensions and just ignore stuff outside of that area.

Of course, there's one snag: you can't read from your shadow map before you finish building it. This means that if your scene needs to actually use the shadow map (for, you know, shadowing), this is totally not going to work.

So basically this conversation is entirely academic.