what to do when map is too big?

(damocles) #1

I knew my map was big, but I didn’t think it was too big…

I can load it and run it fine without lightmap data, but when I attempt to load it with the lightmaps I get a:

hunk alloc failed on 7816xxx error.

This is an ET map and has 11 external 256 size lightmaps - is that really so much? The stock ET maps have around 8-9.

What can I do to help this problem? I’ve already done all the light compiling at standard smaplesize resolution, and no func_groups with smaller sample sizes. I really don’t want to have to use vertex lit terrain cos it looks so naff, and the terrain isn’t that big in the map, I’ve seen much bigger.

7816xxx doesn’t seem like that much too me, that’s only around 7.7MB. Surely ET is geared to handle a map of that size? Are there any compiler options I can use to shrink it down some?

(MindLink) #2

Uhm, Transmitter-Beta has 12 lightmaps (10 256x256 and 2 512x512) and there’s absolutely no problem with it. Your problems must lie somewhere else…

(MuffinMan) #3

everything adds to the hunkmegs, size of the map, lightmaps, textures, sounds, script … everything - so maby you can save some space somewhere else?

(SCDS_reyalP) #4

You can raise you /com_hunkmegs, but this means that your users and server admins will most likely have to do the same.

I assume that the
'hunk alloc failed on 7816xxx error. ’
means that the game at some point tried to allocate ~7 megs from the hunk, and didn’t have enough available, not that the total amount of hunk used was only 7 megs.

/com_hunkused
should show you the ammount of hunk used.
/imagelist
will show you the number of texels used, as well as listing all the texture names.

Both of these number will vary depending on your graphic detail settings.

(pazur) #5

my tips to reduce hunksize:

  • _lightmapscale 2 or 4 in worldspawn
  • higher gridsize (like 128 to 256)
  • use of lightgrid brush
  • reduce textures. try to replace similar textures
  • reduce used sounds
  • delete small “detail” stuff. maybe u can replace them with textures (like wires made of brushes can be a decal texture)
  • opitmize brushwork where possible (mitter joints)
  • be careful with use of models with clipmodel shader parameter
  • reduce visdatasize(less structural)
(damocles) #6

Well, it’s not the map size…

I just removed approximately half the map so that I can make a shorter, faster version for the mapping compo, and the exact same error turns up.

Next step, remove as many textures as possible without making baby jebus cry…

(damocles) #7

Well, it’s not the textures thing either. I removed a ton of textures, and the amount I use now is not even 3/4 of what most maps use.

The log is no help either. It says something along the lines of:

loading map
stitched 40 LoD cracks
xxx tris xxx surfs xxx something or other
Hunk Alloc Failed on 718xxxx

I just don’t get it. There must be something awry with the map or bsp that is causing it to fail when it shouldn’t. Perhaps something causing some kind of infite loading loop that eats up the hunk.

I’m at a complete loss. It’s not the lightmaps, it’s not the number olf textures. I don’t use that many game_models. Not that many entities. Something is causing it to go to hell :frowning:

(SCDS_reyalP) #8

Silly question, but could it be the infamous ‘too many .pk3s’ bug ?

Did you try raising com_hunkmegs ? If it is bugging out and asking for huge ammounts of memory, that shouldn’t solve the problem. OTOH, if you have just a little too much of something it should.

(damocles) #9

I put the hunk megs up to 128 and it still bombed at the exact same place with the same amount of memory allocation failure. I removed all of the extra pk3’s bar a couple of maps and the problem remains. So maybe I’m right and there is something with the map that is causing some kind of memory bug…

…next question - wtf could cause that!? The vis is quite complex (average 8 passages, 12000 portals) but that can’t be helped much because of the style of the map. That’s the only thing left that could be eating up the memory, but it still fails with the extra hunk megs :frowning:

I’m at a complete loss now… I really don’t want to lose 3 months of work because of some bug.

(kat) #10

I know this is gonna sound a bit odd… but delete the current BSP you’ve got sitting in your maps folder and do a ‘clean’ compile.

I’ve had errors crop up in the past that did exactly the same thing in terms of me trying to figure out wtf was causing them only for the error to vanish with a completely fresh clean BSP.

and 12000 portals is a lot of portals…! What sort of map are we talking about here? a terrain?, a complex indoor map?? It sounds like you’ve got a lot of brushes being used for structural calculations…??

(damocles) #11

It’s not the bsp thing because I renamed it to another name when I chopped half of it away. So it was a completely fresh BSP.

12000 portals is a lot, but there’s not much I can do about it. It’s a large open terrain with several large buildings scattered around. These buildings need to be structural to hide the interiors and keep fps down, but their portals extend across the terrain and divide up empty portals into lots of smaller ones. I put in fog/farplane clipping to reduce the amount of portals that need to be checked by the engine,s o although 12000 portals is a lot, it is quite a large map and the vis calculations from any one point in space are hopefully not too complex.

But all of that is irrelevant right now because the bastard pile of crap won’t run :frowning:

(The5thHorsemen) #12

change the default _blocksize to make the splits bigger…

make the building’s cleaner. use solid caulk brush’s to make a building hull as clean as possible. and make the rest detail .

use antiportal inside the terrain when necessary .

(damocles) #13

I’m not exactly new at this. I do know how to make clean levels, the problem is that not all designs can have perfect vis. I don’t think the vis is going to be a problem, as I mentioned it’s only 8 as the average passages, which isn’t that high for an open level. 12000 portals is quite high, but I don’t think it’s crippling high, just higher than average. And it is a large level, so there was always going to be a lot of portals. I’d hazard a guess that around 6000 are in the terrain area and the other 6000 are in the large interior buildings.

And all this is still not helping track down the bug. :frowning:

(damocles) #14

This is really annoying me now…

I’ve been doping clean-up work, and some re-organising of brushes in the hope that I can accidentally fix the problem…

on the plus side I found a good spot to reorganise and managed to shave off a couple of thousand portals :smiley:

on the down side, I have absolutely no frickin idea what is causing this allocation failure :frowning:

(damocles) #15

Ok…I may have fixed it, I may not…

When I originally had the problem, the map was called subpen.bsp and was the larger version. I then shaved half the map off and renamed to minisubpen.bsp and the problem remained…
…so just for kicks, I renamed minisubpen back to subpen and the hunk_alloc problem disappeared. So I assumed script related bug. Just to test I renamed it back to minisubpen and it still works. So it’s probably nor script related, yet somehow it’s working again.

No doubt, I’ll be back here again soon saying it’s stopped working again but for now :banana: