Lightmap problems

#1 @David - I'm looking into this now. If you could email me the CSM file at tom at sickheadgames dot com it would help.

#2 @Tom

Thanks for having a look - I have just sent the file.

I have had some success in reducing the green brushes by adding even more geometry - seems to change the lightmap packing to avoid most of the green bits.

#3 The bit i've gleened from looking thru the code:

Lightmaps that are not in the outside zone are filled with the ambient color.
Lightmaps that are in the outside zone are filled with black.
Sheets are filled with pink before lightmap packing is done.

The final sheet during repacking is filled with pink.
All sheets where a binary search was needed are filled with green.

So at least i know the green is coming from the engine trying to fit alot of maps into multiple sheets. I need to check your map to really get into this.

Also do you happen to be trying to use the alarm lights (worldspawn property 'emergency_ambient_color')?

#4 @ Tom

I am just using some light_omni entities for lighting with ambient set at 0 0 0 in worldspawn.

Looking at the screenshot it seems to be certain brush faces in shadow from a particular light that go green.

I have noticed that as I added geometry to the map there are occasions when there are huge numbers of green brush faces and then, after adding a bit more geometry, the green disappears for a while.

I have also had some success by adding lights with low colour levels (1 1 1 to 25 25 25) and a large radius to get more light maps in there.

I am trying to get just enough light into the map for background lighting so I can light the rest of it with lighting pack lights. I tried ambient in worldspawn but it looks awful.


And - to anyone reading this and wondering whether to buy the exporter - go and get it now! So much better than using Quark :)

#5 I have seen this happen when there were a large number of brushes in the interior. I haven't investigated it but I suspect there is some bad indexing (like a U8 going out of range) in the lightmapping code.

#6 Ok it really looks like the lightmap filtering issues... i'm gonna go off and integrate implement John Kabus' lightmap fix as option on export.

Unfortunately i'll be out of town for the weekend, so it might not be till monday till i can post a 1.02 version of the exporter for you to test. We'll see how much i can get done tonight on it.

Sorry for the delay David.

#7 @Matt - Well i do see some stuff that could be explained as what you're saying. I see brushes that seem to be completely green. And this map that David sent is fairly large... it reports 2531 surfaces to light.

I guess i'll find out soon enough. Any tips to debugging it?

#8 @ Tom - dont worry about the delay - thank you for taking the time to look into the problem (and thank you once again for writing the exporter!)

As an update, I spent the afternoon messing around with the map and have got to a stage where the green brushes suddenly disappeared. I now have a few *very* slight purple hints and some jet black brushes (but where they are looks fine in the dif).

To get to this, I have actually added geometry (reporting 2837 lit surfaces now) and removed a set of light entities.

To recap - from exporting progressively as I have built the map I have noticed that the 'green brush phase' starts to gradually appear as you add brushes until at a certain point you get large number of them. As you continue to add brushes, the number then starts to decline until they suddenly disappear. This lack of greenery continues for a while until another 'green brush phase' starts. So it seems you can either backtrack to fewer brushes or add more brushes until you get to a sort of mid point where it is properly lit. The only drawback is the time taken to keep adding, exporting, lighting and testing until you find a good point to stop. You then hesitate to make any changes unless you end up right inthe middle of a green brush session again.

On a positive note, I have not had one bad export from the map (light issues aside) even though it is a large and complex model.

#9 What i found so far (i'm sitting in a bar in New Orleans right now) is that as some point the lightmaps get completely screwed up. There are shadows in weird places where there should be none. I exported your CSM as a map and ran it thru map2dif for TGE 1.4 and it worked perfectly. So i'm now diffing the code to try and figure out what i broke.

#10 Thanks again Tom.

I never thought to run it through map2dif from 1.4 (mainly as the old map2dif used to choke horribly on it).

Enjoy New Orleans :)

#11 Tom - just tried map2dif from 1.4 and the results are virtually identical with my newer green free geometry (even down to the black brushes I mentioned above) - in the screenshot the map2dif is on the left and the pipeline is on the right.

The only difference I can see is that pipeline seems to allow different interior and exterior light scales whereas map2dif seems to choose the exterior only when they are different (shadows are a lot sharper in interiors with the smaller scale from pipeline than with map2dif and the dif is 200k larger with pipeline presumably due to the larger interior lightmaps). I dont know if this causes any problems but thought I would mention it.

If the scales are set to the same amount then the export results are the same with the exception of the orphaned poly count which is around 1600 in pipeline and 89 in map2dif (I have lots of shared brush faces which are nearly all null textured - is pipeline counting these as orphans?)

#12 @David - I'll have to look at the inside/outside lightmap scales tomorrow. It was supposed to set the same scale inside and out for TGE exports, but i can imagine that if i do not that it could potentially screw up interiors with portals that pass thru outside light.

I'll take a look at the orphaned faces as well... it could be that i'm marking NULL faces wrong.

#13 Hey David... just wanted to let you know i'm still looking at this issue. Sorry it's taking so long.

By the way are you using the shader engine by chance?

#14 Ok i found the issue... your map set to a light scale of 8 units creates 265 lightmaps or so. The DIF format cannot store a lightmap sheet index for a surface that is greater than 254. So basically you've reached a limit in the maximum allowable lightmaps.

First thing i'm gonna make sure that it halts export when you get too many lightmaps. But as far as fixing it either a) i must support larger lightmaps or b) the sheet index array needs to be expanded to 16bits... or both maybe. Matt... have you thought about this issue?

#15 Looking further into larger lightmaps i see that it is not possible without breaking the DIF format. Surfaces use single bytes to define lightmap sizes, so they are format limited to 256x256 or less. I hope Matt gets to correcting this soon... at least for the shader engine.

So David you have only three options: simplify your DIF, break it into more than one DIF, or lower your lighting scales.

The one other trick i think i can add to the exporter for you is "per-brush" light scale control. This way you can take some of your larger unimportant brushes an decrease your lightmap usage for them. Do you think this could help?

#16 On my todo list

#17 Tom.

The changes I made which resulted in the sudden appearance of green colouring were to try and smooth a few shadows out.

I can live with less smooth shadows so I think that lowering the lighting scale will be the best way out of this for me.


However (sorry), I have just spent a few hours doing tests and there is still a green (and purple) problem.

First though - another minor problem - map2dif uses a different name for the lightscale property - "light_geometry_scale" (see entityTypes.cc around line 70 or so). This property is not added to a standard worldspawn entity in cshop. If this is missing from the map file, map2dif uses a default value of 32. This had me stumped for around half an hour as the map2dif difs were coming out at the same size regardless of the inside and outside lightscale settings. :/

So after manually adding the "light_geometry_scale" to the map files :-

In cshop, I changed the lighting scales to 32 for both internal and external lighting and exported a torque dif and a torque map. Using map2dif (from 1.4) I then exported another dif using the map file I just created.

In these screenshots, pipeline dif ones are session screenshot_023_xxxxx.jpg and map2dif dif ones are session screenshot_024_xxxxx.jpg.

I think you will agree that there is something definitely not right?

The only thing I dont know of course is whether I am still busting the lightmap limit with the lightmap scale of 32.

So I tried scales of 64 and 128 but the results are the same - pipeline has green and purple bits (which get worse as the scale number gets bigger) whereas map2dif has none whatever the scale.

The only things I have noticed from the tests that may help is that the dif sizes from pipeline and map2dif are rather different :-

Lightscale=32, pipeline dif=658kb, map2dif dif=762kb
Lightscale=64, pipeline dif=585kb, map2dif dif=667kb
Lightscale=128, pipeline dif=547kb, map2dif dif=616kb

Same number of surfaces reported, same number of zones reported so the only thing I can think of is lightmaps? You arent using different compression code or anything are you?

BTW - I tried the obvious one of putting a light_geometry_scale value in the worldspawn entity in cshop which makes no difference.

#18 Inside/outside_light_scale was a feature from TSE's map2dif which this exporter is based on. Setting the inside and outside light scales to the same value has the effect as light_geometry_scale. I had some success with your map by setting the inside scale to 8 and the outside scale to 32. This doesn't hit any lightmap limits and looks fairly well... aside from the small green and pink bits. The larger bits were caused by the overflow of the sheet index causing surfaces to use the wrong lightmap.

So the small green and pink bits your getting from the pipeline exports look to be the lightmap border issue. The effect seems to differ from card to card and is enhanced when fullscreen anti-aliasing is enabled. John Kabus came out with a patch to fix these which adds borders around each lightmap surface. The 1.4 map2dif has this patch, Pipeline does not that this moment. I'm integrating that now. It's the reason your DIFs are bigger also... the borders take up more lightmap space.

I should have a 1.1 beta here in the next day or so for you to test. My changelist so far for this new version:

- You can now import Valve 220 maps into Cartshop.
- Support for John Kabus' lightmap borders fix.
- Completely disabled Torque memory manager to vastly reduce plugin memory usage on large maps.
- Smart texture copy overwrite prompt now asks yes/no and not ok/cancel.
- Fixed bug in orphaned polygon detection.
- Inside/outside lightmap scale options work properly in TGE.
- Added lightmap export statistics to output.
- Enabled all debug checks in release build for better error reporting.
- Clarified a few confusing error messages.
- Exporter version number is added into .map file.

I still need to finish up on the .map importer and need to look into a texture rotation bug.

#19 Thanks Tom - I was using 8 inside and 32 outside for a while but must have added too many brushes for that setting now as well.

I mentioned the light_geometry_scale being missing as it doesnt go into an exported map so if you do use map2dif for any reason it will default to scale 32. Maybe a point for the faq or docs?

As I said earlier, I am grateful for being able to work in something other than Quark. I will look out for the 1.1 beta and put some testing into it for you rather than waiting for release to do a lot of work :)

#20 It's probably not that it's too many brushes now. It's that by default the 1.4 map2dif uses a 10 pixel border around all lightmaps. That sucks up *alot* of extra lightmap space! In Pipeline it will be configurable from the export dialog and the new lightmap stats will help you determine how much it's hurting you.

Ahh... right. I fixed the .map exporter so that it adds light_geometry_scale as well as the interior and exterior light scales. As long as interior/exterior appears after the light_geometry_scale there shouldn't be any issues when using it with TSE's map2dif.