Open Garux opened 12 years ago
This issue seems to be caused by external lightmaps being mipmapped like a normal texture (I believe internal lightmaps are not mipmapped or the engine has some other way of dealing with them). The dark edges appearing on the edges of a lightmap seam are caused by the edge luxels sampling adjacent luxels and mipmapping the result.
textures/luxel/lux1024
{
q3map_lightmapSize 1024 1024
q3map_lightmapMergable
q3map_lightmapSampleSize 1
q3map_lightmapBrightness 2.0
qer_editorImage textures/luxel/lux1024.tga
{
map textures/luxel/concrete.tga
rgbGen identity
}
{
map $lightmap
tcGen lightmap
blendFunc GL_DST_COLOR GL_SRC_COLOR
rgbGen identityLighting
}
}
Hoping for some kind of fix for this, I'm also working on a map that uses external lightmaps significantly.
Still interested why external 128x128 are cool (used lightstyles trick to get these ones).
I guess one quick and rough workaround can work - scaling lightmaps a bit to move problem area out of view.
Using nearest pixel is even more badass thing:
Meanwhile using external lightmaps is a good optimization for big maps
I have made a short experiment with clampmap... since it seems to fix similar issues. And in my test it worked on Enemy-Territory. The visible seam is gone. Though I could not adjust the brightness of the external lightmap correctly, but that is a different issue I think. That gives as lightmap stage this: { clampMap $lightmap tcGen lightmap blendFunc GL_DST_COLOR GL_SRC_COLOR rgbGen identityLighting }
I am very curious if this does indeed work as I think, as its a little special I think.
i gave it a try with q3 engine
rainbow artifacts are caused by strong jpeg compression level of lightmaps images, so can be avoided easily nomipmaps shader produces 'sandy' view, fortunately it fits the map from shots well :d
Then I suppose clampmap will not work if your lightmap covers multiple areas. Maybe works only when there is exactly one on it, filling it out... :/
Making outline could fix usual internal lightmaps too Neighbor lightmap intrudes pretty often in case of non-axial brushes and even axial ones It's actual pain to fix those
Existing -fill code can be used. Corner pixels might be ignored; single pixel artifact isn't a problem, comparing to current state. The case of non-rectangular lightmaps seems questionable:
Necro time. I implemented a workaround for the issue in python.
Main idea is: once an image is loaded in most id tech 3 engines, it will be reused. Even so if the image flags aren't the same. Images are loaded when surfaces are parsed. Surfaces are parsed in order of occurence in the surface lump. Nomip flag is used for all images of a shader, not just a stage.
So my workaround adds new surfaces to the head of the surface lump. Then, every surface index in the bsp is incremented by the number of added surfaces. For every 8 external lightmaps a new shader is added to the shader lump. The added surfaces obviously use the new shaders. The new shaders are added to the generated q3map2_map_name.shader. These are basically dummy shaders. Nomip shader attribute with up to 8 stages. Every stage is just one external lightmap.
Code of my python implementation: https://github.com/SomaZ/id-tech-3-BSP-tools/blob/main/force_ext_lm_nomip.py
128x128 internal and external ones are ok, any higher lightmap resolution causes including unwanted pixels. On the map it looks like dark lines on edges of lightmaps. I figured that out after painting black areas of lightmaps with different colors on test map: http://rghost.ru/38372170
Somehow this effect hides in close area with r_picmip 0.
Actually i was trying to get bumpmapped lighmaps for large surfaces with not reduced resolution, so had to cut brushes to pieces with less 2048 units length.