Uniform lightmap scale on all brushes?

[g0th-]

As the topic says, I'm having troubles setting my lightmaps up to be uniform on all brushes. I'm using the normal map command inside of q3map2 so the lightmaps needs to be quite high res as well. Any tips on how I can archive this would be greatly appreciated.

Thanks.

[Hipshot]

_lightmapscale in worldspawn.

[g0th-]

I tried to put _lightmapscale to both 1 and 2 but the problem still exists.

Here I uploaded a picture of how it looks

[Hipshot]

Put it at .25 (or whatever) - 1 is def and 2 is twice as bad.

Is both sides the same value now? Odd that the difference is so big, is there a light source that is more "direct on" on the blured one?

[g0th-]

Yes the blurred one gets hit by sunlight, but I don't think the sunlight is the problem here. I put the lightmapscale to .25 and it still didn't work.

Here's another picture with a better overview of how it looks. The different colors means that the same material is applied to the surface. The only thing I can get out od this picture is that is seems to be very dependent on where the brush is on the grid. As you can see on the shot all faces that are on the same grid line get a lot of blurriness. I've marked the faces with L for blurry and m for detail, just to clearify

[Hipshot]

Yea, seems like it. I have had so much trouble getting this to look good, consistent over a whole level, so I just decided that I probably would never use it. It feels inconsistent using it on some places and if one can't make it look good everywhere, then - nix it.

[g0th-]

Yeah I can see what you mean

But i can't help to wonder if this is not related to the way q3map2 makes the lightmaps with or without the normal maps, only difference is that is a lot easier to spot where the lightmaps gets a lower resolution when you're using normal maps. But I might be completely wrong about that one

It would be a real shame if there wasn't a way to make this work decently.

Thanks for you help so far Hipshot

[ix-ir]

There are two approaches as far as I'm aware to this issue. The problem you're encountering is that Quake 3 lightmaps are made of 128 by 128 textures, all stitched together. As I understand it a single brush face can only be on one lightmap texture, not spread across multiple textures, this means that sometimes you will get the light map resolution you want with _lightmapscale and sometimes it will be much lower resolution to fit the brush on the light texture.

The two approaches are:
Write a shader for every texture you use adding the command tesssize 128 (or whatever value works for you). This will cut the world geometry into 128 by 128 squares with surprisingly little impact on performance, potentially for modern cards it will help performance. This ensures brushes will receive high resolution lightmaps. Dangers of this approach are that it will create a large bsp file and you may exceed the max lightmaps limit in which case you would need to increase the tesssize.

The second, and probably easier approach is to use q3map2's external lightmap compile command to make larger lightmap textures which are not built into the bsp. These are then applied to the level textures with shaders. A write up of how to do so:
http://sgq3-mapping.blogspot.com/2009/0 ... htmap.html

[g0th-]

Thanks ix-ir.
This looks really promising.

[obsidian]

Nice link, ix-ir. External lightmaps are the way to go.

Oddly enough, I didn't see it mentioned in the tutorial that was linked, but the actual Q3Map2 switch for external lightmaps is -export.

Oh, it's also a good idea to use local lightmap scaling (in shaders or func_group) on certain hidden or distant parts of the map where high resolution lightmaps are not necessary and scale them back up to default or even larger. You can overwrite previously set values in the order of: global (switch), surface (shader), entity (func_group). So a func_group lightmap scale value will always overwrite the shader and switch values.

[Plan B]

I've only experimented with bump maps in Q3A once, just because it was a novelty then, and I liked to see if it worked.
It did, but with pretty disappointing results.

But to be honest, I'm more interested in getting higher quality shadows from geometry than normal maps.
Either way, thread delivers.
Nice!

[g0th-]

Ok so I tried the external lightmap approach and it works pretty good from what I can tell (looking at the lightmaps in photoshop). The problem is that I cannot seem to get the lightmap to affect my diffuse correctly. It's all to dark ingame and while I can see shadows it's to dark from the rest of the map. I've tried to put the lightmap brightness up without any effect.

This is my current shader setup for the lightmap

textures/g0th_map01/stone_floor_02
{
q3map_lightmapSize 1024 1024
q3map_lightmapBrightness 2.0
qer_editorimage textures/g0th_map01/stone_floor_02.tga
q3map_normalimage textures/g0th_map01/stone_floor_02_normal.tga
{
tcgen lightmap
map $lightmap
rgbGen identity
}
{
map textures/g0th_map01/stone_floor_02.tga
blendFunc GL_DST_COLOR GL_ZERO
}
}

I've tried to put the blendfunc to filter as well but it still looks dark. Any ideas?

[Hipshot]

textures/g0th_map01/stone_floor_02
{
q3map_lightmapSize 1024 1024
q3map_lightmapBrightness 2.0
qer_editorimage textures/g0th_map01/stone_floor_02.tga
q3map_normalimage textures/g0th_map01/stone_floor_02_normal.tga
{
tcgen lightmap
map $lightmap
rgbGen identity
}
{
map textures/g0th_map01/stone_floor_02.tga
blendFunc GL_DST_COLOR GL_ZERO
}
}

Try?

Code: Select all

textures/g0th_map01/stone_floor_02
{
	qer_editorimage textures/g0th_map01/stone_floor_02.tga
	q3map_normalimage textures/g0th_map01/stone_floor_02_normal.tga
	q3map_lightmapSize 1024 1024
	q3map_lightmapBrightness 2
	{
		map textures/g0th_map01/stone_floor_02.tga
		rgbGen identity
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

[g0th-]

That worked but it messed up the mapping on the lightmap, apparently I need to have the tcgen lightmap cmd in there for it to be mapped correctly. And it is when I put that cmd the brightness gets wrong.


Edit: Oh It worked when I remove the brightness cmd and run the game in fullscreen
Just in case anyone else want to know here's the shader that works

textures/g0th_map01/stone_floor_02
{
qer_editorimage textures/g0th_map01/stone_floor_02.tga
q3map_normalimage textures/g0th_map01/stone_floor_02_normal.tga
q3map_lightmapSize 1024 1024
{
map textures/g0th_map01/stone_floor_02.tga
rgbGen identity
}
{
tcgen lightmap
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
}
}

[Hipshot]

Always test colors and light in fullscreen (overbrightbits 1), which I'm pretty sure is the option most people are running in. There's no way to enable (anyone??) overbrightbits when in win mode, which is sad. If you are using "identitylighting", then it's the same as overbrightbits 0 (and/or as in winmode), the lightmapstage as default is only "identity".

[g0th-]

Yeah I've done the fullscreen mistake with q3 a numerous times over the years now It's very annoying sense all programs and stuff switches position when you got 2 monitors and running a fullscreen game.

ohh and you got to love the "WARNING: No BSP lightmap data" comment the compiler gives

[Shallow]

Write a shader for every texture you use adding the command tesssize 128 (or whatever value works for you). This will cut the world geometry into 128 by 128 squares with surprisingly little impact on performance, potentially for modern cards it will help performance. This ensures brushes will receive high resolution lightmaps. Dangers of this approach are that it will create a large bsp file and you may exceed the max lightmaps limit in which case you would need to increase the tesssize.

I'm curious to know whether you've tested this or if it's just an assumption, as it sounds fishy to me. Although my suspicion is equally based on assumptions

As I understand it, tesselating surfaces with tesssize does not create a mass of discrete triangles - that would have caused plentiful performance issues in all the stock Q3 maps that used it on water surfaces. The compiler will divide the surfaces every so many units, like you tell it, but it will then selectively weld many of the verts on adjacent triangles back together to create nice big drawsurfs. You still get all the triangles you asked for, but joined up. So what you'll probably get is drawsurfs that have roughly or exactly the same kind of size and layout as the ones you would have got without tesselation, but just with more triangles in the same area.

Now, those bigger drawsurfs are what gets looked at for lightmap allocation. As it's likely that you have drawsurfs that are of similar size to what you had without tessize, the lightmap UVs are going to get squashed in just as much to fit them onto the lightmap pages.

Like I say though, it's all assumptions. I've done bugger all mapping in ages now so you can just ignore me as a cranky old bastard if you like.

[g0th-]

I tried the tessize command as well. And it couldn't make it work good. Perhaps it possible to split the brushes up manually with the clip tool and the alter the texture mapping just 0.00001 or something so the brushes won't merge. At lest that's how you prevented q4 to merge it's brushes. A lot of job though

[obsidian]

These might help, though I don't recommend using the tessSize method to achieve higher resolution lightmaps, a bit like taking a sledgehammer to a broken pocket watch.

http://www.robotrenegade.com/q3map2/doc ... ml#notjunc
http://www.robotrenegade.com/q3map2/doc ... tml#noclip

[rgoer]

isn't there some worldspawn entity key you can set that will set the grid size, and isn't there some bsp setting you can use that will force the drawsurfs to split on grid divisions?

[obsidian]

Hey, nobody asked you!

[T_Creutzenberg]

I don't know if it already was said before, but if you set _lightmapscale in the worldspawn,
everything will have this lightmapscale EXCEPT func_groups. I.e. you have to maually set
the lightmapscale for every func_group, too. You can also set different lightmapscales for
different func_groups.

[ix-ir]

Grid size is a very different kettle of fish cutting the bsp for vis purposes (_blocksize which is best set to 0 0 0 and manual cuts made to giant leafs), I vaguely remember the switch you're talking about which makes the hints(?) also cut geometry as they did for Quake 2. This really would be an example of cracking a nut with a hammer as the vis tree would take forever to compile and be very slow for the kind of 128 cubes or so we're talking about.

Tesssize is a more complex method for the light maps issue, I'm using it ATM for other unrelated reasons as well. Performance-wise I think you'd be surprised, perhaps you're thinking too much in raw vert and tris terms which are no longer that relevant to modern cards.

Shallow perhaps there's a way to make it weld things back afterwards, it does what you'd imagine by default, cutting the world into regular sized squares and cubes. It is something I'd tested as I'd hit the same issue as goth- and tried this before finding out about external maps for Quake 3, I knew about ET's use of them but it didn't occur to me that you could write shaders to get them into Q3. You make a distinction between tris and drawsurfs, perhaps I'm missing some technical point here, Radiant and Quake 3 seem to treat what you see in my image as what it cuts up the lightmap for as if they were distinct brushes, if you decompile of course you see that they're not.