Calculating where the shadow falls on a plane

[elect]

If you attach a texture instead of a render buffer you can then use that texture on a quad rendered to the application frame buffer to look at it. Or you use glReadPixels() to transfer the pixels to main memory and write an image file.

I know, but I would need to use the renderBuffer because they are faster and I do some heavy operations..

Is that last snippet meant to render to the screen? It binds the FBO and sets GL_COLOR_ATTACHMENT0 as draw buffer, so it draws to the FBO. To render to an application frame buffer, unbind the FBO (glBindFrameBuffer(GL_FRAMEBUFFER, 0)) and set the draw buffer to GL_BACK.

I just want to check the content of the renderBuffer, and to do this I thought to render/display it on the screen.. But it doesnt work

[carsten neumann]

I know, but I would need to use the renderBuffer because they are faster and I do some heavy operations..

Sorry, I mentioned the two methods I can think of how to look at what is rendered into an FBO, so I don't really know what to tell you. Maybe someone else here has another idea?
FWIW I don't quite follow your reasoning: you reject using a texture because of performance (personally I even doubt there is a big difference between render buffers and textures, but I've not measured it), but we are talking about a temporary change to aid debugging. Taking your point of view to the extreme it seems to become "better a fast program that computes something nonsensical than a slow and correct one"

I just want to check the content of the renderBuffer, and to do this I thought to render/display it on the screen.. But it doesnt work

AFAIK there is no way to directly (without copying or other transformation) use the contents of a render buffer for drawing. The code sequence you had shown previously only sets the FBO's color attachment 0 as target for future drawing operations.
About the only use of render buffers I can think of is for input to other computations on the GPU, through OpenCL/CUDA, because as far as OpenGL is concerned there is not a whole lot you can do with them - at least that is my understanding.

[elect]

FWIW I don't quite follow your reasoning: you reject using a texture because of performance (personally I even doubt there is a big difference between render buffers and textures, but I've not measured it), but we are talking about a temporary change to aid debugging. Taking your point of view to the extreme it seems to become "better a fast program that computes something nonsensical than a slow and correct one"

You are totally right , but I was almost giving up and using texture when I made it

AFAIK there is no way to directly (without copying or other transformation) use the contents of a render buffer for drawing. The code sequence you had shown previously only sets the FBO's color attachment 0 as target for future drawing operations.

Yep, you are right again, I did as follow to read and drawing the content of the RBO

gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, frameBufferID[0]);
        FloatBuffer pixels = GLBuffers.newDirectFloatBuffer(250*250);
        gl.glPixelStorei(GL2.GL_UNPACK_ALIGNMENT, 1);
        gl.glReadBuffer(GL2.GL_COLOR_ATTACHMENT0);
        gl.glReadPixels(0, 0, 250, 250, GL2.GL_BGRA, GL2.GL_UNSIGNED_BYTE, pixels);
 
        gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, 0);
        gl.glRasterPos2d(0, 0);
        gl.glDrawPixels(250, 250, GL2.GL_BGRA, GL2.GL_UNSIGNED_BYTE, pixels);
 
        gl.glFlush();

About the only use of render buffers I can think of is for input to other computations on the GPU, through OpenCL/CUDA, because as far as OpenGL is concerned there is not a whole lot you can do with them - at least that is my understanding.

Damn, you are right for the third time!
I am going to use Cuda for some calculation on the results. I have different light sources, each of them will produce a shadow. But when I have two or more shadows on one pixel, than that pixel should have a different shadow (let's say "core shadow")..

Now I'd need to know what you really meant by "clearing the FBO to white" (I guess set color to white, right?) and why you mentioned "enable GL_MIN blending (glBlendEquation(GL_MIN))" (what is it useful for?)

Moreover, how can I recognize by a mathematical point of view when a pixel is white or black?

Because it is not so much clear to me, since when I allocate the RBO I use RGBA

        gl.glRenderbufferStorage(GL2.GL_RENDERBUFFER, GL2.GL_RGBA, floorWidth, floorHeight);

while when I read BGRA

gl.glReadPixels(0, 0, 250, 250, GL2.GL_BGRA, GL2.GL_UNSIGNED_BYTE, pixels);

[carsten neumann]

But when I have two or more shadows on one pixel, than that pixel should have a different shadow (let's say "core shadow")..

Yes, that is why usually shadows are not explicitly calculated, but are implicit when calculating lighting. What I mean is that when calculating the color of a fragment one tests from which (if any) light sources it receives light and calculates the reflected light based on that. This naturally puts fragments that don't receive any light into shadow.

It seems to me that you want a more explicit representation of shadows by keeping track of which fragments are in shadow with respect to a light source.
You could assign each light source a "color" based on 1/numLights and draw that. So for two light sources a black pixel means light from all sources, a 50% grey pixel means light from one source and a white pixel means fully in shadow. This requires that you use additive blending (glBlendEquation(GL_FUNC_ADD)) to add up the contributions from the different lights. However the big problem is overdraw: if two triangles from one object are drawn to the same fragment (e.g. because the object has a front and back side) you incorrectly add twice to that fragment.
You could create a render buffer per light source and afterwards combine them to get around that.

meant by "clearing the FBO to white" (I guess set color to white, right?)

yes, I meant setting the clear color (glClearColor()) to white.
The GL_MIN blending was a mistake, it is not needed. The idea was to make sure that a pixel can only ever go from white to black - never the other way - but that won't happen anyway.

Moreover, how can I recognize by a mathematical point of view when a pixel is white or black?

it's rgb value is (1.0, 1.0, 1.0) or (0.0, 0.0, 0.0) respectively.

[elect]

Another question:


Since I am going to have n shadow matrixes (that I will merge in a final one), shall I declare n RBO or n FBO?


I guess n RBOs since the FBO switching mechanism makes things complicated if I want to read values from two different FBO and merge in one (and this means having an additional temporary content somewhere).. right?

[elect]

LOL, we posted at the same time, and actually you answered me in your post

You could create a render buffer per light source and afterwards combine them to get around that.

Thanks carsten!

[elect]

I tried to create a RBO for each light (I start with 2).

I start binding the FBO[0] and RBO[0] for the first shadow set.

// bind the FBO
        gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, frameBufferID[0]);
        gl.glBindRenderbuffer(GL2.GL_RENDERBUFFER, renderBufferID[0]);
 
        // clear
        gl.glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
        gl.glClear(GL2.GL_COLOR_BUFFER_BIT | GL2.GL_DEPTH_BUFFER_BIT);
 
        gl.glViewport(0, 0, floorWidth, floorHeight);
        gl.glLoadIdentity();
        gl.glMatrixMode(GL2.GL_PROJECTION);
        gl.glLoadIdentity();
 
        gl.glMatrixMode(GL2.GL_MODELVIEW);
        gl.glLoadIdentity();
        gl.glDrawBuffer(GL2.GL_COLOR_ATTACHMENT0);
 
 
        // render
        gl.glColor3f(0.5f, 0.5f, 0.5f);
        gl.glBegin(GL2.GL_TRIANGLES);
            gl.glVertex3f(0.0f, 0.5f, 0.0f);
            gl.glVertex3f(0.5f, 0.0f, 0.0f);
            gl.glVertex3f(0.0f, 0.0f, 0.0f);
        gl.glEnd();

Then I bind the FBO[0] and RBO[1] for the second shadow set

gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, frameBufferID[0]);
        gl.glBindRenderbuffer(GL2.GL_RENDERBUFFER, renderBufferID[1]);
        // Allocate the RBO
        gl.glRenderbufferStorage(GL2.GL_RENDERBUFFER, GL2.GL_RGBA, floorWidth, floorHeight);
        // Attaching the RB image (RBO) to the FBO
        gl.glFramebufferRenderbuffer(GL2.GL_FRAMEBUFFER, GL2.GL_COLOR_ATTACHMENT1,
                                                GL2.GL_RENDERBUFFER, renderBufferID[1]);
        // clear
        gl.glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
        gl.glClear(GL2.GL_COLOR_BUFFER_BIT | GL2.GL_DEPTH_BUFFER_BIT);
 
        gl.glViewport(0, 0, floorWidth, floorHeight);
        gl.glLoadIdentity();
        gl.glMatrixMode(GL2.GL_PROJECTION);
        gl.glLoadIdentity();
 
        gl.glMatrixMode(GL2.GL_MODELVIEW);
        gl.glLoadIdentity();
        gl.glDrawBuffer(GL2.GL_COLOR_ATTACHMENT1);
 
        // render
        gl.glColor3f(0.5f, 0.5f, 0.5f);
        gl.glBegin(GL2.GL_TRIANGLES);
            gl.glVertex3f(-0.5f, 0.0f, 0.0f);
            gl.glVertex3f( 0.0f,-0.5f, 0.0f);
            gl.glVertex3f(-0.5f,-0.5f, 0.0f);
        gl.glEnd();

The problem is that the first shadow set gets overwrite...why?

I am binding everytime the proper FBO and RBO, + drawing in the right color_attachment

[elect]

The problem is that the first shadow set gets overwrite...why?

Because I am an idiot! I was clearing the color BEFORE switching color_attachment

[elect]

I am just wondering if it makes sense what I am doing:

- render to the RBO each shadow set , merge them together with cuda, reading the final resulting shadow set, sending to the CPU, create a texture and apply it to the floor inside my render.

The other option would be:

- render directly to texture, merge them to a unique final texture with Cuda and apply it directly

I choose the first way because I read (or at least this appeared to me) that working with RBO is faster and easier. Take in account that I need to calculate core and partial shadow for hundred/thousand of "shadow set".
In the final result, a white tile will be that tile that has never been shadowed by any shadow set. A core-shadowed tile will be that tile that has been always shadowed by all the shadow sets. All the other tiles are then partial-shadowed, that is at least one shadow set without shadow on this tile and at least one shadow set with shadow on this tile.

[Dark Photon]

I am just wondering if it makes sense what I am doing... In the final result,

• a white tile will be that tile that has never been shadowed by any shadow set.
• A core-shadowed tile will be that tile that has been always shadowed by all the shadow sets.
• All the other tiles are then partial-shadowed, that is at least one shadow set without shadow on this tile and at least one shadow set with shadow on this tile.

Sounds like you're trying to compute soft shadows by accumulating the results of rendering hard shadows from a bunch of different points on the surface of an area light source.

I probably don't understand some of what you're requirements are, but...

I have to confess. I don't understand:

1. why you think you need CUDA for this,
2. why you're convinced you need a renderbuffer over a texture.

From what I gather, seems to me you could do this all in GL/GLSL, keep around just two images (or some small number), and use textures instead (so you could use GLSL to do the reduction). Rendering 5 million tris is child's play for GL on a GPU (if you batch your data properly), so even with 100 such frames rendered from different eyepoints (positions on the light source), this isn't super heavy lifting. Not necessarily real-time (I'm assuming that's not your goal), but still pretty darn fast.

You may want to check out Casting Shadows in Real-time for this and other soft shadow algorithms to determine if there's another more efficient solution that you'd be happier with (unless you're just trying to generate an approximate ground truth image). This content may have juiced up and released as a book under the name Real-time Shadows (I say may because I haven't actually had the latter in my hands yet, but the Table of Contents looks suspiciously similar).