TTimo / GtkRadiant

The open source, cross platform level editor for idtech games
http://icculus.org/gtkradiant/
Other
587 stars 157 forks source link

Q3map2 external lightmaps coordinates inaccuracy #66

Open Garux opened 12 years ago

Garux commented 12 years ago

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.

TTimo commented 12 years ago

(for reference) http://sgq3-mapping.blogspot.de/2009/01/using-hi-resolution-external-lightmap.html

0bsidian commented 11 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.

External Lightmaps are mipmapped

Possible solutions:

Shader for external lightmap surface:

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.

Garux commented 11 years ago

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.

Garux commented 11 years ago

Using nearest pixel is even more badass thing:

shot0131 shot0132 shot0133 shot0134 shot0135 shot0136

Meanwhile using external lightmaps is a good optimization for big maps

ailmanki commented 11 years ago

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.

Garux commented 11 years ago

i gave it a try with q3 engine shot0150 shot0151 shot0152 shot0153

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

ailmanki commented 11 years ago

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... :/

Garux commented 9 years ago

Making outline could fix usual internal lightmaps too Neighbor lightmap intrudes pretty often in case of non-axial brushes shot0414 and even axial ones shot0415 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: lm_0000

SomaZ commented 7 months ago

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