Framebuffer Object shadows
Written by on in Snaking.

I also added a FrameBufferObject implementation to the "special effects" tutorial path for OpenGLContext. This uses the convenience wrapper for frame buffer objects which I just added to PyOpenGL. The convenience wrapper just makes the ARB and EXT variants of the entry points available via alternates and provides a checkFramebufferStatus function which implements the ARB extensions suggested check operation (with a raised GLError if there's a problem). That should all show up on the next release, as it will need the newest PyOpenGL release.

At the moment I'm still not very satisfied with the results. Even with a 2048x2048 depth texture I'm seeing very obvious pixellation in the shadows. I'm guessing either floating-point-precision issues or problems with the setup of the scene (OpenGLContext is very conservative with clipping planes, so there's a lot of depth-buffer "compression" going on as the depth buffer goes way off into the distance). I looked into doing multisampling on the depth texture, but that seems to require doing a pixel copy into the texture, which somewhat obviates the value of the direct-to-texture (off-screen) rendering approach.

I also found and fixed a large set of errors in the auto-generated extension wrappers. I also tweaked the docstrings generated. The errors found were that the glGet* constants were not getting registered because the OpenGL extension registry has moved (duh!). I'm thinking I need to spend some quality time with at least the extensions on my machine and make sure that we've got all image-formats, array retrieval, etceteras properly noted and wrapped. Not this week, though.

Comments

  1. Rene Dudfield

    Rene Dudfield on 11/20/2009 3:49 a.m. #

    Hi,

    have you tried changing the resolution of the depth buffer? 32bit rather than 8bit gives nicer shadows from my experiments.

    Also being a bit clever about camera angles and clipping planes can help... which is cheating, but with the right angles shadow buffer shadows can look ok.

    The 'perspective shadow maps' look like an improvement too...
    http://www.devmaster.net/articles/shadow_techniques/
    They are also mentioned at the bottom of http://www.paulsprojects.net/tutorials/smt/smt.html and are what blender uses now for its shadow maps.

  2. Mike C. Fletcher

    Mike C. Fletcher on 11/23/2009 11:58 a.m. #

    Boggle: are there really machines that use a 256-level depth-buffer these days? Everything I've read recently suggests that 24-bit is standard... 24-32 bit might make a difference, though.

    Article pointers were helpful. I hadn't realized someone had already done the "find silhouettes via image processing" approach.

    I still don't see anyone attempting per-object shadow-maps... I might try that if I get some time (each light and each object creates a (small) bitmap for shadows. Each object's bounding box is projected out from the light and to do shadow tests you do an object-bitmap test for each object whose shadow-casting BBox intersects with your BBox. Would break down with large highly-dynamic scenes, but for largely-static scenes it's a possibility.

    Other avenue to pursue is to do traditional optimizations manually, things that I should be doing anyway in OpenGLContext's scenegraph rendering (i.e. determine front/back clipping planes from scene extents, provide feedback to the lights as to the scene extents in order to calculate bitmap angles, that kind of thing).

    Ah, if only I had infinite time to explore hobbies :) .

  3. Viktor

    Viktor on 12/03/2009 10:42 a.m. #

    Mr Rene I have tried with 32bit resolution and I agree.. The shadows are nicer!

    hypotheekrente http://www.laagstehypotheekrentes.com                                           

Comments are closed.

Pingbacks

Pingbacks are closed.