Lightmap luxel density & sampling questions

[KillPixel]

I'm trying to create aliased lightmaps with a luxel density that matches the texel density. So far I've only been able to visually match densities but cant seem to remove the blur.

The texel density is 2 (4?) per game unit (so, a texture scale of 2 in radiant). I'm using external lightmaps.

I would much appreciate it if anyone could shed some light on this

[KittenIgnition]

Are you talking about blur in game, or the lightmap itself? If you have multiple light sources then they will blend shadows together (umbra and penumbra), but if you compile with simply -fast -export (no samples or filter or super), it will be displayed exactly as-is in the texture file. In game, there is a filter in place that blurs everything. Its not possible to render textures perfectly 1:1.

[KillPixel]

I'm talking about in game. The lightmaps themselves don't have blur and are totally sharp/pixelated/aliased whatever. I'm not quite sure where the blur in game is coming from.

Its not possible to render textures perfectly 1:1

That's a bummer :/ I was getting pretty good results using _lightmapscale and external maps, aside from the blur.

I appreciate the info, thanks.

[obsidian]

In addition:

Max lightmap page size = 1024^2 (default is 128)
Default texture resolution = 2 texels/1 game unit
Default luxel resolution = 1 luxel/16 game units

Lightmap pages, unlike textures, do not tile. Each luxel is unique on every visible surface. What this means is that if using max lightmap page size, and at same texel density, your maximum surface size can be only 512 units. Any larger and the lightmap page will be stretched to accommodate the surface.



General suggestions:

High resolution lightmaps might sound really cool, but in practice it's extremely hard to notice the effect, and you'll run into a bunch of limitations which usually means the lightmap will be downsampled to fit geometry, run out of memory, or other issues. Instead, I would rather opt for better quality lightmaps using a combination of entity keys, shader directives, and compile settings.

[KillPixel]

Thanks for the additional info, obsidian.

High resolution lightmaps might sound really cool, but in practice it's extremely hard to notice the effect, and you'll run into a bunch of limitations which usually means the lightmap will be downsampled to fit geometry, run out of memory, or other issues. Instead, I would rather opt for better quality lightmaps using a combination of entity keys, shader directives, and compile settings.

This has been my mode of thinking, but put it aside to try this out (which I really wish was viable).

I should have a noted that this is not for quake3, just a project using darkplaces. I wanted to produce "retro" looking shadows, i.e. low pixel density and no anti-aliasing. the current setup is this:

.5 texels / 1 game unit (player char is 128 game units / 64 texels tall).

AFAIK, DP supports lightmap pages of 4096 and possibly greater. However, maps are BIG, and my experiments produced a ton of lightmap data, which is nothing for modern hardware, but I'd like to be able to run this on a calculator.

One could draw the shadows on the actual texture, but that's totally ridiculous and impractical. I suppose I'll have to ditch the hard shadows idea.

[KittenIgnition]

If you want to see your texture in-game as unfiltered pixels, set r_textureMode to "GL_NEAREST_MIPMAP_LINEAR". As I said, this isn't perfect 1:1 drawing, but it's as close as you're going to get.

I use really high-resolution lightmaps all the time, and it definitely does have a lot of drawbacks and issues, the most frustrating of which is compile time. It takes a lot of testing to get things working mostly OK, but when it does, it can look pretty spectacular.

P.S. Some engines can handle 2048^2 textures, so I use those most of the time, not 1024^2.

[Hipshot]

just gl_nearest will give you a "pixel perfect renderer"

I've been using this to prototype game assets for a lowpoly pixelated environment in 3d.

[KillPixel]

KittenIgnition, I use gl_nearest, but it seems to have no effect on the lightmap. I've observed this in both Darkplaces and FTE. A shot to demonstrate: http://www.killpixel.com/clean/kp1_filtering.jpg

In this shot no filtering switches of any sort are used during the light phase. The _lightmapscale is set to .5 in worldspawn (would need to use .125 for a 1:1 luxel/texel density). Currently using 1024^2 lightmaps, but will likely end up using 4096 as I think DP ends up merging lightmap pages anyway.

I noticed in your shots they all seem to use trilinear filtering save for 2 and 3 from the bottom. In those pics the lightmap is clearly aliased, which is what I'm trying to achieve. Strange that I can't replicate that on my end. Nice shots, BTW.

[KittenIgnition]

Correct, gl_nearest does not affect the standard lightmap (when using map $lightmap in the shaders), but when using external lightmaps the shader created uses simple texture mapping using lightmaps coords - the engine doesn't see this shader step as an actual lightmap due to it not using $lightmap.

I dunno if you're confused about aliasing, or if I am. I used a hell of a lot of samples (-super 5 or 3 iirc), and some other effects on the lightmaps. There is very little aliasing, if at all. I think I made a mistake for some of those shots and didn't use gl_nearest, but some of the more close-up ones make it pretty obvious.