Something I thought I should mention that I realized only recently. In the section "Usage tips", I realized I was in error by saying that you need to swap the green & blue channels to make it work with RH normals. It is actually much simpler to swap the bottom two vectors in the basis in the shader to get the same effect at no extra cost. This way, you can use readily available tools, without any need to modify their output and introduce another step in the content creation pipeline.
Other than that, forget to mention the bonus pictures I added to the end of the post. Check them out, if you haven't already. ;)
SashaRX was asking about reflection vectors from an SS Bump map, so I thought I'd add it up here where everyone can see. Basically, all you need to do is get a tangent-space normal back, and then apply standard techniques from there. This is achieved by applying an inverse transformation to the SS Bump value using the basis vectors. Using just the basis vectors, the result will be in tangent-space. If you concatenate the tangent2world matrix with the basis vectors, you can transform staight to world-space.
Hope that helps. ;)
tanNormal = bumpBasis * bump.x + bumpBasis * bump.y + bumpBasis * bump.z;
tanNormal = normalize(tanNormal);
For those who don't know, Self-Shadowed Bump maps were originally developed by Valve for use with their Radiosity Normal Mapping technology. After I decided to make the switch to a renderer built around pre-computed data, this was one of the first things I decided to try out. If you wish to read more about the technique, the following links have provided me with most of my information on the subject.
 SSBump Generator (used to make the maps)
During the course of my experiments, I have verified all the benefits that Valve described in their papers. However, I have also discovered a few drawbacks that they didn't mention. Keeping that in mind, I have pooled and summarized my findings from all the papers and my own experiments.
Recovers bent normals
Better use of byte precision
Faster than tangent-space normal maps
NOTE: Only for RNM, not for general diffuse lighting
Diffuse Lighting expense
In order to get dynamic lighting with directional occlusion, each light direction has to be projected onto the basis. This boils down to the same amount of math as a 3x3 matrix multiply, per light direction.
DXTC causes artifacts at detail edges, and nasty blocky artifacts in specular/reflection
RGB5 is acceptable for diffuse lighting, but produces banding for specular/reflections. Also, this format is not supported by Direct3D 10/Xbox 360.
Figure 1. 1, Height map; 2, Normal map; 3, SS Bump (no DO); 4, SS Bump (DO); 5, recovered tangent normals; 6, no DO; 7, DO; 8, reflection
Figure 2. 1-3, RGB channels; 4-6, lightmaps w/o masks; 7-9, lightmaps masked
I added these images to help visualize how these maps just store multiplicative masks for the lightmaps. Note how sides facing the light direction receive almost no darkening, while those that are occluded are darkened to give the impression of shadowing.
Figure 3. 1, SS Bump map; 2, Detail map; 3, combined with SS Bump; 4, recovered normal; 5, diffuse lighting
This trick works since an SS Bump map is just a series of masks that get multiplied with the lightmaps. Since the lightmap data will be multiplied with the diffuse texture, we can effectively multiply the diffuse texture by the detail map if we just apply the detail map evenly to each color channel in the SS Bump map. This even weighting of each channel is what ensures that the recovered tangent normals are unaffected by the detail map.
Figure 4. 1, DXT1 SS Bump map; 2, diffuse lighting; 3, reflection
Figure 5. 1, RGB5 diffuse lighting; 2, reflection
Most tools that generate SS Bump maps will format them for the Source Engine, so they assume a left-handed coordinate system. This will cause issues with any programs that use a right-handed coordinate system. Fortunately, this issue can easily be fixed in a decent image editing program (Photoshop, Gimp, etc).
Here, you just need to invert the contents of the green channel to flip the Y-axis.
Figure 6. 1, normal LH; 2, normal RH
Self-Shadowed Bump maps:
Here, you have to swap the contents of the green and blue channels.
Figure 7. 1, SS Bump LH; 2, SS Bump RH
Other than that, I thought I'd mention a problem I encountered while writing shader code to use these maps. The order of the bump basis vectors as Valve listed them in the paper can be a bit confusing, and will produce incorrect results that will have you scratching your head for days. To save you that trouble, here is how they should appear:
static half3 bumpBasis =
half3(sqrt(2.0) / sqrt(3.0), 0.0, 1.0 / sqrt(3.0)),
half3( -1.0 / sqrt(6.0), 1.0 / sqrt(2.0), 1.0 / sqrt(3.0)),
half3( -1.0 / sqrt(6.0), -1.0 / sqrt(2.0), 1.0 / sqrt(3.0))
Despite the added storage and lighting cost, the benefits from using this technique are too enticing for me to pass up. So I have decided to integrate this technology into my new renderer for handling static objects. Dynamic objects, or anything that needs detail normal mapping, will still use Partial Derivative Normal maps for efficiency & flexibility. Between these two solutions, I should have a sufficiently versatile system for generating pleasing visuals.
Something I should have added a long time ago, there are two screenshots that have been sitting the in the comments section for some time now. They use a, SS Bump map from Valve's wiki, and really shows just how much depth this technology can add to even a flat surface. Check them out! ;)
SS Bump map from Valve's wiki, "$ssbump"
Figure 8. 1, 0 degrees; 2, 90 degrees