Lightmap Resolution problem

(VolumetricSteve) #1

I’ve been using q3map2 on and off since about 2005 and now that I’ve gotten back into mapping, I’m starting to notice that some brushes are simply too large to case detailed lightmaps onto. Knowing this, I went into my map and used the cutting tool to divide my one giant brush into about 200 smaller brushes, but no matter how many brushes I use for that surface, the lightmap looks low-detail and jaggy.

my compile options are so:

[q3map2] -meta -samplesize 3"[MapFile]"
[q3map2] -vis -saveprt “[MapFile]”
[q3map2] -light -fast -super 2 -filter -bounce 8 -samplesize 3 -samples 4 “[MapFile]”

the weird part is, my floor is made up of a grid of 64x64 tiles, so I’m guessing because they’re small, they seem to catch sufficiently detailed lightmaps, so I know q3map2 is trying to make good lightmaps, but no matter how small I make the brushes for my walls, the walls still appear to be processing as one huge brush, and therefore get a low-detail lightmap in a very visually obvious place. What’s causing this? how can I fix it?

Thanks

(obsidian) #2

Most id Tech 3 games are limited to 128x128 lightmap pages, IIRC ET uses slightly larger ones at 256x256. Regardless, you may have to play around with external lightmaps. Keep in mind that outrageously large lightmaps will take up more video memory and may not as efficiently make use of the page real estate. Try smaller values before jumping up to the next power of 2.

(VolumetricSteve) #3

Thanks for the speedy reply and great pointers, that link explained a lot (albeit in somewhat broken english) but I have a few questions:

what is ‘page real estate’ and what did you mean by “Try smaller values before jumping up to the next power of 2.”? which value should I change by smaller increments?

and just to clarify…

if i’m understanding that article, what I need to do is edit the texture info so that the concrete floor texture i’m using tells q3map2 to get 1024x1024 lightmaps…and then every surface in my map that uses “concrete floor” will then take a 1024x1024 lightmap?

thanks again

(obsidian) #4

If you think about a player or weapon model skin, it’s taking the 3D shape of the model and flattening it out onto a 2D surface of the texture. Lightmaps are the same, it is the 3D shape of your map broken up into pieces and flattened onto a lightmap page.

The dimensions of each lightmap page, like any other texture, needs to be in dimensions in powers of 2, so 128, 256, 512, and 1024 pixels are all powers of 2 numbers. So the default size is 128x128. You may want to carefully bump that up to 256x256 and if that really doesn’t do, 512x512, etc.

If using really large lightmap pages, like 1024 or above, sometimes once your map is unfolded onto the page, you might end up with a bunch of empty blank space. This extra blank stuff is still loaded into texture memory, so that comes with a performance cost with no benefit to appearance. Just be aware of that and try to uses the smallest lightmap page size as possible to get the job done, bigger does not always mean better.

Instructing Q3Map2 to use larger lightmap pages means Q3Map2 will have a larger surface to project the lightmap on to, giving it more pixels to work with on a single page. It does not mean that the floor will necessarily span the entire 1024x1024 area nor does it mean if it needs more than 1024, it won’t downsize the surface to fit.

Take all this with a massive block of salt, as I see 90% of people who scale lightmaps to higher resolutions in the first place don’t necessarily need to do so. If you need more shadow details, you are generally better bumping up the resolution of that surface locally using a func_group and entity keys rather than scaling up all lightmaps globally at compile or per-surface using a shader. Lots of people also try to increase lightmap resolutions because they think it will get rid of jagged aliasing shadow edges. It does not, it just creates higher resolution jagged shadows, filtering will do a lot more in this case. In general, scaling lightmap resolutions or larger lightmap pages should be used sparingly and only when other solutions don’t work.

(VolumetricSteve) #5

That post was so beautiful I want to mount it on a wall and have it framed.

Your point about filtering vs. lightmap sizes is precisely what I needed to hear. My hope with higher res lightmaps was to take the jaggies out of a long-distance shadow being cast onto a gigantic surface. It bothered me because the shadows casting on the floor look so much clearer, then as the same shadow casts onto an adjacent wall, the jaggies in the lightmap went from the size of legos to the size of small cars.

I’ve used the -filter switch, which helps a LOT, but is there a way to make it filter…better? I’ve messed around with -samplesize (setting it as high as 64 for giggles) but I don’t get the impression it really helps much. If I could avoid going to the trouble of increasing the lightmap size, I’d be happy to just employ better filtering, at least for now; I can’t think of an instance in my current map where I’d really need a more detailed shadow rather than a smoother one.

Thanks again.

(obsidian) #6

Filtering can be applied in a variety of ways. Globally with -filter, or on sky shaders (see appendix section in Q3Map2 shader manual), entity keys on light entities. That should give you a variety of options and localized control.