OpenGL ES drop shadows for 2D sprites

I’ve got a an OpenGL scene rendered with a bunch of sprites, and I’d like to automagically add drop shadows to all of them. Here’s a picture showing what I mean:

enter image description here

  • Disable Word Wrap in an Android Multi-Line TextView
  • Create borders on a android view in drawable xml, on 3 sides?
  • Getting the next AUTO_INCREMENT value of a SQLite database
  • Different app names for different build flavors?
  • Android - not able to attach a file in email
  • Android Layout background alpha
  • The scene uses orthographic projection, the sprites are textured quads, and I’m using the depth buffer to draw them front to back. I’m working with OpenGL ES 2.0, but thoughts from the iOS or non-ES worlds would be appreciated as well. I’ve tossed a few ideas around in my head of how I can go about this, and I’d like to find out which has the most promise.

    1. Draw each sprite twice, the first normally, the second with some kind of drop shadow shader a bit deeper in the scene. Not sure if this is possible?
    2. Draw a sprite, then draw it again, darkened and with some alpha, several times with some random jitter applied to the verticies. This may look silly and not at all like a shadow.
    3. Draw the base scene without background to a texture, then blur and darken it to create one large drop shadow. Then draw the base scene over the drop shadow texture, then finally over the background. This would lose the shadows between sprites, though.
    4. SSAO in a post-processing pass. Might be the most dynamic and automatic, but could look fuzzy/grainy and really slow things down.
    5. At creation time, generate a shadow texture for each sprite. For rendering, draw a sprite and then its shadow texuture a bit deeper in the scene. I think I’d like to avoid this due to the loading time and extra memory requirements, but this may be the fastest and best looking?

    I don’t want to do any shadow work with external textures, since I use the same sprite textures at varying scales, and pre-baked shadows would scale unnaturally.

    So are any of these better than the others? Are there other options I’m not thinking of? Thanks!

    Related posts:

    Android Bluetooth: Get UUIDs of discovered devices
    Universal image loader roundedBitmapDisplayer issues
    How do I detect touch input on the Android
    How to Change color of Button in Android when Clicked?
    Is proguard.cfg needed for library projects?
    Lazy Loading in ListView with Image. (Cursor Adapter)
  • Detecting when system buttons are visible while using 'immersive mode'
  • Is it possible to use GTK+ in Android?
  • Multiple SearchRecentSuggestionsProvider classes in Android app possible?
  • Fragments overlapping each other
  • This app won't run unless you update Google Play services error
  • Setting targetSdkVersion=“13” causes Activities to ignore android:configChanges=“orientation” flag
  • One Solution collect form web for “OpenGL ES drop shadows for 2D sprites”

    Those are all some well thought out options, here are my thoughts on each

    1. It is definitely possible to use a shader but it might not be the most performant option, since the blurring will have to be done inside the shader and might involve multiple texture lookups.
    2. Drawing the texture multiple times would work and would look like a shadow, because each “jittered” image would have slightly modified alpha values. But again, blending and multiple renders of each sprite would add up and might affect performance.
    3. I like and recommend this option, because you can set a shader that puts black pixels instead of colored pixels (considering alpha) into a render target smaller than the screen (1/4th?) and then use this as the shadow texture. Since the texture is now being stretched, you’d get the “blurring” for free, too. The pixel shader that does the “blackening” would be very simple and not affect performance too much.
    4. Unless you really need high-quality shadows (and the previous method doesn’t suffice) I wouldn’t recommend this.
    5. This is of course the most flexible option and has an x2 rendering complexity. Unfortunately, it will consume more memory than all the other options above.

    Hope this helps!

    Android Babe is a Google Android Fan, All about Android Phones, Android Wear, Android Dev and Android Games Apps and so on.