That's just how lightmaps are handled in Quake2- they're 1/16 the resolution of the original textures. Shrinking the texture on a surface will get you more detailed lightmaps, but also more surface splits and it may cause errors (MAX_MAP_LIGHTING) in the light phase of the compile.
`-chop 16` is a terrible idea. It'll cause your faces to be subdivided at regular 16 unit intervals, and it has next to no effect on lighting. Have you ever looked at what this does to your r_speeds / gl_showtris? The first thing I usually recommend to people in trying to improve their map's performance is to use `-chop 1024`. All `chop 16` will do is literally raise your r_speeds by an order of magnitude (default is 256, 16x16 = 256). Do not use this method.
`-extra` actually will improve lightmap jaggies because it forces the light sampling algorithm to use "extra" sample points -- coordinates adjacent to the default sample coordinates -- for gathering light. It's your basic Gaussian blur algorithm, where several points in a cluster are measured, and then their average value is used as the result. Works fairly well, but inflates your compile time significantly. This is why most mappers save this option for their final bake.
`-bounce` defines how many times a light source will reflect off of CONTENTS_SOLID before completely dissipating. This is known as the "indirect lighting" pass, or the "radiosity pass", and is where the `-rad` compile stage derives its name. This was new to Quake2; Quake1 did only direct lighting. Higher bounce values (default 4) can give your map a more cohesive ambiance, and will soften some shadows up, but is probably not the answer to the OP's issue.
I think Knightmare and Jitspoe both have some improved tools that may help alleviate what you're seeing in your map. The problem is two fold: 1) Quake2 does in fact use a very low resolution for lightmaps and 2) at this low resolution, false collisions (very common near surface edges) cause shadows to seep through corners. The solution is to nudge the sample positions during the lighting calculation towards the surface center, and along the surface normal. This prevents false collisions during the light gathering pass, and you see fewer of these artifacts.
As I said it's been a while since I tried this, so maybe it was 32 instead of 16. Here I was just going by the manual with smallest value, in order to yield higher quality, based on the following assumption:
Smaller -chop sizes can yield higher quality, but will dramatically increase time and memory requirements..... size: 16-256
Interesting! It seems like Arghrad has its own -chop (and -chop*) parameters. In that case, your suggestions are correct, Null. My bad.
That's kind of a curious choice on Argh's part, since the standard issue tools from id Software have a -chop option on the BSP stage, which will do exactly what I described above. But if you _only_ provide -chop to Arghrad and NOT qbsp3, then you won't hurt your r_speeds at all. Thanks for providing that link.
With that said, based on my own experience in implementing some of these features in q2wmap / quemap, the areas where you'll likely see the most improvement are on Phong-shaded surfaces and light-emitting surfaces. So I would recommend starting with just -chopcurve and -choplight as a general rule of thumb. My lighting compiler automatically increases patch precision on Phong objects and light emitters.