|General Rule of Thumb: Use (or make) a texture smaller than the brush (or the same size) and scale the texture upwards to fit. Use only textures with these edge dimentions: 16, 32, 64, 128, 256.|
(Note 1: #s 2, 4, 8 cannot be used because they are smaller than 16.
I just gave them to show the series.)
(Note 2: #512 can be used, but it should only be used with one of the others, not in a 512x512 format - unless you are prepared to lose some players. Anyone in software mode or with a poor video card will not be able to render 512x512 textures. See Taylor's note below.)
The reason these sizes are preferred, is that the rendering engine does not change them, so they stay sharp. If you have a between size (base 16 size), for example 48x96, then the engine resamples at 32x64, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching. So while other sizes are legal, "the powers of 2" are the best to use.
(NOTE: With gl_round_down 0 somewhere in your autoexec.cfg, config.cfg or similar, the engine rounds up sometimes. Nearest-neighbour sampling, so kind of lumpy, but much better than the blurry textures. However, the engine is still resampling, which it does NOT do with "the powers of 2" sized textures! Furthermore, not everyone who plays your map will have that setting, or even open gl..)
What if you have a between size brush? You resize the ideal textured
dimension, that is what. After all that is what the engine will do
anyways....you must make a choice then: to make an oversized "powers of 2"
texture which when shrunk looks good an sharp, or a smaller "powers of 2"
texture which when scaled up/stretched looks good an sharp - AND uses less
Lets take a look at that next, and also later at the lag and scaling section under r_speeds.
|Originally by Taylor |
512x512 textures are bad, so bad I'll write bad in uppercase with bold and italics. BAD
Software mode and older graphics cards (such as the Voodoo 3) do not like a texture with a lump size of over 65536. You work out the lump size by the simple equation x*y, examples are:
If Half-Life or OpenGL (depends on the drivers what happens) doesn't like the Texture Lump, it'll:
So to recap, 512*512 = BAD, you can have 512x128 textures and other simular combinations of sizes, as long as the lump size is under 65536, which can be worked out by x*y.
Besides using a smaller texture there are other ways to save memory. One is
to use 2 textures in one. If you need a 48x96 texture to fit a planned brush,
put it on a 64x128, and only use part of the space. in the remainder 16x128 side
or the or 64x32 space you could place another texture. Then both of these
textures would look sharp when their part was placed on a brush without
resizing, and yet you would make maximum usage of the memory used. This would
not work for tiling textures, of course.
Anyway, it takes a really big map with a lot of details to go over this texture memory load limit, for most maps do not worry about it!
If you are facing the problem of minimizing wpolys in a wide open area,
stretching/scaling 9x is about the limit of the engine, more causes problems and
errors. If you stretch a 256x256 texture 9x then the 224 subdivide will also be
stretched 9x = a wpoly of 2016x2016. That is about the maximum wpoly you can
have - regardless of what texture size you use. 9x (224x224) = 2016x2016, 9x
(128x128) = 2016x2016, 9x (16x16) = 2016x2016 subdivide/wpoly size. The only
difference is how many times the smaller textures will tile within that
That is one of the vital things to realize. Texture sizes do not control the subdivide per se. A 16x16 will not make wpolys 16x16 if it is not stretched. Instead it will make the wpoly at the brush size or 224, whichever is smaller. It is texture stretching which stretches (or shrinks) the subdivide - not the texture size!
|note: to get the full effect of the 2016x2016 on the ground,
you will also have to increase the maxnodesize in BSP compile from the
default 1024 to 2048. HLBSP -maxnodesize 2048 is the command you
need. However, be aware that changing the maxnodesize for leafnodes on ALL
maps is NOT a good thing. On smaller maps, or maps with lots of corridors
and no large open space it may INCREASE your r_speeds and lag, because the
leafnodes will "see" more wpolys. For such maps DECREASING maxnodesize
from 1024 down to 512 can reduce wpolys, sometimes. One needs to
experiment to find the best mode - but all this is for compile experts.
Finally, the maxnodesize does not really affect walls much, so if you are
building a skyscraper you can pretty much ignore it.
note2: the subdivide CAN be changed up from 240 to say 256. This will allow 1 wpoly for a 256x256 texture on a 256x256 brush face. The problem is that software video mode does NOT allow subdivide to be changed, so NO software video mode user can play your level. Also you cannot decrease subdivide below 240. Finally some compilers do not allow subdivide to be changed, and you will get a "bad surface extents" error during compile. But if you want to experiment, HLBSP -subdivide 256 is the command you need.
example of using the texture tool for scaling
Note the 1.5 scaling, and the 128x128 texture size.|
However, there is another way to deal with the problem besides only scaling
up textures: HLRAD -notexscale. This stops the compiler from basing the
patch sizes on the texture scale. But this -notexscale usually increases
the number of patches in a map, as most maps have many walls scaled up 2x or 3x
or even 9x to reduce r_speeds - as described above. So if you are shrinking
textures/scaling down and having patches problems/lag in an area with an older
video card/software mode, then experiment with -notextscale - but do not use it
automaticly all the time.
Furthermore do not forget HLRAD -sparse can also help with too many patches, even if the compile will be slower.
BTW: You might think of shrinking textures down on purpose for more patches
on a textures, hoping for better lighting. There are better ways to control
HLRAD -texchop # and HLRAD -extra to control texture "light giving" patches sizes, (default TEXCHOP is 32x32 x texture scale, unless -notextscale is on, and default EXTRA is 1/2 texchop/16x16 respectively. But EXTRA may do more than just 1/2 the texchop!);
and HLRAD -chop # to control the size of general "lighted on" patches. (64x64 x texture scale is the CHOP default, unless -notextscale is on, in which case default is 64x64 only.) FYI: Chop larger than 96 generally looks poor.
The combination of HLRAD -notexscale -sparse -texchop 16 -extra -chop 32 can be especially handy for lighting a level extra fine, but will be a slow compile due to the many, many extra patches.
FYI: Why is the max subdivide size 240?Originally by Rhett on the ERC forums.
Why is the max subdivide size 240, and not 256? Well, there is a very
good reason for this.
(That 8 pixel border is problably also the reason why 16 is the minimum texture border size.)
FYI: Why tiling makes wpolys occur at (224 x texture scale) instead of (240 x texture scale)?Originally by Merl on the ERC forums.
From the code in the zhlt source the formulae for subdivisions basically boils down to the following line of code:
that is, basically, the subdivide size minus 16. Do the math on 240 - 16, and you get 224.
(Zoner is also reported to have said that too many 240x240 wpolys may cause some wpolys to not appear, later in that same thread.)
FYI: Can the max subdivide size be changed?
From Merle in version 1.7 of his compile tools: Increased maximum subdivide value in hlbsp to 512. You may now specify a value using the -subdivide parameter other than 240. WARNING: Doing so may cause problems in software mode. If in doubt, leave at the failsafe default value of 240.
(So if you intend for any player who ever uses software mode to be able play your map, do not change the subdivide!)