I’ve tried compiling my map with the normal q3map and q3map2 using the same parameters, with a lightmap sample size of 1x1 to get nice shadows. With q3map it’s all well lit up but I run out of lightmaps soon (low limit). With q3map2 that won’t happen, but the detailed shadows will only affect walls - floors will look like their lightmap sample size was set to something like 32x32. And it looks horrible. Any ideas?
The command line I’m using is -fast -super 2 -samples 1 -bounce 2 -patchshadows
Why don’t you specify the areas where you want incredible shadows by func_group’ing things, and setting the _lightmapscale on them?
Maybe your floor brushes are too big? The bigger the brush, the harder the compiler finds it to fit a lightmap to it without wasting huge amounts of lightmap space.
Also, isn’t it -samplesize N to shrink the lightmap samples size. -samples N is something to do with lightmap blending/sub-sampling.
No, it’s not that -samples thing because the wals were well lit up. Anyways, doesn’t matter. I’m now using normal q3map with a samplesize of 3x3 and -extrawide, and it looks excellent. Defined, soft shadows cast all over the place 
Uh.
Using an older version of Q3Map is certainly your choice, but you’ll pay for it in time, BSP size, frustration and your hair will fall out. *
Lightmaps are limited to 128x128 pixels, so if a brush face or a set of contiguous, coplanar brush faces are too large to accomodate a low samplesize lightmap, it increase the sample size until it can fit.
You can prevent this from occuring by splitting the floor into a few func_group entities, and use _lightmapscale to set the lightmap sample size for each.
This is preferable to using the -samplesize switch, which blows out BSP size by wasting lightmap detail on stuff that won’t need it.
y
Well I’m going ahead with q3map because splitting brushes will lead to high polygon counts. If what you say about frustration becomes true, then I’ll do that stuff… but really, my map is already high on polys (it’s the MGS2 Liner which I am revamping) and doing that will kill the framerate, I prefer a big BSP. Anyways, I wonder why normal q3map compiles it right and q3map2 doesn’t? I mean, with q3map I don’t have to split up my brushes, isn’t that weird?
I did not say split your brushes. I said group chunks of them into func_groups. You don’t have one giant brush as the deck of the oil tanker, do you?
Even if you did split the brushes, the number of lightmaps that a full ship of that size with samplesize 3 would make the polygon count the least of your problems.
Compile the map with Q3Map2 (make sure to use -meta in the BSP phase) and check the r_speeds–all numbers, not just triangle counts. Then recompile with Q3Map (1) and check the r_speeds in the same location.
Also, compare BSP sizes and compile times if you wish. The rest being equal, a larger BSP generally means lower FPS on an equivalent map.
I could go into excruciatingly boring detail as to why this happens, and why neither Q3Map1 is right nor Q3Map2 is wrong, and debate for hours the pros/cons of splitting brushes versus grouping, sample size, shader and vertex counts, BSP size ad nauseum.
But I won’t, so you’re just going to have trust me.
y
What about using the shader parameter q3map_lightmapsamplesize to control which surfaces have high shadow detail and which not?
So far it seems to work with normal q3map, but I might be wrong.
Yeah, now you might think I’m trying to avoid q3map2 at all costs, and you’d be partially right. Why, you might ask… that weapon fire bug. Weapons fire graphic looks corrupted when I compile with q3map2. If there’s a fix for this, I might just go ahead and try out what you’re saying 
Are you creating a map for RTCW SP?
RTCW SP has a bug in the shader code that allows an overflow due to a mismatch internally of a couple maximums. That and it has a billion shaders loaded at any time, and large maps with lots of lightmaps generate tons of shaders.
You can use the -nocollapse switch in the light phase to disable identical lightmap removal, which usually reduces the number of unique shaders used by the BSP at the expense of more lightmaps.
Otherwise, you’re more or less f*cked. You’ll eventually run into that bug whether you use Q3Map2 or not.
To recap: a high number of textures/shaders and lightmaps will create a lot of unique BSP shaders, and will overflow, causing the “weapon fire bug.”
y
That’s one way to do it. An alternative is to specify lightmap resolution via a “_lightmapscale” key on a func_group or other brush entity. It gives you finger grained control than per-shader.
y