over on Worldofleveldesign.com forums - much less drama over there. Goes by ... I forget what name he uses. 

http://wantonhubris.com/blog/ 

Hello all

Been working some more on a Quake 1 mod and I've got an error that crashes Light.exe

LoadBSPFile: Texture lump size 2103368 too big (max = 2097152)

I was wondering what can be done about this, the mod is more a TC so it has a lot of textures, I would be okay ditching all of the id1 textures if it means I can make more textures (I am not done making all of the new ones I need by far)

any info would be helpful.

Thank you all! 

iirc, that sounds like you have too many textures in your map. basically you need to reduce the total size to less than the max (~2mb) so just remove/replace lesser used textures with others, or reduce the size of textures. 

Ah, thats a bummer

Just wondering since the game will end up using Darkplaces engine, are there any modded build tools that can maybe increase the size above 2mb? Game doesn't have to be Winquake friendly ect.

Thank you for your help so far 

I think they're currently the best. Not sure if it will help with this error though.

txqbsp/treeqbsp: http://user.tninet.se/~xir870k/

There are modded versions of his vis/light with multithreading and colored light support:
vis: http://celephais.net/board/view_thread.php?id=60365&start=93
light: http://celephais.net/board/view_thread.php?id=60480&start=35 

use aguirre's tools, his are the most advanced compilers out there. they will compile maps right up to the max that can be done with the .bsp format.

or rather, use his qbsp. for light, use MH's modified version of aguirre's light: http://www.quaketastic.com/upload/files/tools/windows/BengtLightColouredR2.zip
it has coloured light support and multi-threading.

and for vis, use tuna's fixed version of willem's modified version of aguirre's vis (hehe...)
http://www.quaddicted.com/tools/wvis_20100119.7z
which likewise enables multi-threading (and fixes the bug with the vis progress saving) 

BJP's qbsps have a -hilimit switch to enable extreme capacity. This may be worth a try, though probably not solve the texture lump problem. If you can't reduce their number/size (considered grouping several similar textures into one?), and are aiming at DP anyway, you can use the Q3 map format and compile the map with hmap2. This way the map will have external textures which should bypass the texture lump issue. 

 

aguirre's (BJP) qbsp already has > 2mb tex lump capacity.

also, i've never been able to get -hilimit to work.
i mean, it compiles and whatever, but no engines can load the map. not even aguirre's engine. :P 

I need -hilimit. Without it my map wont compile. My map runs in Fitz .85 (and its children), Darkplaces, Aguire-Quake etc. When you hit the vertex limit weird stuff happens. The map will compile, but DP and Fitz&co no longer run it, and AguirRe's invincible, un-crashable engine will run it but you get artefacts in the form of giant flickering polygons all over the place. 

Dont break the vertex limit of 65### whatever it is. 

I think -hilimit merely allows the map to compile, it doesn't magically make engines support the resulting bsp. I used it to exceed 32k leafs I think, and it worked for that test. Not sure if you need it even to exceed marksurfaces though. 

that's really all i meant. i mean, what's the use of compiling a bsp that can't load in anything at all. :P 

Probably aguirre hoped that engines would add support once there were bsps to test it on. At least, he added a lot of support to his engine. Sounds like he didn't get to everything though. 

The 65thousandish mark. But I started to need the -hilimit command way back when it was only 40'000 or something. If -hilimit wasn't there, really large maps would be a no-no. 

i have a map that is right at the 65k vertex mark, but the other things are either below or very close as well, hence why i felt -hilimit was completely useless.

must be in the way the map is made that makes other things balloon up faster than vertices. 

How much does the openess of an area affect VIS time? If an area is huge but low on detail does VIS time still get hit really bad? 

yeah, detail and 'openness' both affect vis.

for example, i've got a map that is at 65k vertices, that is to say, about as detailed as you can be, and it full vises in less than 4 hours. flat 3 if i let the machine be and not use up the cpu. mind you, this is on a dual-core cpu, so single core, it'd be maybe 6-7 hours, but that's still very fast.

another map is about half that, but is basically one giant open terrain area, and the vis estimate reached 200 hours before i gave up. (since it's wide open, there's no real point running a full vis anyway).


it's not just details, it's also how many different planes there are in an area, because many different planes (for example, tri souped terrain or curves/beveled edges) will force qbsp to cut the area up into many many (many) small volumes which takes exponentially longer to vis. 

What would happen if you created an empty box of sky and just placed models inside it? in showtris the sky always looks like it's has less polys cutting it up :E 

But as soon as there's geometry in, things slow down. I remember a certain coagula map that was the biggest bitch of all Quake to vis which made the author feel stupid for months afterwards.

Modern compilers split a simple sky surface only twice if there's no interference (older ones would treat sky as a regular texture which is why back then it was recommended to scale it up). So, indeed, you can box your whole map with sky and turn everything within into a large func_wall. Bam, VIS trouble solved! 

To be more precise, they split it once, so it will have two polys. In a box with flat symmetric walls and no other brushes touching it. 

Thanks negke. I was thinking about it's use for adding a bit of surrounding geometry beyond walls in large areas.

And on a similar note: Quoth and replacing geometry with BSP models:

I've got it working, but you don't appear to be able to apply an angle change to it. This just a basic limitation with the technique? 

Btw. the func_wall box thing above was a joke in case you really thought it was the way to go. If it's just for additional detail 'outside the window', then it's fine.

Yes, I think external bsps can't be rotated. They always appear relative to worldspawn (angle 0). For angle varations you'll have to create several instances in individual bsps. 

If it's just for additional detail 'outside the window', then it's fine.

Yeah just thinking of it has some extra eye candy