4mb texture limit
Muu
Join Date: 2002-01-24 Member: 23Members
Join Date: 2002-01-24 Member: 23Members
<div class="IPBDescription">Question</div>Does any one know what the implications of the 4Meg texture limit are and why its inforced? Im guessing its so people with only 4megs on thier video card can load all the textures into memory - but thats not going to happen because you've got all the model textures and sprites etc so I don't understand why its inforced.
Comments
Maps will be able to be made much MORE immersive if we can up the texture memory limit.
You can increase the limit by using the -texdata argument, but I'm not sure where.
I -think- that this 4MB limit might be something that Relic was doing, and it got read by pretty much everyone (including me) that it was an actual limit set by Flayra.
<!--EDIT|Moleculor|Mar. 21 2002,09:34-->
So if you wanted to, say, set your texture limit to 5 megs, you would use -texdata 5120 in CSG, BSP, VIS, and RAD.
its splits the brush into four pieces per texture repetition, 240 is the max unsplitting texture size.
Edit: I was talking about splitting, not blurriness.
The only texture sizes supported by OpenGL (AFAIK) are the powers-of-two ones (128x128, 256x256 etc). Nothing else.
Half-Life, when it encounters a texture that isn't of this size, rounds it down to the nearest power-of-two size. A 240x240 texture is scaled down to a 128x128 texture - which is why things look blurry.
It's possible to make it scale <b>up</b> - to 256x256 in this case - but things look slightly lumpy due to the poor-quality nearest-neighbour scaling. Do this with <b>gl_round_down 0</b> in your autoexec.cfg or whatever.
<a href="http://www.compsoc.man.ac.uk/~afoster/gl_round_down/" target="_blank">http://www.compsoc.man.ac.uk/~afoster/gl_round_down/</a> - screenshots of the kind of results you'll get. It's like a mini-HD-pack for textures - and works on a load of existing Half-Life ones. <!--emo&:)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'><!--endemo-->
However I tried that command myself and it had no visible effect, even in one of my maps where I used 224x192 wall textures. They still looked as blurry as normal.
It has to be set before any textures are loaded - it's not something that can be dynamically changed. <!--emo&:)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/smile.gif" border="0" valign="absmiddle" alt=':)'><!--endemo-->
For instance, I have the following in <b>valve/hw/matrox.cfg</b>:
<!--c1--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td><b>Code Sample</b> </td></tr><tr><td id="CODE"><!--ec1-->
gl_ztrick 0
gl_polyoffset 0.1
gl_round_down 0
gl_texturemode GL_LINEAR_MIPMAP_LINEAR
gl_max_size 512
<!--c2--></td></tr></table><span id='postcolor'><!--ec2-->
Edit: I was talking about splitting, not blurriness. <!--QuoteEnd--></td></tr></table><span id='postcolor'><!--QuoteEEnd-->
erm, they do, try stretching a 256 texture to exactly fit a face, then check out w_polies and gl_wireframe in half-life (someone back me up here . . .)
for example this site:
<!--QuoteBegin--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td><b>Quote</b> </td></tr><tr><td id="QUOTE"><!--QuoteEBegin-->Does texture size matter? Yes an no...
No it doesn't matter as long as you don't require a perfect fit (walls ground etc.).
Yes it does matter if you require the texture to fit the brush (like crates).
Faces are scaled with texture scale.
Face size = subdivide size (240 max.) * scale.
Brush size / 240 = scale for lowest faces (round up to 2 decimal places (not down!<!--emo&;)--><img src="http://www.natural-selection.org/iB_html/non-cgi/emoticons/wink.gif" border="0" valign="absmiddle" alt=';)'><!--endemo-->).
Now a 256*256*256 brush with a 256*256 texture scaled to x=1, y=1 would have 24 faces. If you were to make a crate like this and wanted to reduce the faces, then you would have to increase the scale to x=1.07, y=1.07 (method above, 256/240=1.066667) and then part of the texture will be missing, so it wouldn't look good.
The same brush with a 240*240 texture scaled to x=1.07, y=1.07 would have 6 faces, and the texture would fit much better. Same as a 16*16 texture scaled to x=1.07, y=1.07, it would have 6 faces and texture would be tiled 15*15 times.
So the best textures to use are:
16*16, 16*48, 16*80, 16*240, 48*48, 48*80, 48*240, 80*240, 240*240
<!--QuoteEnd--></td></tr></table><span id='postcolor'><!--QuoteEEnd--><a href="http://www.planethalflife.com/chaincraft/home/news/news_032001.htm" target="_blank">Proof</a>
there are many other sites that will tell you the same thing, i am sure, but this was the top of my search results.
this is why mofo uses 240 textures instead of 256, to keep r_speeds down . . .
I'm going to think about this a bit more before a give a definitive answer on it. I realize this is the kind of decision that really shouldn't be changed this late in the development, but it's better to make the right decision and not be able to take advantage of it.
Relic, Merks, would it be a lot of work in your nearly-completed maps to take advantage of a texture limit of say, 6.5 megs (leaving 1.5 megs for player models, buildings, particles, HUD artwork, etc)?
I am mucho curious about this, from an architectural standpoint...