There is so much misinformation going on in this thread that I almost started to doubt my own knowledge on the subject. Most of it concerns a confusion regarding static and dynamic lighting concepts, which I'll admit, are a little difficult to grasp for some people. Nevertheless, it is in the general interest fighting the spread of ignorance and misinformation that the following facts shall now be revealed.

First and foremost, lightmap scale has literally nothing to do with projected textures. In Source we essentially have two forms of lighting, static and dynamic (this is also true of many other game engines although the emphasis is on dynamic these days).

Static lighting is calculated by vrad during the map compile and does not change at runtime whereas dynamic lighting is calculated entirely at runtime. Since static lighting doesn't have to be calculated while the game is running, it is significantly cheaper (in terms of CPU time) but isn't able to change the way dynamic lights can (so for instance, you can't illustrate a moving light source with static lights).

vrad's job (in its entirety) is to calculate the static lighting for a map. It does this by generating a special texture called a lightmap for any brush surface painted with a texture that uses the lightmappedgeneric shader*. The lightmap is then additively mixed with the surface texture at runtime.

Let's say you have a room with a few brushes strewn about the place and a static light in the middle:

vrad will calculate the static shadows and draw them to a lightmap**, like so:

The lightmaps are loaded into video memory when the map starts and additively mixed with the surface textures on-the-fly:

Although lightmaps are extremely cheap (computationally speaking) they can very quickly use a large amount of memory both on the disk (as lightmaps are stored in the .bsp file) and in video memory at runtime. Lightmap scaling is introduced to mitigate this problem. The default lightmap scale for a surface in Hammer is 16. What this means is that when vrad generates the lightmap for the surface, said lightmap will be 16 times smaller than (or one 16th of) the original surface size. At runtime, the texture is then scaled back up on-the-fly. This solves the memory issue but causes another: scaled down lightmaps cannot preserve crisp shadows because the loss in image size accompanies a loss in detail. An experienced mapper will balance lightmap scale per surface, creating high resolution lightmaps when detailed, crisp shadows are required; and lower resolution lightmaps to save memory when such detail is not needed.

Projected textures are a form of dynamic lighting. They are not calculated by vrad and they are not saved to the lightmap. Therefore, you can change the lightmap scale on a surface as much as you want; it simply cannot and will not affect the appearance of a projected texture because they have nothing to do with lightmaps.

The -textureshadows switch on vrad will also have no effect on projected textures because, once again, projected textures are unrelated to vrad. Additionally, -textureshadows deals with translucent textures on props and has nothing to do with brush surfaces.

Creating a grid of brushes using tools/toolsblocklight is an old but reliable method of creating static shadows but it also has nothing to do with projected textures or other dynamic lights. Vrad will not cast light through any face textured with tools/toolsblocklight (and will also not bounce light off it during radiosity passes) but these faces are removed when vrad finishes and are not present at runtime (when dynamic light is calculated).

Other suggestions included changing the Disable shadows and Shadows keyvalues on the func_brush which are also static lighting related and have nothing to do with projected textures either.

Basically, the entire compile process is unrelated to projected textures (in fact, projected textures will work in a map with no lights, with mat_fullbright set to either 0 or 1). In that respect, I find it impossible to believe that switching to an expert compile is what actually solved the problem; there's just no reason why this would be the case (especially if you're using the default expert compile, which is exactly the same as a normal compile). This is further proved by the fact that the OP managed to get the projected texture to work in another map without executing an expert compile, which proves that the problem lay elsewhere.

• This is a bit of an oversimplification; vrad also generates lighting data for static props (which generally use the vertexlitgeneric shader) as well as ambient lighting for light_env, but this is outside the scope of this post

** In this example I'm only illustrating direct lighting. Provided there are no leaks in the map, vrad will also calculate global illumination to make the scene much more realistic.

Wow Nacimota. Thanks a lot for that clear and detailed information. I've just learnt a damn lot in only 2 minutes!

Nacimota wrote:
Nevertheless, it is in the general interest fighting the spread of ignorance and misinformation that the following facts shall now be revealed. [...] which proves that the problem lay elsewhere

Thanks Nacimota for these rectifications !
I've read your post 3 times : 2 times because i'm french, and a third one because there are many informations !

So, in facts, i don't know how i solved the problem...
But thanks to your post, i decided to remove the env_projectedtexture to free CPU time, since i didn't need a dynamic light (the light source was not moving), and created a grid of brushes using tools/toolsblocklight, as you said we could.
There were then static shadows on the walls, but not sharp enough to me, so then i changed the lightmap scale of these walls, from 16 to 4.

Here are the Hammer's and the game's screenshots :

Sans titre5.jpg portal2 2012-06-26 01-10-11-87.jpg

Yes, that is an old trick. I told you about it in my very first post...

Brainstone wrote: