Thread: [PyOpenGL-Users] Depth buffer attachment problem
Brought to you by:
mcfletch
From: Nicolas R. <Nic...@in...> - 2014-02-24 20:41:07
|
Hi, I'm trying to render a simple rotating textured cube to a texture using framebuffer. I attached a RGB texture for the color buffer and a depth render buffer for the depth buffer to the framebuffer (same 512x512 resolution for each of them). I checked for the status of the framebuffer which report itself as "complete". Nonetheless I get a weird rendering as shown on second image: Direct rendering (without framebuffer): http://www.loria.fr/~rougier/tmp/without-fbo.png Indirect rendering (with framebuffer): http://www.loria.fr/~rougier/tmp/with-fbo.png First image is direct rendering (no framebuffer) and is ok. Second image is indirect rendering (rendering to texture then displaying the texture, the left washed-out part is ok, it comes from the fragment shader for testing purposes). I suspect the depth buffer is not really attached but I did not get any error along the way. I'm using python (2.7.6), pyopengl (3.0.2) on osx and I'm using framebuffer operations from the main pyopengl namespace (OpenGL.GL) but I know OpenGL.GL.ext.framebuffer_object is also available. Could this be the reason ? I cannot provide a simple example since the example comes from a project (vispy). If anyone have a simple glut based example showing framebuffer rendering (with depth buffer) such as cube rendered on cube, that could help. Nicolas |
From: Mike C. F. <mcf...@vr...> - 2014-02-24 20:52:34
|
On 14-02-24 03:40 PM, Nicolas Rougier wrote: ... > I cannot provide a simple example since the example comes from a project (vispy). If anyone have a simple glut based example showing framebuffer rendering (with depth buffer) such as cube rendered on cube, that could help. I can check out code for vispy (already have it checked out on multiple machines). I don't have a simple "render a cube" sample, but this code here: http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/shadow_2.py renders a shadow map (that is, a depth-texture) using FBOs and might help with what needs to happen to render a scene into an FBO. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Nicolas R. <Nic...@in...> - 2014-02-24 21:23:39
|
Thanks, that will be really useful. I'll try to turn your example into a rotating cube and see what happens. And if it works, it'll make a nice addition to pyopengl. Nicolas On 24 Feb 2014, at 21:52, Mike C. Fletcher <mcf...@vr...> wrote: > On 14-02-24 03:40 PM, Nicolas Rougier wrote: > > ... >> I cannot provide a simple example since the example comes from a project (vispy). If anyone have a simple glut based example showing framebuffer rendering (with depth buffer) such as cube rendered on cube, that could help. > > I can check out code for vispy (already have it checked out on multiple > machines). > > I don't have a simple "render a cube" sample, but this code here: > > http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/shadow_2.py > > renders a shadow map (that is, a depth-texture) using FBOs and might > help with what needs to happen to render a scene into an FBO. > > HTH, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Ian M. <ia...@ge...> - 2014-02-24 20:58:31
|
On Mon, Feb 24, 2014 at 1:40 PM, Nicolas Rougier <Nic...@in...>wrote: > Direct rendering (without framebuffer): > http://www.loria.fr/~rougier/tmp/without-fbo.png > Indirect rendering (with framebuffer): > http://www.loria.fr/~rougier/tmp/with-fbo.png > This doesn't look FBO-related; it looks like a difference in rendering. FBO errors tend to have nothing work, not have the rendering look incorrect. I cannot provide a simple example since the example comes from a project > (vispy). If anyone have a simple glut based example showing framebuffer > rendering (with depth buffer) such as cube rendered on cube, that could > help. > I have a simple FBO class implemented. It is used in several of my projects (e.g. my GLSL game of life implementation<http://geometrian.com/programming/projects/index.php?project=Game%20of%20Life>). You can use it as a reference. As before though, it looks like some broken matrices or shading--not a FBO issue. Ian |
From: Nicolas R. <Nic...@in...> - 2014-02-24 21:21:52
|
Thanks a lot. I will start with the example by Mike and your class as well. If I do not find the bug, I will try to write the most simple example I can and come back here. Nicolas On 24 Feb 2014, at 21:58, Ian Mallett <ia...@ge...> wrote: > On Mon, Feb 24, 2014 at 1:40 PM, Nicolas Rougier <Nic...@in...> wrote: > Direct rendering (without framebuffer): http://www.loria.fr/~rougier/tmp/without-fbo.png > Indirect rendering (with framebuffer): http://www.loria.fr/~rougier/tmp/with-fbo.png > This doesn't look FBO-related; it looks like a difference in rendering. FBO errors tend to have nothing work, not have the rendering look incorrect. > > I cannot provide a simple example since the example comes from a project (vispy). If anyone have a simple glut based example showing framebuffer rendering (with depth buffer) such as cube rendered on cube, that could help. > I have a simple FBO class implemented. It is used in several of my projects (e.g. my GLSL game of life implementation). You can use it as a reference. > > As before though, it looks like some broken matrices or shading--not a FBO issue. > > Ian > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: rndblnch <rnd...@gm...> - 2014-02-25 09:02:06
|
Nicolas Rougier <Nicolas.Rougier <at> inria.fr> writes: > First image is direct rendering (no framebuffer) and is ok. Second image is indirect rendering (rendering > to texture then displaying the texture, the left washed-out part is ok, it comes from the fragment shader > for testing purposes). > > I suspect the depth buffer is not really attached but I did not get any error along the way. did you clear the depth buffer between the binding of the FBO and the rendering? the code (even with dependencies) would help for analysis. renaud |
From: Nicolas R. <nic...@in...> - 2014-02-25 09:51:54
Attachments:
fbo-glut.py
|
While trying to write a strip-down example, I accidentally reproduced the same kind of output using GL_TRIANGLE_TRIP instead of GL_TRIANGLES. Here is the source (which doesn't work as expected using the indices buffer: no output). That le me think I may have introduced the same kind of bug in the other source. I'm still investigating why the index buffer doesn't work (and texture actually). I didn't thoroughy check for errors yet, pardon me if it is very obvious... (The crate.npy is a 256x256 RGB texture stored as a numpy array. You'll need to replace it or discard it.) Nicolas |
From: Nicolas R. <Nic...@in...> - 2014-02-25 11:20:02
Attachments:
fbo-glut.py
|
I investigated furthermore and my problem may come from my misunderstanding on vertex/index buffers. I attach an simple example where 2 programs are built (cube and quad): - cube is a rotating cube using vcube and icube (vertex and index buffer) and TRIANGLES. - quad is a simple quad using vquad (vertex buffer) and TRIANGLE_STRIP. In the "display" method, one can choose to display the rotating cube (if 1) or the quad (if 0). The rotating cube runs fine on my machine but the quad display does not. It is like the quad is using the cube vertex buffer and the display appears broken (cube vertices have been divided by 2 and it impacts the quad). It's very similar to the bug I first reported here and this makes me think there's no connection with the framebuffer. Also, the quad seems to be able to use the cube texture information while I did not set the "u_texture" information in that program. Obviously I'm doing something wrong but I can't see it. Finally, binding the texture (see line #DEBUG) blacks out the texture. A lot of weird things are happening indeed. Any help appreciated. Nicolas |
From: Nicolas R. <Nic...@in...> - 2014-02-25 12:12:23
Attachments:
fbo-glut.py
|
I found the bug. I was not re-setting attributes between calls to the two different program that lead to the weird behaviour. It also fixed my framebuffer problem. Now I understand the utility of VAO... Sorry for the noise. Here is the corrected version. Nicolas |