Drawing from COLOR_ATTACHMENT0 to COLOR_ATTACHMENT1

[Bob Read]

How can I set up my WebGL state, framebuffer object and fragment shader so that I can read from a COLOR_ATTACHMENT0_WEBGL texture and then write the data (after doing some processing) to a COLOR_ATTACHMENT1_WEBGL texture? I have tried various methods but I always end up with a 'Source and destination textures of the draw are the same' error.

I am relatively new to WebGL and GLSL and have been trying to implement real-time volumetric lighting as described in Chapter 17 of WebGL Insights by Muhammad Mobeen Movania and Feng Lin. I have made good progress understanding other aspects of the technique (after a lot of effort) but this particular problem has me stumped. 

[Ken Russell]

Hi Bob,

You need to make sure that the same WebGLTexture object is not bound at the same time to any of the color attachments of both the framebuffer object (WebGLFramebuffer) you're reading from and to the framebuffer you're writing to. This restriction may require you to allocate a separate texture object for the destination while you're reading from the source -- effectively ping-ponging between two textures.

-Ken

On Sun, Oct 22, 2017 at 1:49 PM, Bob Read <robh...@gmail.com> wrote:

How can I set up my WebGL state, framebuffer object and fragment shader so that I can read from a COLOR_ATTACHMENT0_WEBGL texture and then write the data (after doing some processing) to a COLOR_ATTACHMENT1_WEBGL texture? I have tried various methods but I always end up with a 'Source and destination textures of the draw are the same' error.

I am relatively new to WebGL and GLSL and have been trying to implement real-time volumetric lighting as described in Chapter 17 of WebGL Insights by Muhammad Mobeen Movania and Feng Lin. I have made good progress understanding other aspects of the technique (after a lot of effort) but this particular problem has me stumped. 

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bob Read]

Hi Ken,

Many thanks for your reply. Do you know of a good example of the ping-pong technique that I could look at?

Bob

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.

[Kirill Dmitrenko]

You also can create a separate framebuffer object, attach the destination texture and draw to it. That would eliminate feedback loop.

воскресенье, 22 октября 2017 г., 23:49:12 UTC+3 пользователь Bob Read написал:

[Bob Read]

Many thanks for all the suggestions. I still cannot get this to work however. If anyone can point me to a coding example of ping-ponging between textures using two color attachments that would be fantastic.

Bob

[Jeff Dash]

Here is an example of basic ping-ponging in webgl1:

http://jdashg.github.io/misc/webgl/ping-pong.html

--

You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-list+unsubscribe@googlegroups.com.

[Bob Read]

Thanks Jeff,

Unfortunately the example you provide only uses color attachment 0 whereas the technique in I am trying to use (by Mobeen and Feng Lin) ping pongs between color attachment 0 and color attachment 1. They do provide some code in their paper but I cannot get it to work without the source and destination the same error. If anybody knows of a ping pong method using two color attachments that would help me understand what I am doing wrong.

On Sunday, October 22, 2017 at 9:49:12 PM UTC+1, Bob Read wrote:

[Jeff Dash]

There is no functional difference here in using two different framebuffers. If you'd like, you can additionally attach both textures to some third framebuffer, and use that if you need MRT functionality for some reason.

If you insist on using a single framebuffer, you'll have to use drawBuffers() to exclude the color attachment of the texture you're sampling from. This is likely to be slower than using multiple framebuffers.

The crux of the issue is that WebGL prevents reading from a texture while writing into the same texture via framebuffer attachment. Since this cannot always be precisely determined, there are some configurations where we forbid drawing when actually no fault would occur. (I doubt this case here is this kind of false-positive though)

--

[Bob Read]

Many thanks Jeff,

I think I will try using two framebuffers as you suggest. I only tried using one because this is what Mobeen and Feng Lin do in their technique. I assumed (without having any technical knowledge) that they did this because it would be faster or use less resources but if this is not the case then it would certainly make it a lot easier to implement!

Bob

On Sunday, October 22, 2017 at 9:49:12 PM UTC+1, Bob Read wrote:

[Muhammad Mobeen Movania]

Hi Bob,

   This is Mobeen here. We use a single FBO with two color attachments. COLOR_ATTACHMENT0 has lightBuffer attached to it and COLOR_ATTACHMENT1 has eyeBuffer attached to it. During rendering when the eyeBuffer is used as render target, the lightBuffer is read from and in the second pass the lightBuffer is used as render target. AS to why we used a single FBO we were more focused on the technique itself in which we had to accumulate results slice by slice once into the eyeBuffer and then into the lightBuffer and using a single FBO did it for us.

Sincerely,

Mobeen

--

[Mark Callow]

On Oct 24, 2017, at 18:08, Muhammad Mobeen Movania <mmmo...@gmail.com> wrote:

Hi Bob,

   This is Mobeen here. We use a single FBO with two color attachments. COLOR_ATTACHMENT0 has lightBuffer attached to it and COLOR_ATTACHMENT1 has eyeBuffer attached to it. During rendering when the eyeBuffer is used as render target, the lightBuffer is read from and in the second pass the lightBuffer is used as render target. AS to why we used a single FBO we were more focused on the technique itself in which we had to accumulate results slice by slice once into the eyeBuffer and then into the lightBuffer and using a single FBO did it for us.

In native OpenGL this behavior (reading from a buffer while is is bound as a render target and to a texture unit) is a feedback loop and behavior is undefined. See, e.g., the OpenGL 4.5 spec section 9.3.1.  Obviously you’ve been able to get away with it on the implementations you have been using probably due to your case being one of the exceptions listed in section 9.3.1 or maybe you’ve just been lucky with the implementations you have been using.

WebGL doesn’t like undefined behavior so it specifies an error for the dual binding which means none of the listed exceptions can work either. So you need to make sure lightBuffer is not bound to a bound FBO when you are reading from it and not bound to a texture when writing to it which can be accomplished in several ways one of which is multiple FBOs.

Regards

    -Mark

[Muhammad Mobeen Movania]

thanks mark for the details.

[Bob Read]

Many thanks to Mobeen and Mark for your responses. Could it be that when Mobeen developed his code the browser he used were not quite as efficient at detecting feedback loops as my browser is? I had followed his code closely and couldn't understand why I was getting the error. My knowledge of GLSL and WebGL is still quite limited and I assumed it was something I had done wrong. I'll try using separate FBOs and see if I can get that to work. Many, many thanks for your help, it is much appreciated.

Bob

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.

[Muhammad Mobeen Movania]

Hi Bob,

  Actually at the start of writing to eyeBuffer I disable writing to COLOR_ATTACH0 as it is read as texture in the first pass by using drawBuffers call. In the second pass, the write to COLOR_ATTACH1 is disabled. This is exactly what Jeff Dash said in an earlier reply
>if you insist on using a single framebuffer, you'll have to use drawBuffers() to exclude the color attachment of the texture you're sampling from. This is likely to be slower than using multiple framebuffers.

Sincerely,

Dr. Muhammad Mobeen Movania
Head, Department of Computer Science,

Head, Computer Graphics and Visualization Research Group,

Director, CUDA Research Lab,

DHA Suffa University,

Karachi,

PAKISTAN

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-list+unsubscribe@googlegroups.com.

[Bob Read]

Hi Mobeen,

I may be doing something fundamentally wrong since I am not familiar with programming in WebGL. Could you tell me whether my approach to this is correct. My basic algorithm is as follows (without going into detail at this point)...

Setup FBO, matrices, etc

For each slice perpendicular to the half angle direction

Get the vertices of the slice

Bind the shadowShader program

Draw the slice from the eye point of view

Bind the volumeShader program

Draw the slice from the light point of view

Unbind the FBO

[End of for loop]

Draw the contents of the eye buffer to show final result

Best wishes,

Bob

On Sunday, October 22, 2017 at 9:49:12 PM UTC+1, Bob Read wrote:

[Bob Read]

Sorry Mobeen, I meant to put unbinding the FBO after exiting the slice loop

Bob