Q3 engine and the 128x128 lightmap size limitation
That's something that have bored me since I started to map... How can I override this stupid limit of lightmap size.
When you are still new to mapping, you just don't understand why adding a key _lightmapscale with the value of 0.25 or 0.125 to the worldspawn give pretty good result on some part of the map, while being extremely ugly and blurry on some other. Because we all are very naive, we just think "let's reduce this damn value until it looks good", but it looks never good.
Why?
It is a little technical...
Q3 engine only handle 128x128 lightmap. So even if you specify a smaller value for lightmapscale or samplesize, or whatever, all your mergeable surface will be put by q3map2 in a 128x128 lightmap. This is why tiny brush have a good lightmap precision while large flat terrain have bad. Each tris can't have more than one lightmap, so larger tris can't have too much precision. And that's not all: if you have a flat surface made of multiple tris, all those tris share a single 128x128 lightmap. They are merged. Why? Because if they were not merged, you would not get a seamless lightmapping on this surface, because each tris would have a different lightmap precision, so shadows would be very sharp on small tris, and very blurry on some other, and that's a major problem especially if this is the same shadow that lie on multiple tris.
If you doubt about it, you can test it, for example by turning each ground brush you have into its own separated func_group. Face in a func_group will never be merged with face that are not in the same func_group (using this property is a common way to fix light leak). That was my first attempt to get more precision... That was awfull...
How to override the 128x128 engine limitation
I have searched the web forever... I have never seen someone getting it. I have found many forum thread talking about that, some people's answer was: "use the -lightmapsize switch of q3map2", but they have probably never tested it, cause this switch is for Wolfenstein/ET, if you use it for Q3, you get a full illuminated map, cause the engine just don't load those lightmap.
There is only one solution, I found it yesterday, you should use shaders. You should use an external lightmap. Ydnar (the author of q3map2) does that for this purpose! Too bad this feature is just badly documented (as many q3map2's feature). For each surface you want to have a greater lightmap, you have to write this shader:
- Code: Select all
textures/my_dir/my_texture_hi_res_lightmap
{
q3map_lightmapSize 1024 1024
q3map_lightmapBrightness 2.0
{
tcgen lightmap
map $lightmap
rgbGen identity
}
{
map textures/my_dir/my_texture.jpg
blendFunc filter
}
}
"q3map_lightmapSize 1024 1024" instruct the compiler to put the result of the lightmap for all face using this shaders into one or more external TGA image file (standard lightmap are directly stored into the BSP) with a 1024x1024 size, that will be written in your /map/name_of_your_map directory, then q3map2 auto-generate a shader file in the /script directory named q3map2_name_of_your_map_lightmap.shader. Here is what you found in this file:
- Code: Select all
// Custom shader file for my_map.bsp
// Generated by Q3Map2 (ydnar)
// Do not edit! This file is overwritten on recompiles.
my_map/7132892A3E304A3B1AEC29CEB002847F
{
q3map_lightmapSize 1024 1024
q3map_lightmapBrightness 2.0
{
tcgen lightmap
map maps/my_map/lm_0000.tga
rgbGen identity
}
{
map textures/my_dir/my_texture.jpg
blendFunc filter
}
}
That's the trick! Your external lightmap is just meant as a standard texture! Be carefull, cause q3map2 is forced to create one shader for every lightmap/texture combination. That's why it is best to use a huge lightmapsize, you have good chance that one texture will be combined with only one lightmap.
q3map_lightmapBrightness 2.0 instruct the compiler to render the surface twice as bright. You should have this to work cause standard lightmap use overbright bits, without this line, your surfaces will look darker than usual. With a value of 2.0, they will look exactly as bright as it used to be.
In the stage part of the shader (remember that stage are for the renderer, while q3map_* are directive for the compiler), there is an important line: tcgen lightmap. That's the trick I missed for days... In all usual shader (using true built-in lightmap), this line is implicit. But here we use a conventionnal texture that play the role of a lightmap, so the renderer should be aware that we want to use the lightmap coordinate calculated by q3map2 for this surface.
The end of those two shaders have nothing particular.
Note that if you want to use this trick for your terrain (modeled or indexed), you should add the directive q3map_lightmapMergable, because you want to merge all tris of your terrain into one continuous and seamless lightmap. I think you need (not tested) q3map_nonplanar and q3map_shadeangle N, and I suggest to tune the value of a q3map_lightmapSampleOffset N.
The result:
Ooops, it looks like Blogspot have some protection against hotlinking... To see screenshots of Alamo patched with hi-res lightmap, please visit my blog:
http://sgq3-mapping.blogspot.com/2009/0 ... htmap.html
Don't miss them! This is really impressive!
Just too bad that I found that trick one week too late...
