Question about decals

I would guess that making decals are less expensive on the game resource wise than making a texture of the same image???

Anyone know?

Ive got my first ever map just about completed. Still learning alot and one thing Im discovering is how much different things can make a difference to the file size. Right now I have a map thats a bit too big in the file size so Im trying to see where I could reduce. I have some textures that really could be decals.
Can that make a difference?

how big is it? any SS's? its not like a blown up version of your kitchen is it?

lol no you bastard

No SS yet until i get this issue resolved. Its very big, bigger than Octagon in file size. I have a bunch of custom textures and lots of func_details, many of which could be made into decals which might significanly reduce the file size.

I've got a RC candidate running on a server now with no problems for the server but playing on it causes a client timeout in a few minutes which I believe is because of the file size or number of func_details.

Prob just gona have to save a new version of the vmf file and try to change things over and see what the effect is.

Decals are still a texture. Custom content will always bring up your filesize, the only way around it is to use less custom content. Models are usually quite small but textures are not.

For example: a standard 512x512 compressed texture is about 170 kb, a normalmap plus specular mask for that texture is about 1.3mb - so for every 10 custom textures with bump and spec you're looking at roughly 15mb filesize increase. Doubling the dimensions of the texture to 1024 x 1024 multiplies all that by 4.

func_detail is generally a good thing and wont really bump up filesize.

Your first step should be to compare the file size of your raw compiled .bsp vs your .bsp with the all the custom content packed into it. If it's still very large without any custom content then you have a problem.

If the difference is huge then its simply due to all the custom content. It's a balancing act between adding shiny new things and keeping the size down really - I generally aim for 50mb max uncompressed filesize as a good compromise.

Things I can think of that will also bump up size:

using HDR - this will add 2 sets of lightmaps, cubemaps etc

lightmap values too low - they only need to be low where they actually make a difference and can be balanced out with using very high lightmap scales where they wouldn't be noticed like flat dark ceilings and such

not using compressed .vtf files - base textures should always be compressed, normalmaps are usually not compressed due to how crap it makes them look

lots of displacements - displacements will bring your filesize up, however they compress very well when using serving bz2 compressed maps and are very easy for the engine to render.

bad vis optimisation - don't quote me on this one, but I have a feeling a really messed up vis will add some size to your bsp (see compare raw vs packed above)

not serving compressed map downloads - lots of maps with huge filesize will compress down very nicely when compressed, take a look at dm_octagon for example. If I remember rightly its something like 30mb vs 85mb.

Oo, wall of text.

Update: Yea most of my custom texture files were over 1.3 mb each because the files I made them from originally were all bigger than 512 px X 512 px. I was able to reduce them to 512 X 512 or smaller (most are at 256 x 256) without noticable reduction in the image quality. This reduced the size of the map file significantly, now its about as big as LD_r4 so its much more managable. Im going to run it on a server for a while and see how it goes.

Paradox wrote:Update: Yea most of my custom texture files were over 1.3 mb each because the files I made them from originally were all bigger than 512 px X 512 px. I was able to reduce them to 512 X 512 or smaller (most are at 256 x 256) without noticable reduction in the image quality. This reduced the size of the map file significantly, now its about as big as LD_r4 so its much more managable. Im going to run it on a server for a while and see how it goes.

Looking forward to seeing it

Boshed covered alot here. (as per usual )

I would reccomend converting any WAVs to MP3s too.

With no noticable sound quality loss and a massively reduced filesize its well worth doing.
I just did it in my map and the filesize went down by around 7mb!

Two free programs:
Audacity (best) - http://audacity.sourceforge.net
FreeRIP (does the job, but use audacity) - http://www.freerip.com

I gave up on the sound, because no matter what I did it just didnt work.

Thanks for those links though

This sound:
C:\Program Files\Valve\Steam\SteamApps\jacka18l\half-life 2 deathmatch\hl2mp\sound\pseudonym\splash.mp3

Will be this sound name in an ambient_generic:
pseudonym\splash.mp3
(or in a soundscape)

Mp3s dont preview in the sdk sound browser, but will work ingame so use them.
wavs do preview in sdk, but have a big nasty filesize.


Another thing i thought of to reduce your vmt count is to put multiple images into one vtf and then align it accordingly ingame.
fair enough you will have a large single .vtf, but you will cut down on the amount of .vmts associated with each texture you are not having to use as you have it all neatly in one place.

now i dont know how reliable this is, but valve did it with some posters in l4d no mercy and i think they know their mapping also theoretically this would work, but then again .vmts dont add up to much in filesize.
Just brainstorming here, anyone any thoughts on this last idea?

give it a try paradox. or msg for more info.

Pseudonym wrote:Just brainstorming here, anyone any thoughts on this last idea?

I think there's some overhead on using several vtfs (file type headers, colour indexes and such) so compacting them into one should make it a little smaller, but like you said filesize of vmts is not really an issue. This requires investigation

Edit: Woo science time!

So, tested this with 4 x 256x256 and 1 x 512x512 simple textures (compressed, no alpha, vmt contains just basetexture and surpfaceprop)

VTFs only

All 4 in one sheet:
174,984 bytes

All 4 seperate:
175,648 bytes (43,912 x 4)

VTFs and VMTs

All 4 in one sheet:
175,077 bytes

All 4 seperate:
176,020 bytes

So, yes there is a saving in filesize but its negligible (~1kb) - also as I'm using small textures, large textures would get less of a benefit as the VMT size would generally stay very small in comparison to the VTF size.

The real kicker is in game and how texture caching works - If it disregards non-visible textures when not needed then you're actually hurting performance by loading up the larger texture sheet to only use part of it. I have a feeling though that textures are all cached permanently for the duration of the map which would make it extremely efficient as only the one texture is cached.

Going to look into this more when I can get back to a PC that will run source games.

The size of my texture files went from 1.3 mb each to 700 kb just by reducing to 256x256, so it had to have done something. However they were HUGE before because I had been working with them in photoshop to get them to tile correctly and kinda forgot to reduce them.

700k is ridiculously huge for a 256x256 texture, it should be about 43k for a plain texture and 84k for one with an alpha channel.

Are you sure you're using the right vtf format and compressing them?

edit: normalmaps will be large, don't compress them.

I use the photshop plugin to save/convert them to the VTF format

Me too (this one). You sure you're using the "compressed texture" (or "compressed texture with alpha") preset?

Even with Generic / 8 Bit Alpha the largest filesize I can get a 256x256 texture to is 342k, that's still less than half your 700k.

edit: compressed 256x256 texture with no alpha is 42.8k, that's ~16x smaller than what you're getting - looks like we found the cause of your filesize bloat

8 bit / 22 Khz WAVs aren't as large as the usual 16 bit / 44.1 Khz ones.
same goes for Mono vs Stereo.

Oo oo......just wanted to get my two cents in too

A few things you might not know about map file size:

1. Large open spaces such as landscape maps or skyboxes that reach up very high will increase bsp size. This is because of the stress put on vis.

2. Lots of env_cubemaps will increase file size once buildcubemaps is run. Cubemaps are not big on their own but it is important to keep numbers as few as necessary. Also, more detailed env_cubemaps (128x128 and 256x256) will rapidly increase bsp file size.

3. Lots of flashing or strobe lights will put stress on rad and increase bsp file size.