Glossmap for per pixel lighting


Ron Frazier proposes in his advanced per pixel lighting tutorial to use a gloss map that is multiplied with the specular map to exclude some parts of a polygon from shininess.
I wonder if this map is really necessary since you could just make the parts of the specular map black that aren’t shiny. Since the specular map is added to the polygon, the parts with black color won’t affect the polygon. This would save one texture unit.

Am I missing something here?

Thanks in advance

The problem is that, from what I can tell, the specular map isn’t explicitly mapped to the object that you are lighting. The texture coordinates are generated depending on the camera and light positions, which means that if you encode non-shiny areas into your specular map, they will shift around and not stay where you want them to be.


Zeroing out your bump map to kill the specular in the dull areas is certainly one option I didnt mention in my articles. This does raise some additional issues too.

One issue is that you now have to have separate diffuse and specular bump maps (since you dont want to gloss map the diffuse) instead of just one. In such a case, you use some additional texture mem (a gloss map takes less texture memory to store than a second bump map would). You could opt to store the gloss map in the alpha component of the bump map and ignore the alpha component when doing diffuse bump mapping. The down side to this is that you may already be using the alpha component to do mip-map fading. Of course you could try pre-multiplying the alpha-fade into the RGB portion, but you might run into precision limitations. Remember, we already have precision issues with specular as it is. You probably dont want to go out of your way to make it worse.

Another issue is that sometimes your bump maps dont map texel for texel to a diffuse texture map. For example, you may have a small bumpmap that is tiled over a given quad, while the diffuse texture map isnt tiled. In such a case, you would probably want your gloss map to correspond to your diffuse texture map, not your gloss map.

-Ron Frazier

[This message has been edited by LordKronos (edited 05-08-2002).]

Originally posted by j:
The problem is that, from what I can tell, the specular map isn’t explicitly mapped to the object that you are lighting. The texture coordinates are generated depending on the camera and light positions, which means that if you encode non-shiny areas into your specular map, they will shift around and not stay where you want them to be.

If I understand you correctly, I think what you are saying would not be an issue. The way LaBasX2 is suggesting, your would just zero out the RGB components in the bump map. When you try to dot this with your light/half-angle/eye/whatever vector you would always get a zero from it, which would kill the specular when multiplied into the equation. However, there are other issues, as I mentioned above.

-Ron Frazier

[This message has been edited by LordKronos (edited 05-08-2002).]

Ah, that makes sense. When I read “specular map,” I thought of a 1D texture that would be used as a look-up for calculating specular exponent. Seeing as I hadn’t read your page yet, I guess I jumped to a conclusion too quickly.


There are two factors, one is the gloss/specular map which is fixed with the surface and the other is the reflected light which varies with viewing conditions. You can only join them when you render with the lighting calculation for the specular term which is view/object/light position dependent.

I did this using destination alpha a long time ago on SGI systems. You can see the results at the bottom of the page here:

There’s no need to use destination alpha, especially if you have multitexture but I had a single texture unit and was also using it for a high quality spheremap specular highlight. This also predates the ability to independently interpolate separate specular term in a single pass and add it post texture (or modulate it) so multipass would have been essential even without using destination alpha or texture spheremap specular.

[This message has been edited by dorbie (edited 05-08-2002).]

First, thanks for your replies.

LordKronos, I’m not trying to zero out the bump (normal) map but the specular map. I think you are also using that map. It is a 2D RGB texture similiar to the diffuse texture that contains the specular color of a surface on a per pixel basis. If the color for a texel is black, there is no shininess for that texel. Furthermore I’m using the same texture coordinates for the normal, diffuse and specular map. So one pixel from the normal map will always correspond to the pixels in the diffuse and specular maps. If the normal map is tiled over a polygon, the diffuse and specular maps are als tiled.

We have tested using only a specular map instead of a combination of specular/gloss map on textures where only some parts were shiny and it seemed to work perfectly.

Yeah, that makes more sense. I kind of forgot about the specular color map. If you have one of those available, I dont see any harm in premultiplying the gloss into it.
The only issue then is that once you mix the 2, its a little more confusing to edit your source textures. You may want to keep a photoshop file with separate layers for the specular and the gloss.

Sometimes you may be using a vertex color for the specular (or you may still have specular and gloss maps that dont correspond texel for texel), so a separate gloss map would still be useful in those cases.

-Ron Frazier

[This message has been edited by LordKronos (edited 05-09-2002).]

Thanks again for your reply, LordKronos!

There is still one thing I’m wondering about:

I’ve read in John Carmack’s plan file that doom3 is using 6 texture units and that the cube normalization map is accessed twice.

I think that these maps are:

  1. 3d attenuation map
  2. cube normalization map
  3. normal map
  4. diffuse map
  5. specular map
  6. ???

What could the sixth texture be? Of course it could be the gloss map but I don’t think that Doom3 will really use it if it isn’t necessary.
Any other ideas what the sixth texture unit could be used for?



I’m sure most lights in DOOM III are spotlights, so it could be a 2x1 texture to eliminate backprojection and a 2D texture for inner/outer cone angles ( raised to some power ). It could be a million things.

Also, a lot of things really only require one channel ( like using the alpha channel for occlusion effects ).

When you said specular map modulated by gloss map I assumed by specular map you meant some kind of environmental cube map for high quality complex environmental specular reflection. In your case your specular map is your gloss map, most people wouldn’t make any distinction between the two. You just have a color gloss map not a monochrome one. That seems a little unusual but each to their own.

Originally posted by LaBasX2:
Any other ideas what the sixth texture unit could be used for?

Could be a spotlight filter (maybe John even put one of my disco lights in the game…what? you dont think so? oh well ). A gloss map. A detail map. He could have just been counting the normalization cubemap twice.

-Ron Frazier

PH, I think the stencil operations would resolve any back projection issues. I’m not sure if they are correctly described as spots or mostly full on point light sources. I think some kind of projective texture would be a good candidate, but that too would be back projected and would actually make point sources look strange, maybe some kind of projective cubemap approach from the light could be correctly implemented in the geometry engine, that would be a totally general approach to spotlights (P.S. This would make it your disco lights Ron right? We must have been writing at the same time).

I agree it could be many things. It might be used for soft shadow effects on dynamic objects after render to texture from the light, this is related to the projective spotlight radiation and could include it’s overall modulation. OTOH there may be a need for some kind of adjusted light vector interpolation for high quality local lights on big surfaces, for instance, although subdivision might be a more ballanced approach (and I think you need 3D texture & 4D coords for that (and it’s signed components so you end up with 7 bit + sign normals).

All this is also only for a single light source, each lightsource would require similar treatment in a rendering pass of it’s own (but reusing some textures). My understanding is that a lot of the smarts in DOOM3 are limiting the scope of rendering for a specific light to objects illuminated by the beam tree for that light.

[This message has been edited by dorbie (edited 05-09-2002).]

You might be right - the stencil operations could be used to eliminate back projection. And as you mention, using cubemaps to implement all lights is probably the best way ( for generality ). I’ve previously used cubemaps for lights that illuminate more than a 180 degree FOV ( with the “back” half of the cubemap filled with zeros ).

It should be possible to use 3D textures to implement soft shadows ( with selfshadowing ) in “real-time”. I’m positive Carmack has an option in the renderer for soft shadows ( in one form or another ).

Yes, you’re all right, there could be many ways in which the sixth texture unit could be used.

About shadows:
Are there any further information out there about soft shadows using 3d textures? Any papers? Or is this still unresearched at the moment?