View Full Version : BSP Error: "Lightmaps exceed max memory"

12-11-2002, 03:10 PM
The level compiled as it usually does, then after the final countdown in the light process I got this error message:

"Lightmaps exceed max memory (8403296 > 8388608)"

Needless to say, after waiting nearly seven hours for the stupid thing to compile, I wasn't the least bit impressed.

Anyway I can fix this?

I'm using SOF2Map by the way. I don't get this error with Q3Map2 (I get the annoying "nullpolyshader" error instead).

12-11-2002, 04:26 PM
1. You need to increase the size of the lightgrid. I forget how, since I no longer need to since Q3Map2 does it automatically.

2. If you need help with Q3Map2, visit the Q3Map2 support forum (http://www.splashdamage.com/phpBB/viewforum.php?forum=8&261). I'm sure you can get some good help there.

12-11-2002, 06:27 PM
I had the same problem a while back, heres a link to the thread about it:

I did manage to solve it eventually, I had to delete all the lights and redo them all, took ages but it did compile fine after that. The thread suggests there are other less drastic measures before redoing all the lights.

12-12-2002, 05:58 AM
Cheers for the link Kengo.

Originally posted by Emon
1. You need to increase the size of the lightgrid. I forget how, since I no longer need to since Q3Map2 does it automatically.

I was hoping I wouldn't have to do that, it doubles the compile time. I can't be bothered with Q3Map2, I've tried everything that I've been able to find that will fix it but it does no good. I'll just sod it and use SOF2Map instead.

12-12-2002, 07:46 AM
That "nullpolyshader" error bothers me a lot more really. If you could just fix that, you wouldn't have the lighting problem and you could just use Q3map2. It's alos an error that can happen in SOF2MAP. It would be pretty f*cked up if you got that error later on in your mapping process.

Does anybody know what exactly causes that error? Maybe someone should contact Raven about it.

12-12-2002, 10:40 PM
There is no other way unless you increase the lightgrid or massivly reduce the amount of lights. You should go to the Q3Map2 support form and ask about it. Ydnar actively posts there, he wrote Q3Map2, so he'll know what to do. I've already taken the liberty to go and post for you. I'll let you know if I find anything out.


12-13-2002, 10:32 AM
Cheers Emon.

I'd love to get Q3Map2 to work properly, its efficiency will come in very handy. It's just a pain it doesn't work.

12-13-2002, 01:04 PM
Where do you get the "nullpolyshader" error? In-game? Does the map look correct or does it not load at all?

Is your map large? Do you have terrain? What version of Q3Map2 have you been using?


12-13-2002, 05:00 PM
I've been using the latest version of Q3Map2. This error also persists with a couple of older versions.

The level loads OK, but most of the textures appear as solid white or as black with white grids on it. The error message "nullployshader" actually appears in-game in the top left of the screen multiple times as textures are loaded.

There are a few terrain patch areas in the game, but the error occurs all over the map.

12-13-2002, 05:34 PM
I've also deleted all duplicates of "shaderlist.txt", as suggested in other threads. No luck.

My level is saved and compiled in the "base\maps" directory. But when I go to play it, I run a mod which has all the model replacements and such in it.

12-13-2002, 05:40 PM
Just a hunch, but you could try moving your map(s) to your mod folder as well.

12-13-2002, 05:43 PM
Well I just this second tried running it without the mod. I get the same error.

Let me try your idea Emon, I'll post with results in a moment.

12-13-2002, 05:46 PM
Just tried it, doesn't work...


12-15-2002, 12:04 PM
I resorted to altering the gridsize and using SOF2Map again. No luck. I get the exact same error message, so the gridsize has nothing to do with the memory. Which is a tad annoying to say the least.

I can't compile my level, unless I find a way around it, it's not going to get released.

12-15-2002, 12:46 PM
Have you tried copying the textures and shaders of the textures which cause the error into your mod folder and play the level with the mod?

12-15-2002, 12:49 PM
It just occured to me that it could be caused by an evil brush or something like that. Have you tried running the bobToolz brush cleanup?

And are the textures/shaders you get the error on custom ones or ones from the assets?

12-15-2002, 04:06 PM
I get it from both custom and Raven ones.

I think I may have found the problem.

My Q3Map2 BAT file says -fs_basepath "C:\Games\Jedi2\GameData"...

I can't help thinking that that should be -fs_basepath "C:\Games\Jedi2\GameData\base"...

Think that could be it?

12-15-2002, 05:07 PM
Yeah, that's probably it. Why are you even using BAT files? GTKRadiant 1.2.11 has Q3Map2 integrated.

12-16-2002, 04:33 AM
Compiler works a lot faster without Radiant in the background. It's also quicker to fire up a compile that way.

I was wrong about the basepath thing anyway. I tried it with a test map and it worked better with the basepath as "gamedata" than "gamedata\base".

I also tried the brush cleanup, it got rid of lots of invalid planes and such, but didn't do anything to stop the error.

12-16-2002, 09:07 AM
I don't know if this has been said before, but most MP maps that also have this problem have used multiple directories for custom textures and multiple shader file.

When Shadriss and I were working on DoTF .v2 I made sure I put every single custom texture in one directory and one shader file. And that map does work in SP. And I compiled it with Q3map2.

I don't know how you structured your pk3, but this may be a solution. It looks to me that Raven might have also done this, because some textures appear in multiple texture directories.

So if everything else doesn't work, try that. It will be a hell of a lot of work.

12-16-2002, 09:12 AM
Oh yeah, and if you used non-custom textures from different texture directories, that might be a problem as well. Maybe the SP engine doesn't like using 3 or 4 different texture directories and shaders for SP maps.

All the Raven maps probably used only one Texture dir and shader file. You might have to copy some stuff over to your own texture directory even if it's not custom.

12-16-2002, 01:49 PM
You could be right, but it doesn'y explain why I don't get the error in SOF2Map.

I tried compiling with Q3Map2 directly from GTKRadiant (it uses different extensions to my BAT). Instead of this error, the level refused to load and a dialogue box came up saying "SV_SetBrushModel: NULL".

I just can't win. I've worked long and hard on this level, it's just shaping up to be really good and it looks like I'm going to have to scrap it.

12-16-2002, 02:13 PM
I've just written a new BAT based on the command lines in the GTKRadiaint porject settings window. Can somebody who knows more about Q3Map2's extensions tell me whether it looks right or not?

@echo off
"C:\Games\Jedi2\GameData\Radiant\q3map2.exe" -v -fs_basepath "C:\Games\Jedi2\GameData" -fs_game base -game jk2 -meta C:\Games\Jedi2\GameData\base\maps\crasher1.map
"C:\Games\Jedi2\GameData\Radiant\q3map2.exe" -fs_basepath "C:\Games\Jedi2\GameData" -fs_game base -game jk2 -vis -saveprt C:\Games\Jedi2\GameData\base\maps\crasher1.map
"C:\Games\Jedi2\GameData\Radiant\q3map2.exe" -v -fs_basepath "C:\Games\Jedi2\GameData" -fs_game base -game jk2 -light -fast -filter -super 2 C:\Games\Jedi2\GameData\base\maps\crasher1.map

12-16-2002, 02:18 PM
Ahhh... I may have found the cause to the shader error. According to the log, the compiler is taking in 2 "shaderlist.txt" files. I'm confused because I've already been over the folders and PK3s time and time again looking for a duplicate shaderlist and have not yet found one. There must be one somewhere there.

12-16-2002, 02:29 PM
This is weird.

I deleted the one shaderlist that I knew of, and now the compiler can't find any shaderlists.

12-16-2002, 02:35 PM
Originally posted by AKPiggott
You could be right, but it doesn'y explain why I don't get the error in SOF2Map.

That is weird indeed. But it is an error that also occurs in Sof2map. LDJ used Sof2map for his original DoTF map and it had the same problem.

I just can't win. I've worked long and hard on this level, it's just shaping up to be really good and it looks like I'm going to have to scrap it.

Before you do that, would you mind giving me a crack at it? I really want to get this problem solved.

12-16-2002, 02:50 PM
Cheers White but I think I've solved it!

I removed the "fs_game base" parts from the BAT and now the shaderlist only loads once! It appears the error was with the BAT the whole time. I'll compile it tomorrow morning and let everyone know how well it goes.

12-16-2002, 02:54 PM
I'm keeping my fingers crossed :)

12-16-2002, 05:26 PM
If your compiles in GTKRadiant are slow, then turn off BSP monitoring in Prefs and shut it down into sleep mode when you compile.

12-16-2002, 05:29 PM
Glad to see you got it working, hopefully. :)

And yes, never ever scrap your work because you can't get it to compile. ALWAYS give it to one or more people and let them try it out first. Wouldn't want to loose something that works perfectly.

12-17-2002, 04:40 AM
I just compiled it, I still get the error "SV_SetBrushModel: NULL". What causes that? A pain really because I can't find out whether I still get the shader error.

12-17-2002, 06:55 AM
Do you get that in Radiant while compiling or do you get it in your junk.txt that's generated by Q3map2?

I've never seen that error before, but maybe we can check out some Radiant forums and or some Q3map2 forums for it.

12-17-2002, 10:10 AM
I found out what it is. It is when you have a brush that has 0 thickness. I think this problem was generated with the bobtools crush cleanup "fix".

Luckily, I was able to find a backup of my level that GTKRadiaint created shortly before I ran the brush cleanup. That was very lucky, I thought the level was completely screwed for a moment.

Vis compile with this week old version of the level is taking unusually long. I recently went and converted a load of structural brushes to detail brushes, so the backup was probably created before then.

12-17-2002, 02:03 PM
Damnit. I compiled it and still got the same shader error. It can't be the BAT then.

However, I discovered that the brush cleanup wasn't causing the null brush error (it was something else that I can't be bothered to explain). So I'll see if compiling after cleanup helps.

Also, what extensions can I use to speed the "vis" up? With Q3Map2 it takes over 5 hours, with Sof2Map it takes about 2 hours.

12-17-2002, 02:11 PM
maybe you can take out the lightstage, if you hadn't already done that. Or if you can't do that, delete "-super 2" and if you're using it, "-bounce 8". That's really for a final compile.

But it's weird that it takes longer than Sof2map. It should be faster.

12-17-2002, 04:15 PM
It's only the vis part that's slower. Light takes about an hour in Sof2Map, it takes half an hour in Q3map2.

12-17-2002, 05:00 PM
that's even more weird. The Vis part is usually the fastest part of the compile. And Q3map2 should surely be faster in that area.

Light can be slower, because you can add so many smoothing options.

12-17-2002, 06:30 PM
Q3Map2's BSP and vis stages are more complex and create better output, so they take longer. Meta and patchmeta, which reduce surfaces over the map by merging surfaces and that sort of thing slows it down, but the BSP in the end is better.

Leslie Judge
12-18-2002, 01:31 AM
And... you can use -fast to make the VIS phase faster.

12-18-2002, 04:18 AM
Cheers everyone.

I just compiled it after running the brush fix. Guess what happens when I run it? NullPolyShader.

OK to sumarise, my level compiles OK with Sof2Map (disregarding the memory thing). It used to compile OK with Q3Map2 until about 6 weeks ago, this suggests an error in the map, but this error doesn't seem to bother Sof2Map. There is absolutely nothing wrong with the file structure of my textures or anything. I can confirm that. It's something in the map that has done it. Anyone got any suggestions as to what that could be?

12-18-2002, 07:35 AM
It's not a specific Q3map2 error. It can happen with Sof2map as well. Maybe you would have gotten it with Sof2map as well if you didn't get the memory error.

I think you should just contact Raven about it. They should know about it.

Anybody know how to contact them?

12-18-2002, 01:01 PM
No it's Q3Map2 specific. I've been getting this error for a while now, but I just stopped using Q3Map2 and used Sof2Map instead. I didn't get the error with Sof2Map and I was quite happy using it, until I got the memory error.

Here's a picture of the error in all its glory:


The "NullPolyShader" message is constantly appearing in the top left hand corner. Hasn't come out on the screenshot though.

12-18-2002, 01:37 PM
I know you only have it with Q3map2 in this case, but it's not a Q3map2 only problem.

This (http://homepage.bysky.nl/~ka1e1/null_poly_shader.jpg) is what I get when I load LDJ's episode1 map into SP. And I'm 100% sure that it was not compiled with Q3map2, because I explained him how to use Q3map2 when he was working on his Carbon Freeze 2 map.(which also has the null poly shader error btw :)) And he made Carbon Freeze 2, 2 maps after Episode 1.

12-19-2002, 05:26 AM
I know the NullPolyShader error can be generated by any compiler, what I meant was that it is Q3Map2 specific in my case.

I just tested my level in MP and I still get the error... so it's the same error as LDJ's but it must be caused differently.

12-19-2002, 08:45 AM
I'm gonna get in touch with LDJ, to see if i can get his mapfile. Shouldn't be a problem. I'm gonna do a little experimenting with that. Maybe if i can fix that one without completely remaking it, like we originally did, we'd be a little closer to a solution.

12-20-2002, 02:41 AM
That will hopefully provide some light on the subject. Thanks a lot.

12-20-2002, 08:12 AM
Ydnar suggested size could be a problem here. I'm gonna try compiling Raven's "kejim_outpost" map file. If size is an issue, the error should occur in this level as it's a lot bigger than mine.

12-20-2002, 04:58 PM

I looked up on the memory error with SOF2Map and I found that changing the samplesize in the command line should help. And it did, bloody marvellously in fact. The level compiled brilliantly and in just over two hours too. So until another fatal error comes along, I think I'll stick with SOF2Map.

12-20-2002, 05:24 PM
That is great news indeed.

12-20-2002, 05:34 PM
But wouldn't changin' samplesize degrade the light resolution in map? I struggle with the same problem and what I'm tryin' to do is degrade the samplesize only on some big areas through the shader script. I'll let you know if I make it right.
That is, if you're interested...

12-20-2002, 06:22 PM
Well to be honest the level looks the same to me as it did before. Framerate has also improved slightly.

12-20-2002, 06:45 PM
The "LIGHTING" part of MAX_MAP_LIGHTING refers to the lightmaps created for the map.
Lightmap images are created by the third stage of the compile.. either by -light using the old light-tracing algorithm or -vlight using MrElusives Volume-casting light algorithm thingy.

Each Drawable Polygon surface has lightmap texture coordinates created for it by the first stage of the compile. The third stage creates the actual lightmap images for each surface, and all of these images are squeezed onto 'pages', with multiple lightmap images on each page. Each of these pages is 128*128 pixels in size, enough to cover 2048*2048 units of brush surface at the standard lightmap resolution (16*16 units per pixel). There is an upper limit on the number of lightmap pages that can be crammed into the BSP.. probably about 4mb. That works out to about 80 pages of lightmaps, which is quite a lot of surface area..

If all the sections of your maps compile fine individually, then it must be that the lightmap pages created for the combined map are greater than this limit.

There are two solutions to this problem:
1: easy but lower quality, use 32*32units per LM pixel resolution.
q3map -samplesize 32 mapname
q3map -vis -saveprt mapname
q3map -vlight -samplesize 32 mapname

2: more difficult but much better result, reduce the total surface area of the drawable polygons in the map. This will reduce the number/size of the lightmaps, reducing the number of lightmap pages created, reducing the total size of the lightmaps in the .bsp.
Drawable polygons are created for a surface even when that surface is hidden by a detail brush. Apply textures/common/caulk to these surfaces, or delete them entirely if they are patches.
Drawable polygons are also created for surfaces that are only partially hidden by structural brushes - and, providing that the drawable polygon is convex, parts of it may still be hidden behind structural brushes, taking up extra lightmap area. If there is a significant amount of the area on a surface hidden by a structural brush, split the surface up until only the visible part exists.

12-21-2002, 03:02 PM
Heh.. that's funny Evader, that's the same source that I read from after I searched the web a bit. It does lower quality, but you can hardly notice it.

12-21-2002, 04:44 PM
If you say so...
I didn't dare even to try, I kinda hoped I could raise my resolution to 8X8 or even 4X4... But it ain't gonna happen'. Would you be kind just to remind me, how do you change samplesize? In worldspawn or in q3map2 command line?

12-21-2002, 06:54 PM
In the command line. Simply add "-samplesize 32" or whatever size you want it to be.

12-21-2002, 07:51 PM
OK, thanks. I hope I won't have to. q3map2 compiled without error all of a sudden.

12-25-2002, 02:09 PM
Originally posted by AKPiggott
I resorted to altering the gridsize and using SOF2Map again. No luck. I get the exact same error message, so the gridsize has nothing to do with the memory. Which is a tad annoying to say the least.

I can't compile my level, unless I find a way around it, it's not going to get released.
Ive heard of your problem nowhere, maybe you need to use the lowmem bsp compile, i doesnt change the quality it just takes allitle longer. Make sure its low memory not the less momory option. I hope this works for you...!:eek:

12-28-2002, 02:37 PM
AK, there are new posts in the thread over at the Q3Map2 forums... Have you seen them yet?