Four models are used for the cargo container sides, each having 3 levels of LOD which you can see in the image above. The transition between these models is practically seamless.

Some r_speeds screenshots for comparison, also, notice the detail loss at a distance, total transformation is from +1000 polygons for the detailed version and ~50 for the one with least polygons.

Ambient occlusion is baked in the model texture which makes it look less flat in-game (no lightmaps can be baked on dynamic models). I will create a common shader which will be used for clipping and casting a shadow on the map geometry.

So, I've been trying to render HD lightmaps in q3map2 without success. The process takes too long and you may not get good results in the end.

Blender can bake shadows on models so I decided to test it with TC:E.

The simplest method I could come up with was:
-exporting a map to .ase format
-removing unneeded faces and unwrapping it (lightmaps need unique UV's)
-reimporting it in Radiant over the original geometry

Here are some images of the last steps of the process:

.ase model with baked shadows on the left, original map on the right:

.ase model placed directly over the original geometry (notice the z-fighting):

I know my shadows are faint in comparison, still working on finding the best contrast. Also, some radiosity (bounce) and perhaps bump maps would be nice.
Surfaces in-game shouldn't be lighted but lightgrid should still be calculated for dynamic models.

In the end, this method requires more work but the results are rewarding.

If you're wondering about the size impact, Northport has 60 lightmaps at the size of 11MB. That's because the default lightmaps are .tga. weighing ~200KB at 256x256. I can make 1024x1024 lightmaps (like the example above) at 20-40KB's. That is a lot of room for HD shadows.

Don't worry about the compression artefacts, since they're blended on detailed textures, none are visible in-game.

I dont know, i just didnt see huge difference between TCEs stock maps shadows and yours, maybe i just dont remember well enough.
But compared between your q3map2 picture and .ase picture it seems to be quite of an improvement.

Wish: if you do some awsum maps for CQB some day, use those darker shadows a lot, i think TCE has too few maps like that

aaaand why the hell i got 5 emails regarding to this topic

Edit: Is it possible to "mix" those two techniques? Q3map2 seems to have some very dark corners and object sides but your models have very "realistic" feel in the shadows. That could do a great mix and give some nice Mood to some maps.

From my understand, however, unless a mix of both techniques is used, dynamic objects (and thus player models) will not come under shadow rendered this way, is that correct?

That's right, I still need q3map2's light stage to render the lightgrid which affects the dynamic models. I'll just leave out the lightmap generation.

One of the things on my to-do list is find the correlation between q3map2's and Blender light parameters. So a lamp placed in Blender seems to cast the same amount of light on the geometry as the light in Radiant casts on the dynamic models.

The cargo container mentioned earlier would also fall in this category since it is implemented as a misc_gamemodel but using this method I can bake proper lightmaps on it which will be seen on the LOD versions as well as long as each model has it's own unique UV maps.
Yeah, this means a unique texture per model so maybe I'll have to compromise with model's texture resolution and placement.

You can also use a much higher lightmap resolution in q3map2 (TCE uses 4 pixels, CQB probably 3, if wanted one can use 2 or 1) and save it at any tex format you want, e.g. 1024 * 1024. It is also possible to compress external lightmaps afterwards, e.g, jpg. This would, of course, only keep the distribution package small, it doesn't matter in game.

Also, artifatcs are not expected in TCE or CQB since they use no overbrightbits which caused problems in the original Q3 series, leaving only 6 bits for colors and pushing compression artifacts.

In the end, the lightmap resolution is pretty much a decision about texture memory. CQBs sample map currently has 25 512*512 lightmaps with a resolution of 3 pixels, which is slightly better than TCE. I don't know how the minimum system spec would respond to something like 60 1024*1024 lightmaps for single pixel lightmap resolution.

I very much like the door mechanic on the containers and this is really needed. Due to the lighting problems with gamemodels I would let the container body be static with reasonable details (misc_model) and let the mechanics only be a lod model.