View Full Version : LETS ALL BE DETECTIVES!!!!!!!!!!!
Masterz1337
March 31st, 2008, 11:12 PM
Alright, many of you know that CMT is plauged by tags for bsp errors. Now this is an interesting one.
A map compiles, with 1.36 megs left.
The same map, is given a new bsp, which changes the free space to 1.35 left.
Now, when that new bsp is changed, tool reports that it has gone .04 megs over the limit.
Now this is where it gets interesting.
The BSP that when added, and caused the error was 11.3 MB. The bsp, that took .01 away from the available tagspace, was only 4.93 MB.
So how on earth does this happen? if anything, the revised bsp should take up .03 Megs, not 1.39. The revised bsp, is about 3x longer then the first. There are new shaders added in with the larger bsp, but they are only a color variation on about 7 textures. . Tagspace for SP maps isn't effected by the amount or size of bitmaps, I tested this by removing 2 2048 textures and replacing them with 512s, and it didn't create any change, for those of you that doubt this claim.
So any ideas?
Kornman00
March 31st, 2008, 11:25 PM
well new (shader) tags would affect the available tag space...
Bitmap and sound data doesn't, because they're not stored in the actual tag data. I don't know why they keep being brought up into the picture
Masterz1337
March 31st, 2008, 11:34 PM
But would they be able to affect it that much?
And I know that tagspace isn't effected by bitmaps, but I know alot of peopel here woudl think lowering bitmap res would fix it, since that what is always suggested in people's mp maps.
Arteen and I did another test, where we used the older version of the new bsp, with the interior of the new one as a separate bsp, and to our surprise, it stayed at 1.35 free.
Kornman00
March 31st, 2008, 11:49 PM
But would they be able to affect it that much?
You're adding new data (read: bytes) to the big picture. You said you added multiple new shaders, so I can see it eating up another 0.4 megs.
Masterz1337
March 31st, 2008, 11:54 PM
I think you mis understand or I didn't express it clearly enough.
It goes over the limit by .04, but before the new shaders would have been added, there was 1.35 free space.
Masterz1337
March 31st, 2008, 11:59 PM
Alright, it gets weirder now.
We decided that the new bsp, would be split into an interior and exterior, rather than combine. This time, when the full bsp was added ingame without lightmaps, it gives us .96 free, which is good, but still alot of space from what we started with. We compiled using the ext. and int. as separate bsps, with no lightmaps, and the amount of tagspace lost was 0.
Is it possible that lightmaps somehow effect tagspace? Despite being a bitmap?
Kornman00
April 1st, 2008, 12:03 AM
If I'm not mistaken, the bitmap tags for lightmaps usually have alot of bitmap block instances. So for every instance of one of those blocks, you take up I think about ~120 bytes of memory. So yes, it could have a profound affect in your case since you have so little room to work with.
Masterz1337
April 1st, 2008, 12:17 AM
Well, this is really going to fry your brain now Korn.
As a test, I copied the b30_a lightmaps, put it in a new directory, and changed the name to aa_b30_a from just b30_a.
I referenced the exterior of the new bsp's lightmaps to aa_b30_a, and compiled. The result is....... 2.16 Megs free?!
I don't see how any of this is possible, although I don't think I should be complaining.
Zeph
April 1st, 2008, 12:44 AM
I tried asking you if those new shaders were part of the BSP, but you never replied. If they are, then they have corresponding data in the lightmap. You said they were 2kx2k, so that should be a good amount of information.
Masterz1337
April 1st, 2008, 01:46 AM
Yeah they were. Me and arteen fixed th eproblem with it. I'll psot a lengthy explination in the morning.
Masterz1337
April 1st, 2008, 09:59 AM
Alright, so we solved the problem, with a loss of 0 tagspace. by making the a30_aa_ext and a30_aa_int separate bsps, with and without lightmaps, neither added any space. The seven shaders, were what took away .01 from 1.36, making it 1.35 megs free. We also noticed that when we ran lightmaps, the size of the actual bsp got larger, although it didn't effect the tagspace in the end.
Once we did this, we tried to combine both bsps back together, only to once again, have a tags per bsp error. The logistics behind this are beyond me, but for anyone else who ever has these problems, it's best to split your map up into as many small fragments as you can.
Choking Victim
April 1st, 2008, 10:12 AM
iirc, running lightmaps also creates UV's in the sbsp tag. That would explain why the size of the bsp increased.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.