how many FBOs is too many?

This has probably been discussed before, so please forgive me as I’m searching through the forum, but I am generalizing my shadow map code and am wondering which of these approaches would be better.

  1. Have a FBO for each shadow casting light, then when a shadow map needs updated just bind this fbo and go for it.

  2. allocate depth textures for each shadow casting light, and a pool of color textures of the used sizes (for completeness), when a shadow map needs updated use 1 fbo for all, and link up the texture ids stored in the light.

The world is somewhat arbitrary, so I don’t know how many shadow casters there will be at one time, but probably only a couple that might need updating in a frame. (for obvious reasons)

Any thoughts are much appreciated.

First of all, you don’t need a colour buffer for completeness, depth only is fine. In your FBO setup call DrawBuffer(GL_NONE) and ReadBuffer(GL_NONE) rather than attaching a colour buffer.

The general recommendation is that you have a single FBO for all textures of the same format and dimensions. It is also recommended you reduce FBO switches as they can be slow whereas changing attachments is relatively cheap.

If your texture is the only buffer in the FBO you might not see any adverse effect in attaching textures of different dimensions, I’m not entirely certain if this really holds with many updates though, perhaps someone can confirm?

I always found this reference very helpful when first familiarizing myself with FBOs:

I would recommend pooling the depth textures too, if you haven’t done that yet.

Madoc, thanks, you are correct of course about not requiring a color buffer, and reviewing my FBO abstraction that I wrote about 2 years ago, it also doesn’t require one.

Scratt, thanks for the link, but I’ve implemented FBO in 2 different game engines, so the nuts and bolts are not a problem, it’s more about driver reaction to it that I was questioning. According to the spec you can certainly have a different FBO for each shadow map, but that doesn’t make it a good idea for performance.

The previous stuff I’ve done just relied on one shadowed light, but the next project will require an unknown number, thus the expanded support, and pooling certainly makes sense if changing a texture of the same size out of an attachment is cheaper than the bind operation, which makes sense.

Thanks for the responses, it’s much appreciated.