Exactly what does it do? I haven’t seen a good description anywhere. I’ve tried -samplesize 8, and even 128 without a discernable difference. I’ve also tried this in combination with _lightmapscale in the worldspawn, but the scale is the only thing that seems to have an effect.
What settings would you need to use to get extra crisp shadows (in vQ3)? At best, even 0.0625 lightmapscale looks a little fuzzy in my maps.
i’m not 100 % sure as i didn’t realy see a difference either, i didn’t compare with screenshots though.
as far as i understand it somehow resembles how a lightmap pixel gets used in-game. so higher numbers should mean larger (?) shadows.
maybe good to get big shadows from small objects or get a more solid shadow from alphashadows borked due to too small shadowcasting details?
about lightmapscale, what u should be aware about is that a lightmap is 128x128 and a single surface of a brush (or patch) doesnt get split across multiple lightmaps as far as i can tell, instead it gets stretched to fit the whole surface. also surfaces that shadows are only being cast on verticaly or horizontaly dont realy need higher lightmapscale, only the ones with diagonal shadows if u want to optimize performance.
@cis, interesting post about lightmapscale.
and to my understanding -samplesize doesnt make shadows larger or smaller, but instead more blurred or sharper edged... the smaller the value, the more samples taken, so less blurring ...unless Im wrong it works the same as q3map_lightmapsamplesize
what I`m not clear on is the difference if any between these two and _lightmapscale?
I’m not sure if more than one lightmap can be mapped to a surface, but from my experience, on normal size brushes (of 128 squared to 256 or so), you can achieve sharper shadows with a small lightmap scale (1/16th - 0.0625), so whether that’s just using every pixel to it’s best or actually making more lightmaps I don’t really know.
But thanks for the samples explanation, that seems to make more sense now. I think that samplesize and the edge antialiasing methods are tied together. Since -samples x is an adaptive algorithem, I think samplesize controls the recursion limit.
So, for -samples 3, it would be a 3x3 filter array, with each element sampled n times for samplesize (defaulting to 16)? But wait that doesn’t make much sense, since smaller samplesizes make it more accurate apparently. Maybe that’s the subpixel size? Arg, I think I’m totally off now.
I wouldn`t think that more than one lightmap can be mapped to a surface?
but I agree these filter arrays are probably similar to the gaussian blurs in photoshop and paint shop pro, ie larger arrays blur the results more.
anyway hopefully ydnar can clarify all this.
… just a copy from the manual
samplesize (n)
This sets the lightmap pixel size to (nxn) units. The default is 16. (16x16). The -samplesize argument allows the mapper to set a map wide samplesize value in the -light phase that overrides the default 16 value. It is overridden by surfaces with explicit lightmap sample sizes. (q3map_lightmapsamplesize)
yes, but why would we also need _lightmapscale? …or is this so we can have a compile switch, brush key value and shader command?
_lightmapscale, _lighmapsamplesize, samplesize, -samples (bsp phase), -samples (light phase) i think i’m getting a headache 
_lightmapscale is how a surface translates into the lightmap (sizewise)
now someone do the rest plz
I’ve just finished doing some experiments using external lightmaps on a test map. The map has a light projecting the shadow of some caulked “text” so I can easily pick it out exactly the surface I’m looking for.
Results are that _lightmapscale produces more lightmaps when you use smaller scales.
So at the default of 1.0, the 6 or more surfaces in a box room will fit on one lightmap. In fact, they’ll fit in the corner of that lightmap (very small, doesn’t use up the 128x128 map).
At small scales, a surface can have a whole 128x128 lightmap to itself. So if it can, dependent on the scale parameter, the compiler will try to fit as many surfaces as it can into one lightmap.
At a scale of 1.0000, it was mapping 512 world units into 32 pixels (part of a lightmap sharing many surfaces).
At a scale of 0.0625, it was mapping 512 world units into 112 pixels (of a lightmap for that surface only).
Ok, so I think I’ve figured that out. Now onto samplesize, I’m thinking that only has to do with the shadow edges, but I could be wrong. I also think it has nothing to do with q3map_lightmapsamplesize.
Update: After more testing including the samplesize parameter and using either the supersampling or adaptive algorithem on a small lightmapscale, I’ve come to the following conclusion:
-samplesize does precisely ziltch in vanilla Q3.
That might be because you are trying to run -light -samplesize. That won’t do anything, because -samplesize is a bsp phase switch. Trust me, -samplesize does lots–more noticeable results than _lightmapscale, even–try compiling a test map with no _lightmapscale values set on anything with just -meta -samplesize 4 -v in the bsp phase, -light -fast in light. You’ll see what -samplesize does. When you combine -samplesize with judicious use of _lightmapscale and -samples 3 for shadow edges, you’ll see how good Q3Map2 can look.
Ok, so I was looking through light.c yesterday and taking note of all the switches. -samplesize is in there for light also, but it’s a bsp switch too? Ok I’ll try that.
Thanks rgoer, that’s what I was looking for.
would -samplesize 4 make sense for a final compile or is it overkill like _lightmapscale in worlspawn?
Q3Map2 -light reads the samplesize value from the .srf surface extra file. This file is written during the bsp phase, hence -samplesize being a bsp phase switch. You can also edit the .srf file by hand and change the samplesize value that way, but it’s easiest to just use it properly as a bsp phase switch. And cis: 4 isn’t quite overkill, but it’s pretty much the reasonable limit. 3 or 2 would look incredible, but bsp filesize starts getting retardedly bloated. There probably aren’t words to describe how awesome a samplesize of 1 would look, but neither is there an accurate measurement for how long it would take to compile (and how ridiculously large the resulting bsp would be).
this sounds like something worth experimenting with. no more chopping up of surfaces to get higher res shadows
thanks a lot 
btw, is this something different from q3map_lightmapsamplesize? i played around with it but i couldnt see any difference of the shadow. or did i just mess it up somehow?
You’ll probably still want to chop up surfaces… although you won’t need to chop them up into such small parts with a lower samplesize value.