Black spots on lightmap possible causes?

[TomArrow]

Hey,

I was wondering if you had any idea what could cause issues like these:

In the editor it looks fine:

It's a very big map if that matters.

Cheers

[TomArrow]

P.S. Compile settings I used, if relevant.

-bsp -meta -verboseentities -flares -v 
-vis -saveprt -v 
 -light -fast -dirty -style  -super 2 -filter -patchshadows -nocollapse -nolightmapsearch -debugsamplesize  

Game is Jedi Knight 2

[ghost]

Looks like it could be a bad shader. Make sure all surfaces to be lightmapped have map $lightmap tcgen lightmap in them. Maybe also try without all the extra compile switches if you haven't already.

[TomArrow]

Thanks!

Would a different surface in another place of the map that doesn't have "map $lightmap tcgen lightmap" be able to cause this issue if it didn't affect this surface? Most of the textures here have no shader written for them, they are just ordinary textures, which I presume the game will automatically interpret as to be lightmapped.

What could be an example of a bad shader? And would a bad shader in a different part of the map be able to cause this issue here?

[ghost]

If you haven't written your own shaders for those surfaces then they should have their lightmaps applied properly. I'm not smart enough to debug such a thing without access to the map. Maybe garux can tell you, but either way I'm doubtful this is a bug from q3map2 or radiant. You'd have better chances asking this in a mapping discord.

[Garux]

Removing features to see what is causing the problem is a good plan. No way to find out with this set of data, too many unknown variables. What looks suspicious is -style, because jk engine has styles support, while switch enables q3map2 styles hack, which is using tcgen lightmap, not supported by jk engine.

[TomArrow]

Okay I tried new lightpasses, one without -fast, one without -style and one with just "-fast" and nothing else. Same result pretty much.

I didn't post the map earlier because it was huge and I figured nobody would want to sit through that kind of time (hours) to do the vis & light passes. It also needed models and shaders etc.

However I succeeded in cutting out that part of the map with the issue and now it's much more manageable so here you go: cut out bespin.zip

Zip file contains both the .map, .prt, .srf, .bsp as well as the .bat compile script for convenience.

[TomArrow]

I might have narrowed it down a little bit. I moved the whole map from my last post more towards the center and above the 0 point on the Y (height) axis and now the error at the old place is gone but it seems to have reappeared in somewhat less extreme fashion in some other areas.

Same kind of zip file as in last post, but with the modified map: raise.zip

Surely this must be some kind of bug correct?

[TomArrow]

Not sure if this could be in any way helpful but I tried compiling with GtkRadiant's q3map2 and the result has the same error, looks a little different however:

Maybe that can give some kind of clue. Maybe not.

[Garux]

i'd try something really simple like

-bsp -meta -v 
-vis -v 
 -light -fast -v

-nocollapse or -nolightmapsearch was noticed as causing strange bugs

[TomArrow]

i'd try something really simple like

-bsp -meta -v 
-vis -v 
 -light -fast -v

-nocollapse or -nolightmapsearch was noticed as causing strange bugs

Just tried with exactly those settings. Exact same thing happens.

[Garux]

You've got pretty robust bug there 😉

[TomArrow]

Is this something you will look into fixing? I understand if you don't have the time, but just asking so I can decide whether it's worth waiting with finishing up my map project. It's certainly very irritating looking.

[Garux]

I'm going to look into this, but later, atm 24/7 in different project. It looks like wrong lm uvs are used for some reason, which isn't good. OTOH i've never seen this problem in Q3 mapping. Shall i install JK2 to debug it? The dead simple example to reproduce this would help much.

[TomArrow]

Sounds good. I don't know if its JK2 specific. I think the only thing it depends on jk2 for is the textures and maybe a few shaders. I don't have Q3 installed myself but I suppose you could attempt to compile it with Q3 (after replacing some shaders/textures?) and see if the error is reproduced.

The easy example for reproducing is linked in the above comment by me: https://github.com/Garux/netradiant-custom/issues/109#issuecomment-1162876606

Should include the .map file and all the other stuff. The post after it also contains the .map file and the other stuff for where I just tried to move everything in the map and it changed stuff somewhat.

I also just quickly tried to clean up the map a bit more to make it compile faster (vis is still slow though) and now the error looks different, but is still there. So: Moving around the map changes the look of the error and deleting other parts of the map can change the look of the error as well even though the affected part itself is not changed.

Here's the zip with this newest version, but if you want to reproduce the same error I had in the same form I'd say go with the earlier version. bespin_cutout_small.zip

Let me know if you need anything else, and thanks!

[Garux]

Reproduced this in Q3 with just one texture: but there is no problem, if i omit -vis Vis data is used for lighting acceleration; also vis is picky to geometry, leading to precision errors, that is why geometry coordinates make effect. Basically bunch of tiny/angled structural brushes in this map is what makes the issue very probable. If i blindly detail brushes like this, issue gets gone too So compiler-side fix would be either about refactoring vis precision (which easily may lead to related issues) or trying to figure out why lm uvs are reused wrongly, as mjt says (but this is probably right behavior and there ought to be visibility issues, causing this).

[TomArrow]

Hmm so what's the bottomline best way to solve this? Since you say avoiding -vis improves the problem, is there a way to do a lightpass that ignores vis data? Since vis data is still important ingame to have decent fps, but I'd be willing to sacrifice some compile performance for my final compile.

[Garux]

Just use detail brushes properly.

[TomArrow]

Can you give me an example of the brushes causing this issue? Tiny and angled doesn't ring a bell.

Edit: Also, maybe I'm misunderstanding but you said "there ought to be visibility issues". Does that imply this is not a bug? But surely this behavior is not intended?

[ensiform]

Steps, trim, the extra floor balconies in open air outside for example.

[Garux]

Vis portals structure must be as simple, as possible. This solves calculation time problem too. After all this tech was developed with corridor levels in mind. I suspect there are actual calculation errors, leading to erroneously occluding things ingame, also exposed as lighting bug.