is it possible to combine radiosity calculated lighting (lightmaps) with per pixel lighting ?
There are no engines using this so i belive it is not possible , but why ?
Lighmapping are a form of texturing where the map store the light[s] contribution into each texel.
So, lightmaps work already on a per-pixel basis.
More precicely, this work on a per-texel basis, but with the help of various texture interpolation mode (cf. bilinear, trilinear and/or mipmaps filtering), it’s near the same thing …
ok so you explained me how lightmapping works, that`s not what i asked.
i asked if i can use lightmapping for static lights and per pixel for dinamic lights, and if the two types of light cand correctly interract.
Yes you can.
in fragment program :
- a = sampled lightmap
- b = computed dynamic lighting
- finalLighting = a+b
- outputColor = finalLighting * yourColor
well then it seams this is a perfect solution for lighting…
why then doesn`t half life 2 use ppl + lightmapping ?
or doom3 lightmapping for their static lights ??
Half-Life 2 : I personnaly think that thier graphic engine is total crap. It only looks good thanks to good artists.
</me ducks for cover 
>
For Doom3, not using precomputed lightmaps allows for smaller data, and no need for precomputing lighting level. As all the lighting is done in real time, it allows quicker level design (only static light/static geometry volulme shadows are precomputed at level load, and this is pretty fast).
And problem would be with static lights, between moving monsters and static crates, shadows would not look the same. I think it is more about giving an uniform visual feel.
In some situations though, sorts of ‘lightmaps’ (some B&W textures) are cast, like blurry grates shadows, large rotating fans, etc. But they are placed by hand, and there is only a small number of different textures.
I think another reason is that the video hardware target for doom3 was Geforce3 (as well for xbox version). Maybe memory footprint and texture access would have been too costly.
However, I would admit that using precomputed radiosity for ‘secondary photons’ and ppl+stencil for direct lighting seems very interesting for current hardware… If I had some more time/knowledge to actually implement this …
Of course one can combine those techniques. However, one will be able to see the differences.
You cannot use Lightmaps for “per pixel” lighting, because the amount of memory needed would be huge. Therefore lightmaps always cover several pixels at once, which makes them look a bit blurry whereas dynamic lighting usually looks quite sharp. Also your shadows will be different, those from the lightmaps will be soft (and sometimes blocky) but stencil shadows are absolutely hard. And because of the issue, that lightmaps won´t store the information for every pixel, you won´t be able to use bumpmapping for the computations. Additionally the lights, which get encoded into the lightmap will not have specular lighting, as long as you don´t do another pass per light to add it, but then you will need to use a normalmap to get nice specular and when you are there already, you could also do diffuse lighting in the shader, too.
So, yes, it is possible, but if you combine them, you will definitely have problems to get a quality which looks equal everywhere. Certainly Radiosity is a nice thing, but it is only for diffuse lighting, whithout bumpmapping and the moment you put any nice effects into your dynamic lights, it will look strange.
Half-Life 2 has the same problem and i think they had a hard time to make it look decent.
Jan.