Decreasing a texture's scale drastically increases the map's filesize and compiling time. Created 6 years ago2018-07-18 15:46:11 UTC by MOCOLONI

I'm currently working on a map which will contain custom textures. These textures actually appear bigger than I expected, so I halved their scaling. However, I noticed that it also doubles the map's compiling time and its final size is thrice as big.

Rolling every texture to "Scale 1" fixes the problem. In Source, rescaling textures seems not to affect anything, while in GoldSrc it does. Is there any solution to this?

Thanks in advance!

That has to do with lightmap scale, which is tied to texture scale in GoldSource. You'll have to scale the actual textures to avoid that.

Solokiller said:That has to do with lightmap scale, which is tied to texture scale in GoldSource. You'll have to scale the actual textures to avoid that.

The thing is, the textures I'm using/downscaling are actually custom textures. This is what's going on:

The texture(s) at 100% are just too large, and to make them look properly I have to downscale them to ".25", which makes my small map be almost 3MB of size, as well as it taking 13 minutes to complete compiling. I then edited the textures, downscaling them half their size (but I still need to, additionally, downscale their appearance in Hammer, although this time to just ".5") because I can't make them even smaller as they'll appear blurry due to small texture resolution. Although it significantly decreased the final filesize of the map and the compiling time, it's still not a good solution as I need to embed the custom .WAD file, which weighs 330 kB = 1MB of a map.

As far as I know you can force it to chop the lightmaps into bigger slices to avoid this, but i'm not 100% positive. I haven't used it in forever.

If you add the -notexscale 1 parameter to VRAD in your compile settings, texture scale will no longer affect lightmap resolution. This option applies to all brush faces in your map. This also means that the lightmap scale on faces with upscaled textures will be reset to normal as well.

Windawz said:If you add the -notexscale 1 parameter to VRAD in your compile settings, texture scale will no longer affect lightmap resolution. This option applies to all brush faces in your map. This also means that the lightmap scale on faces with upscaled textures will be reset to normal as well.

I shouldn't be asking this because I use Vluzacn's ZHLT modification, but still: is that a command only for non-Valve compilers?

Thanks a bunch for the info! Will check it out and let you know.

as far as I know it was invented with ZHLT compilers.
VHLT is basically a ZHLT upgrade, so yeah, the compilers valve had been using lacked this feature

Windawz said:-notexscale 1

I simply used "-notexscale" (without the Value because it's not necessary, according to the parameters), and although it decreases the compiling time, the filesize remains the same (oversized).

Experimenting with a test map of mine, it turns out that the lightmap scale still won't change. I created 4 large blocks that will shadow the next. They go from scale "1" to ".13" and said shadows are less diffuse. Not sure what exactly the command is for, but it definitely decreases the compiling time.

You could technically use a very low-res texture and use an original-res detail texture. It's a trick used to achieve lower lightmap counts as well as less wpolys, but it may decrease the framerate, only slightly.

Decreasing the texture scale leads to:

• more wpolys (due to more subdivision)
• more lightmaps being used (vanilla GoldSrc can only go up to 64 lightmaps, so be careful)
• bigger filesize

Now, the problem is that detail textures may contribute to the filesize more than the situation you're having, but that's up to experimentation.

Edit: Also, -notexscale doesn't affect the lightmap scale, just the patches IIRC, stuff that has to do with the -chop and -texchop values.

Admer456 said:You could technically use a very low-res texture and use an original-res detail texture. It's a trick used to achieve lower lightmap counts as well as less wpolys, but it may decrease the framerate, only slightly.

Not sure what you refer to with "detail". All I want is downscale a texture that looks large at 100%, but doing so will result in a bigger filesize. The texture is a 128x128 file, and downscaling the file (not the texture in Hammer) to 32x32, which is the way it should actually look like, will make it look blurry/pixelated because it's such a small resolution. The "best" resolution in this case would be 64x64, which still forces me to also downscale the textures in Hammer to ".5", continuing to generate bigger filesizes but half the previous ones.

Admer456 said:You could technically use a very low-res texture and use an original-res detail texture. It's a trick used to achieve lower lightmap counts as well as less wpolys, but it may decrease the framerate, only slightly.

Not sure what you refer to with "detail". All I want is downscale a texture that looks large at 100%, but doing so will result in a bigger filesize. The texture is a 128x128 file, and downscaling the file (not the texture in Hammer) to 32x32, which is the way it should actually look like, will make it look blurry/pixelated because it's such a small resolution. The "best" resolution in this case would be 64x64, which still forces me to also downscale the textures in Hammer to ".5", continuing to generate bigger filesizes but half the previous ones.

I refer to detail textures.
link

Texture scale and lightmap scale are locked together permanently in HL1. It is impossible to change. Your solution is to combine small and big scale textures for less important and more noticeable surfaces accordingly. Although scale of 1 is fine for most occasions if the texture is well made. Always make sure to export textures from Photoshop in 8-bit .bmp rather than .jpg to avoid quality loss.

Bruce said:Texture scale and lightmap scale are locked together permanently in HL1. It is impossible to change. Your solution is to combine small and big scale textures for less important and more noticeable surfaces accordingly. Although scale of 1 is fine for most occasions if the texture is well made. Always make sure to export textures from Photoshop in 8-bit .bmp rather than .jpg to avoid quality loss.

Thanks for the info - I was going to ask about other Hammer applications such as J.A.C.K., because I saw a few samples of it some time ago and it looked like it had some advanced features, and wanted to know whether it supports the modification of lightmap scales.

I use GIMP as the image-manipulating software, and when it comes to creating textures for the GoldSrc engine, I export textures to a 24-bit .BMP image, R8 G8 B8 (the other options are 16 and 32 bits).

The thing is, to use a scale of "1" in Hammer, the custom texture should be decreased from 128x128 to 32x32, which already sounds bizarre. I still did it before posting this thread, though, and it's actually where I noticed the textures being blurry/pixelated, very bad-looking. Currently doing balance by downscaling them to 64x64, and then downscaling to ".5" in Hammer to achieve the smallest-possible filesize while keeping the desired texture quality.