When you bake a diffuse lightmap you're pre-integrating your lighting environment at each texel with your BRDF. You can do this and end up with a single value because you assume that the surface normal never changes, and that the reflected light doesn't depend on the viewing angle (which is true for a Lambertian BRDF). For most other BRDF's that last assumption doesn't hold, so you can't really use the same approach and get correct results. You would need to either...

• Store the lighting environment without pre-integrating your BRDF using some sort of basis (such as spherical harmonics), and integrate your BRDF at runtime taking the current viewing angle into account (with this approach you can also vary the surface normal at runtime, which allows for normal mapping)
• Pre-integrate with your BRDF and store multiple values corresponding to multiple viewing angles, then interpolate between them at runtime based on the current viewing angle
• Don't change the way you bake lightmaps, and instead attempt to apply some approximating curve to the value that takes the viewing angle into account.

When you bake a diffuse lightmap you're pre-integrating your lighting environment at each texel with your BRDF. You can do this and end up with a single value because you assume that the surface normal never changes, and that the reflected light doesn't depend on the viewing angle (which is true for a Lambertian BRDF).

I definitely get that, at least up until the "reflected light doesn't depend on the viewing angle" -- that's, to some extent, where I'm still a little bit confused. It doesn't seem to be the case, (at least a priori), that view-angle dependence need to take into account light angle as well (particularly for "diffuse" materials); in fact, this:

Don't change the way you bake lightmaps, and instead attempt to apply some approximating curve to the value that takes the viewing angle into account.

is indeed what I'm looking for. The only question, then (aside from the obvious "what's a good function to use?") is, in what sense need this be only "approximate"? Does it violate one of the properties of "physically-based" BRDFs (and, if so, is there any reading you recommend so that I can gain more insight into what this violates specifically?)

One thing you could do (and I would recommenced this if it is feasible) would be to calculate direct lighting dynamically (that way you could use a Oren-Nayar BRDF) and then for indirect lighting, use low resolution light maps that contain indirect light only. Alternatively you could use directional light maps or something like H-basis coefficients to get better indirect lighting. My intuition is that for the indirect light, Oren-Nayar wouldn't make too big of a difference.

So all I'm really hoping is that I can do this without needing to grossly change what I'm doing now (which is baking all of my diffuse lighting into color-only lightmaps) -- I understand the impulse to store more information in my lightmaps or include dynamic lighting (which also means dynamic shadows) but to be honest the visual quality I'm hoping to gain really doesn't justify this (and in fact I'm beginning to suspect may not be worth it at all).

Regarding indirect light, though, my intuition also would have initially been that it wouldn't make too much of a difference, although my observation that it's actually more viewing-angle dependent than I first thought leads me to believe that this may not be the case, hence my quest for something suggestive of this sort of shading that doesn't take into account light angle at all (beyond what is already being accumulated into the basic lightmaps)

My mistake, it seems that I misinterpreted your goal. I assumed you were going for physical accuracy and based most of what I said off of microfacet models. The statement about Oren-Nayar having more in common with Phong specular was limited to "The result changes as both light direction and view direction change."

Anyhow, glad to hear you have a solution you're happy with in Minnaert (which sounds a lot like what you propose with inverse N dot V)

Yeah, thanks. It does seem like Minnaert (at least as interpreted by Blender; I've heard rumors that "Minnaert" refers some different but related functions, some of which seem to be more physically-based than others) is what I am going for; I read the glsl code for Minnaert and Oren-Nayar, and (as everyone said), there's no way to get the light angle to go away in Oren-Nayar, but to my great happiness, Minnaert doesn't rely on the light angle at all (except as dotted with the surface normal).

Have some up-votes, everyone, but know that this doesn't mean I won't probably come back tomorrow with even more stupid questions.

I'm going to post some screenshots from Blender in case they might help explain what I'm going for. Here is an image with the Lambert, Minnaert, and Oren-Nayar GLSL materials; when the viewing angle is similar to the light angle, Minnaert and Oren-Nayar look very similar (and could potentially be tweaked to be more similar):

And here's the same three (I flipped the image so that Lambert is still on the left) with a viewing angle that's very different from the light angle. In this case, Minnaert is the odd one out, which, knowing what I know now, makes perfect sense:

In any case, the Minnaert shader gets the "rough" look I was hoping for, and I don't know enough about either the origins of this Minnaert shading or physics to say how "weird and unphysical" this is (I've heard that it's based on observations of the moon, but I've also heard that about Oren-Nayar; the fact that almost everyone who's replied so far thinks intuitively that what I'm after breaks some kind of important rule of physically-based shading suggests that maybe Blender's implementation of Minnaert is strange or even "wrong")

I'll probably post an update concerning whether I find that using this kind of function (but obviously not Blender's GPL'd code...) in my own game makes it look prettier -- if nothing else, it seems like something that hasn't really been tried much, so I'm curious.

Thanks again!