lightmaps going wrong...

(fraco) #1

Hi,

I got a case of lightmap going fubar… Lemme first show the problem:
(all pics are taken with r_lightmap 1)

[edit] sorry if some pictures are too dark.

I hope you see how the same bit of lightmap gets repeated over and over.

That “band” is funky. It is as if there is vertex lighting there. You see it again in the next shot.

Notice how the treelines make big bulky shadows? The problems started to be visible when I added those.

Part of that same lightmapped terrain does look perfectly ok:

The game is SOF2.
The problem started showing when I added those treelines. They are tga with an alpha channel on brushes with _nodraw. Here’s the shader

textures/nuclear/treeline3_vl
{
	cull disable
	qer_trans 0.8
	q3map_alphashadows
	q3map_nolightmap
        qer_editorimage	textures/nuclear/treeline3
	{
		map textures/nuclear/treeline3.tga
		blendfunc gl_src_alpha gl_zero
		rgbGen vertex
		alphaFunc GE128
	}

}

Things I might have messed up:

  • I have been vertex pulling that terrain (I assume for now that that is the root of my trouble)
  • It seems I have been overusing _lightmapscale a bit (still have to tweak it down a bit). However if I use a bit more detail on that terrain (lower _lightmapscale), sof2 will crash on the map. I assume it’s telling me I have too much lightmaps? Maybe this being close to the limit causes this?
  • Those treelines seem to have triggered the problem.
  • A lot of my brushes overlap (intersect) with that terrain.
  • the terrain has been clipped around my buildings and structures (and i think that clipping with vertex pulling might not have been a good idea, coz some of the terrain triangles got chopped to a quad now)

any advice is welcome. If noone can help, well, I’ll try rebuilding that terrain from scratch. Unfortunately that would (with all the clipping and vertex pulling) be a very tedious job.

thnx in advance

fraco

(ydnar) #2

Can you post your terrain shader?

(fraco) #3 
// *************************************************

// *   KAM4 Metashader - lightmapped

// *************************************************

textures/nuclear/baseterrain
{

	q3map_lightmapsampleoffset 8.0
	q3map_lightmapaxis z
	q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )
   	q3map_nonplanar 
   	q3map_shadeAngle 75 
}

textures/nuclear/terrain_0
{
	q3map_baseshader textures/nuclear/baseterrain
	q3map_material	Snow
	q3map_lightimage textures/kamchatka/snow_1 
    {
        map textures/kamchatka/snow_1
	rgbGen identity
    }
    {
	map $lightmap
	blendFunc GL_DST_COLOR GL_ZERO
	tcGen lightmap
	rgbGen identity
    }

}

textures/nuclear/terrain_1
{
	q3map_baseshader textures/nuclear/baseterrain
	q3map_material	Snow
	q3map_lightimage textures/kamchatka/snow_1 
    {
        map textures/kamchatka/rock_huge_snow
	rgbGen identity
    }
    {
	map $lightmap
	blendFunc GL_DST_COLOR GL_ZERO
	tcGen lightmap
	rgbGen identity
    }
}


textures/nuclear/terrain_0to1
{
	q3map_baseshader textures/nuclear/baseterrain
	q3map_material	Snow
	q3map_lightimage textures/kamchatka/snow_1 
    {
        map textures/kamchatka/snow_1
        rgbGen identity
    }
    {
        map textures/kamchatka/rock_huge_snow
        blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
        rgbGen identity
        alphaGen vertex
    }
    {
	map $lightmap
	blendFunc GL_DST_COLOR GL_ZERO
	tcGen lightmap
	rgbGen identity
    }
}

it’s a stock SOF2 shader adapted for lightmapping…

fraco

(ydnar) #4

OK, make a backup of your map and other files (alphamap, shader scripts, etc).

  • Try using an alphamap that’s entirely one solid color, say the snow one. I’ve heard of problems with SOF2/JK2 and lightmapped terrain blend shaders.

  • If your map has any styled lights that might touch the terrain, remove them or make them non-styled. This includes lights with a “targetname” key, a “style” key, or light shaders with q3map_lightstyle.

  • I belive SOF2 is limited internally to 1024 unique shaders. This is a hard limit because of sorting bits. Lots of lightmapped shaders (i.e. texture * lightmap combinations) can cause this limit to be breached. Try scaling back your lightmap count/detail.

  • Make sure all the shaders used in your map are listed in shaderlist.txt.

y

(fraco) #5

That does get rid of the funny white banding in the lightmap. Incidentally, those bands seem to be exactly on the blend of the snow to the rocks.

I have no styled lights.

I have heavily scaled up on the lightmapscale (i should have cut my number of lightmaps at least in half, prolly in eight). It doesn’t change much. The banding stays and the messed up lightmap too.

I’m pretty sure they are. Wouldn’t q3map2 give me a warning if they arent?

thnx for the advice. Help is still welcome. In the meanwhile, I’m gonna rebuild that terrain and any brushes I might have last week…

thnx for the help

fraco

(fraco) #6

just following up on this.

  • replacing the entire terrain with a brand new one, didn’t help against the repeating of the lightmap.
  • the ugly shadows from the row of trees is because i misspelled q3map_alphashadow in the treeline shader.

I will simply replace the _terrain with the a simple snow shader.

fraco

(fraco) #7

Damn, replacing the terrain with a simple shader didn’t help.
I still have weird repeating parts in my lightmaps.

all shots with r_lightmap 1 in sof2, tweaked the brightness and contrast in photoshop for all pics.

Following piccies show that the artefact from the previous shots has changed:

Funny enough, it’s not really that part of the lightmap is repeated. The shot below does show the shadows that should be (shadow of a fence with grating), but the artefact is blended with the right lightmap.

Strange also is that if I enable the -debug flag for light, the artefact almost goes away:

although if you look closely you can see that the lightmap still is a bit messed up.

like this out of place piece of triangle

I think that q3map2 got too much intelligence built in and now gets bored with lighting my map on my slow-ass pc. Out of boredom it plays tricks with my lightmaps :slight_smile:

fraco

(ydnar) #8

What’s the snow shader now?

BTW, using high-res lightmaps like that all over a map isn’t a good idea…it can really kill rendering performance.

y

Edit:
I’m not sure if SOF2 has this, but try disabling lighmap compression. The cvar is r_extCompressLightmaps I believe. Set it to 0 and vid_restart.

  • Try a compile with -nocollapse. Sometimes the lightmap collapsing leads to small artifacts on lightmaps without much detail.

  • Try compiling with -samples 2 or -super 2 or -filter or something. I’m not exactly sure what you’re referring to as an error, but if it’s the jaggies, those can be solved with oversampling or filtering.

  • Sometimes superior results for alphashadows can be done by making a new image for q3map_lightImage for each shader with a blurrier alpha channel.

(fraco) #9

Don’t have the snow shader at hand here. I can only tell that it is lightmapped (you wouldn’t have guessed :slight_smile: ) and that it has q3map_shadeangle (120 i believe from memory). I’ll post it later, when I am back from work. It shouldn’t be that different from terrain_0 (few posts higher, but lemme check that out)

As to the lightmap detail all over the map. Yes, that is still to be subject of tweaking. I was planning on having 0.125 for the lightmapscale on the nearby parts of the terrain, maybe have a unscaled layer beyond that and have lightmapscale 4 at the far (unreachable) edges of the terrain.

fraco

(fraco) #10 
textures/nuclear/snow_1
{
	q3map_material	Snow
	qer_editorimage textures/kamchatka/snow_1
	q3map_alphashadow
    {
        map $lightmap
    }
    {
        map textures/kamchatka/snow_1
        blendFunc GL_DST_COLOR GL_ZERO
    }
}

i just noticed i don’t even have a shadeangle… strange, seems i mixed up shadeangle and alphashadows…

guess that shouldn’t matter

fraco

(ydnar) #11

Add the following lines to the shader:

q3map_nonplanar
q3map_shadeangle 120

Otherwise every triangle is a separate surface, which is quite inefficient.

y

(fraco) #12

i just did, i know i had those shader keywords with the terrain i originally started this post with. Putting them in again didn’t fix the problem, but made the problem snap back to the original look of it. The artifact has changed and now shows the same pattern again.

However, i think i tracked the source down. That artefact looks exactly like the lightmap that should have been projected on a piece of patch that is part of that func_group (with the lightmapscale overkill) grouping most of the terrain (with the snow shader).

I think the source of all evil is the patches. Not 100% sure, have to check the bible first, and recompile without those batches - err pitches. Sorry, bit tired :slight_smile:

See the treetops in the form of the artefact with the weird lighting behind it. That darkness is exactly where that piece of patch is.

other shot where the darkness is more clear.

I’m convinced that the lighting on those treetops should have given a lightmap like the one seen repeated all over my map.

I’m gonna experiment and hang a red light there.

fraco

[/img]

(fraco) #13

[edit] double post

(fraco) #14

forget that last hunch. it wasn’t that. lit that area up in red light. No change to the anomaly. - geez, i should have been part of the star trek cast.

going to bed. More detective stuff tomorrow

nn

fraco

(fraco) #15

pfew if figured it out.

yes - the fault was on my side (why did i have to start that other thread on a bug in q3map2 - sigh)

that terrain was split up in 2 func_groups:

  • one with _lightmapscale 0.25
  • one with _lightmapscale 4 (the outer rim of the map, as i didnt care for lightmap detail there)

apparently, _lightmapscale 4 was the culprit. removing that lightmapscale removed the bug completely.

so - yet again - my mistake.

thnx for all the help Ydnar (at least I got an opportunity to learn more)

fraco

(fraco) #16

:banghead: :banghead:

still messed up. I changed to 3 pieces of terrain (with the above snow shader + Ydnars suggestions) with _lightmapscale resp 0.25, 0.5 and none. Problem is back to haunt me. I’m gonna just shuffle with those lightmapscales until i find some acceptable combination where i find no more defects and leave it to that.

greetz

fraco

(fraco) #17

hmpf.

I added a big red light above that area where there are these defects, and it seems the simple act of lighting up this area makes the defects go away.

just wondering when q3map2 says:

collapsing…

and then

1023 identical surface lightmaps, using 24905 luxels

at the end of light… what does that mean?

it seems to suggest that identical or similar lightmaps get reused. Could this explain why drastically changing the light could make q3map2 not do this at that point?

I do realize that I am making a wild guess here, but I find it strange that adding one light makes this defect go away. It probably has some other cause, but well, if i can mask it by adding some light…

fraco

(ydnar) #18

Did you try using -nocollapse like I suggested?

That switch disables, oddly enough, lightmap collapsing.

Or did that post get lost amongst the giant screenshots? :wink:

y

(fraco) #19

:eek: :eek:

I seem to have been able to hide that winning suggestion in between my huge screenshots idd. :banghead:
Do however notice that i posted at the exact time you added that in the edit.

I read your post with -nocollapse while at the same time I was already running a compile with -nocollapse (yes, had just figured that out by myself :smiley: ).

And yes idd that did fix it - I have said that so many times I hardly believe it myself anymore. I am convinced it is gone - thank you Ydnar.

I’m not exactly sure what you’re referring to as an error, but if it’s the jaggies, those can be solved with oversampling or filtering.

Sometimes the lightmap collapsing leads to small artifacts on lightmaps without much detail

actually I have edited the old screenies in this thread and marked all the artefacts that came from lightmap collapsing. May I say that they are not small artifacts? most of them are highly visible in game.

I have also reduced the size of the images manually (LVLSHOT like over at quake3world won’t work), who knows what other info i might gather.

And thnx for that tip on replacing the lightimage, i think that will suit that grating perfectly well.

I sincerely hope this thread is closed :slight_smile:

thnx a lot, I appreciate the time and effort you put in q3map2 and specifically the time you put in helping me out here

fraco

[EDIT] those artefacts in my post of 14 Sep 2003 14:20 may not be related to -nocollapse. Unsure where they come from, but at that point I had _terrain on those brushes (and all the keys in the func_group) + I had those keys also on a func_group that had no _terrain shader. Might have been that or some other thing. Don’t see that type of artefacts anymore - with or without nocollapse
[more EDIT] those might have come from not using shadeangle & nonplanar