About How To Make Your Map Look Better.
tommy14
Join Date: 2002-11-15 Member: 8839Members
Join Date: 2002-11-15 Member: 8839Members
<div class="IPBDescription">a reveiw really.</div> here are a couple posts about how to make your map level LOOK better.
#1 - texture
while i am sure others can (<b>and hopefully will</b>, i am not artistic) tell you great ways to <i>make</i> textures, here are a few thoughts of mine on texture <u>techicalities</u>:
<b>texture dimensions</b>:
stick to 16, 32, 64, 128, 256 for your edge dimensions. sure, 48 and 96 and other divisible by 16 edge are LEGAL, they are not good. if it is not a "power of 2" dimension >= 16, your texture will go thru things like resampling, aliasing and more and end up a bit blurry, even if you never stretched/scaled the texture.
<i>for example make a texture 48x96, then the engine resamples at 32x64, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching.</i>
so if you want SHARP textures, stick to 16, 32, 64, 128, 256 for your edge dimension.
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 memory.
<b>memory</b>:
The larger the dimensions the more memory required. 256x256 takes 4x the memory of 128x128.
since NS has a memory limit in textures, try to keep the textures on the smaller side for less RAM req.
also 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 <i>second</i> texture. 2 textures in one! you could not use the whole thing on one brush, but you can use each part of the texture on a SEPERATE brush face.....
And both of these textures would look sharp when their part was placed on a brush without resizing, because the edges are "powers of 2"! and yet you would make maximum usage of the memory used. This would not work for tiling textures, of course.
<b>R_speeds</b>
There have been discussions about the 240/224 subdivide on faces to create wpolys, and how using a 224x224 or 240x240 texture scaled up to 256x256 can keep wpolys low with minimal stretching. That is true, a 224x224 or 240x240 size texture scaled up to fit a 256x256 brush will create less wpolys than a 256x256 texture unscaled.
HOWEVER texture quality suffers as mentioned above - the engine resamples at 128x128, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching. You may as well start with a 128x128 texture of good quality - <i>remember 128x128 stays sharp looking</i> - and stretch that to fit 256x256.
then the 128x128 only goes thru one set of deformations, instead of the 2 that a 240x240 texture would.
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 2016.
<b>That is one of the vital things to realize.</b> 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!
<b>More on lag and scaling</b>
There is another matter you should be aware of. On older video cards like Voodoos, scaling down below 1.0 had worse effects for lag than you would expect from the additional wpolys. (example: voodoo3 didn't have hardware transformation and lighting.) <a href='http://home.att.net/~firebinder/halflife/TestC_04.htm' target='_blank'>Firebinder did some research</a> and found that scaling down also affected the patches used by lighting up a level, so that fps (frames per second rate) dropped even when the wpoly count was not changing.
Therefore when using a small brush, it is better to use a small texture and scale up, than to scale down a larger one. Even with the same wpoly count, the down scale might lead to lag on some players with older video cards or who are still using software mode.
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.
<b>Random Textures</b>
many beginning mappers like to use the -0 to -9 randomizing name for auto tiling textures. it seems so easy and efficent. DON'T.
randomizing textures have always been buggy, and seem to get more so. often one player will see proper randomized tiling variations and another will not, but will see all the same texture - due to their different video cards. often mappers get compile errors when they use one of series out of sequence, like the -3 prefixed texture.
the more experienced mappers tend to map every texture themselves, and not leave it to some buggy erratic randomizer which they do not know how it will work for certain.
#1 - texture
while i am sure others can (<b>and hopefully will</b>, i am not artistic) tell you great ways to <i>make</i> textures, here are a few thoughts of mine on texture <u>techicalities</u>:
<b>texture dimensions</b>:
stick to 16, 32, 64, 128, 256 for your edge dimensions. sure, 48 and 96 and other divisible by 16 edge are LEGAL, they are not good. if it is not a "power of 2" dimension >= 16, your texture will go thru things like resampling, aliasing and more and end up a bit blurry, even if you never stretched/scaled the texture.
<i>for example make a texture 48x96, then the engine resamples at 32x64, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching.</i>
so if you want SHARP textures, stick to 16, 32, 64, 128, 256 for your edge dimension.
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 memory.
<b>memory</b>:
The larger the dimensions the more memory required. 256x256 takes 4x the memory of 128x128.
since NS has a memory limit in textures, try to keep the textures on the smaller side for less RAM req.
also 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 <i>second</i> texture. 2 textures in one! you could not use the whole thing on one brush, but you can use each part of the texture on a SEPERATE brush face.....
And both of these textures would look sharp when their part was placed on a brush without resizing, because the edges are "powers of 2"! and yet you would make maximum usage of the memory used. This would not work for tiling textures, of course.
<b>R_speeds</b>
There have been discussions about the 240/224 subdivide on faces to create wpolys, and how using a 224x224 or 240x240 texture scaled up to 256x256 can keep wpolys low with minimal stretching. That is true, a 224x224 or 240x240 size texture scaled up to fit a 256x256 brush will create less wpolys than a 256x256 texture unscaled.
HOWEVER texture quality suffers as mentioned above - the engine resamples at 128x128, aliases and resizes to use. This results in a loss of texture quality, and maybe crosshatching. You may as well start with a 128x128 texture of good quality - <i>remember 128x128 stays sharp looking</i> - and stretch that to fit 256x256.
then the 128x128 only goes thru one set of deformations, instead of the 2 that a 240x240 texture would.
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 2016.
<b>That is one of the vital things to realize.</b> 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!
<b>More on lag and scaling</b>
There is another matter you should be aware of. On older video cards like Voodoos, scaling down below 1.0 had worse effects for lag than you would expect from the additional wpolys. (example: voodoo3 didn't have hardware transformation and lighting.) <a href='http://home.att.net/~firebinder/halflife/TestC_04.htm' target='_blank'>Firebinder did some research</a> and found that scaling down also affected the patches used by lighting up a level, so that fps (frames per second rate) dropped even when the wpoly count was not changing.
Therefore when using a small brush, it is better to use a small texture and scale up, than to scale down a larger one. Even with the same wpoly count, the down scale might lead to lag on some players with older video cards or who are still using software mode.
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.
<b>Random Textures</b>
many beginning mappers like to use the -0 to -9 randomizing name for auto tiling textures. it seems so easy and efficent. DON'T.
randomizing textures have always been buggy, and seem to get more so. often one player will see proper randomized tiling variations and another will not, but will see all the same texture - due to their different video cards. often mappers get compile errors when they use one of series out of sequence, like the -3 prefixed texture.
the more experienced mappers tend to map every texture themselves, and not leave it to some buggy erratic randomizer which they do not know how it will work for certain.
Comments
i will show you a final compile setup that i used, and explain WHY i did what i did. it may give you ideas for improving how your level looks thru compiling.
<b>hlcsg -hullfile c:\sierra\half-life\nstr\nshulls.txt -wadinclude mycustomwad.wad -low -chart mymap.map</b>
remember you need to include <b>hlcsg -hullfile c:\sierra\half-life\nstr\nshulls.txt</b> to EVERY NS compile, because NS uses special hulls.
i used wadinclude so that servers can have my map downloaded without haveing to seperately send the .wad. it makes things easier.
i used the -low because it seems to make for less problems, and i can cruse the web while compiling.
i use -chart to keep track of what limits i am getting near.
<b>hlbsp -maxnodesize 512 -low -chart mymap.map</b>
-maxnodesize 512: since r_speeds are such a trouble to NS, and since large open areas are not workable, i find that smaller leafnodes tend to give smaller r_speeds. HOWEVER, you NEED to also run an earlier set for r_speed checks without this so you can compare if the standard default 1024 leafnode max size gives you better r_speeds.
low and chart i have already explained.
<b>hlvis -full -low -chart mymap.map</b>
-full tends to solve problems, give more accurate r_speeds, help RAD to run later - and THIS rad is gonna need it! regardless, i always VIS -full, even for minor tests incase an r_speed problem comes up.
<b>hlrad -notexscale -sparse -texchop 16 -extra -chop 32 -bounce 4 -coring 0.2 -smooth 80 -full -low -chart mymap.map</b>
here is the meat of the looks improvement.
-notexscale: this seperates the light patch size from the texture scaling so often done to lower r_speeds. usually this means more patches of work for RAD to do, and often a max patches error......
-sparse: this stops the maxpatches error from happening. the final compile WILL be slower though.
-texchop 16: makes the biggest patch for a texture light SOURCE only 16x16. 4 times more light textrue work than the 32x32 default. this will make the texture light look better.
-extra: splits the texture chop in 1/2 again, so that a texture light SOURCE is only 8x8 now - 16 times the default 32x32 RAD work. but it also helps point lights, spotlights, light env and any other light source look better.
-chop 32: every single non light patch can now only be 32x32. this makes lighting from every source more precise, but also make the whole RAD thing take 4 times a long again.
-bounce 4: lets non switchable light bounce around 4 times. minor increase in work for a major increase in looks. if you skip the chop changes, keep this.
-coring 0.2: for switchable lights on/off, makes them look better and aviods the "bullseye" so often seen around a switchable light. instead of cutting of light calc at 1.0, the light calc goes out to 0.2, giving a more shading effect. since ALL lights will stretch further, there is more work, but it doesn't seem that big a time cost.
-smooth 80: for any angle 80 degree or less, phong shading calc goes on. this makes cylinders look rounder, and shadows less jaggy. i don't use 90+, because i like right angles on walls to look as sharp as they can. another big improvement for little time cost.
well, that is the main ones i know of. if you are using the 1.7 extension of zoners are a few specials, like switchable texture lights, but these are the main parameters that make levels look better. i hope they work for you.
I heard that if you want to texture a 256x224 face so that it has the least possible wpolys, instead of applying a 256x224 texture (that causes resampling and gets blurry), you can use a 256x256 texture where only 256x224 of it IS DRAWN. The rest is black. Then, scale it up so that the DRAWN PART of it fits the face. Voilà <!--emo&;)--><img src='http://www.natural-selection.org/forums/html/emoticons/wink.gif' border='0' valign='absmiddle' alt='wink.gif'><!--endemo-->
Correct me if I got that wrong.
I can't comment on the rest of the guide except for the -hullfile thing, I've never heard of that before and never once used it in my compiles. My maps still work, am I missing something?
but a "256x256 texture where only 256x224 of it IS DRAWN" will LOOK better than a 256x224 made texture.
and what difference does one wpoly make anyway? if things are THAT tight, time to rethink the layout......
<!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' valign='absmiddle' alt='sad.gif'><!--endemo-->
<b>Requiem</b> like you said, it is all a matter of taste. if you think a level need less bounce, go with it. i just wanted to remind folks that it was there.
as for the hullfile - i got that off the mapping guidlines here. since it said to use it, i did and never checked if things work without it....maybe things work fine without it?
<!--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--><b>from the mapping guidelines</b>: Because of the various sizes of player models in Natural Selection, CSG requires a new hull file for the collision detection in a map. This is a fairly simply process. Just add the switch "-hullfile c:\sierra\half-life\nstr\nshulls.txt" to CSG's parameters (changing the path to reflect your local path of course). This is necessary so collision detection works properly. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
the hulfile itself is just this:
32 32 72
64 64 108
32 32 36
for humans/fades <!--emo&::asrifle::--><img src='http://www.unknownworlds.com/forums/html/emoticons/asrifle.gif' border='0' valign='absmiddle' alt='asrifle.gif'><!--endemo--> , standing onos <!--emo&::onos::--><img src='http://www.unknownworlds.com/forums/html/emoticons/tiny.gif' border='0' valign='absmiddle' alt='tiny.gif'><!--endemo--> and skulk/gorge/lurk <!--emo&::skulk::--><img src='http://www.unknownworlds.com/forums/html/emoticons/skulk.gif' border='0' valign='absmiddle' alt='skulk.gif'><!--endemo--> respectively.
IIRC, HL does the human size one anyway (default), and the smaller one also anyway because of the HL monsters (& crouched humans) were that size.
so, to really check if you need the special NS hullfile or not, you have to go around your level that has no special hullfile with onos <!--emo&::onos::--><img src='http://www.unknownworlds.com/forums/html/emoticons/tiny.gif' border='0' valign='absmiddle' alt='tiny.gif'><!--endemo--> , and see if they go or fall thru things in your level that onos should not.
it would be interesting to find if it is REALLY needed.....
<b>special textures you can see, their goodness and dangers</b>
regular textures are not special, so they are not getting time.
random tiling textures, the -0 to -9 name prefixed ones i have coverd in #1. reminder - <u>Don't Use them!</u>
<b>animating</b>
the name prefix starts with +0 to +9, with +A reserved also. these are underused in NS so far IMHO, they can add a lot to realism. i have looked at various control panels and they just look like they are painted on, frozen in time. not something that pulls you in with realism.
so for a computer screen with blinky lights, make a series of almost identical textures, with different lights blinking in each one. you must start with +0 and work up without skipping - but you do not have to go all the way to +9. a series of 3 is ok, like this example:
+0bobscpu
+1bobscpu
+2bobscpu
animated textures can also be used for flashing monitors - i think HERA map had one such - and also for moving machinery "behind a safety screen" look. i have seen it in other mods used for multiple ripples in water from drops in a puddle.
the +A is used for a STOP motion texture. you HAVE to make the brush it is on an entity to use it, because it needs a name. so with the example above, if you wanted to be able to turn bobs cpu off with a switch, you would have to make the cpu a func wall, then have the switch target the name of the func wall. the textures would then switch from the +0 to +2 sequence to +Abobscpu which would show the cpu with no lights at all.
<u>dangers of animated texture</u>
animation does cause some small cpu load. too many different animated textures in a high combat zone may cause lag. simply too much of a good thing, so use moderately.
also problems in compile have been know to happen if you try to texture with one from the middle of a series: using only the +2prefix one for example. and you MUST start with +0 and go in sequence if you make it.
<b>lighting textures</b>
they always look better than mysterious source light entitys. but too long to cover here, especially with the new switchable texture lights from zoners/merles 1.7 compilers. check them out!
<u>possible problems</u>
too many different light types (8) shining on any brush cause compile crash. bsp Memory used is the square of the number of lights on a brush face, 4 light types = 16 times the memory usage of 1 light type on a brush face - for EACH brush. But 8 *identical* lights do not cause a problem.
<b>Masked/Transparent </b>
good for ladders, screens/grids/gratings, NS maps so far make excellent use of them. follow their lead.
remember though that you only have a limited # of entitys, and also that every entity brush has wpolys.
<b>Liquid/Water </b>
good stuff, when well used. 4 ways to use:
<ul>
<li>! prefix named brush left regular - no entitys cost, but no underwater haze either. best for puddles and other shallow pools players will not go under. regular wpoly for r_speed management.
<li>func water with or without ! prefix. good for waves, good for underwater haze. not counted as wpolys, but DOES give lag, sometimes major fps lag if there is too much. sometimes the engine renders it in the maps even when not visible, which may cause a hidden lag unless you watch for it.
also usable are slime and lava mode for instant poison & burning death on touch.
remember, func water is really a sliding DOOR, so you can make it go up and down like a flood or fountain....or have a wedge of it flood across a room.
<li>func illusionary with the added key of skin -3 can also be water. acts like wpolys, so it can be vis blocked. but no underwater haze that i have been able to do.
<li>this is buggy, but you can make a func train with SKIN -3 like an illusionary for water. the main reason to do so is for special movement effects. treated like a train for lag/r_speed purposes. like i said, it is buggy.
</ul>
related to water is the <b>Contents_Current</b> textures. these give a fast push while you are in the water. they are:
!cur_90, !cur_0, !cur_270, !cur_180, !cur_up, or !cur_dwn and give their push in the direction of their names.
<i>these are special reserved names, use them exactly like that in your custom wad naming. and you can have only one of each.</i>
<b>scroll</b>
i have always found scroll buggy. but when it works it is ok. good for marquees, for waterfalls, for rain/drips/snow, for water currents. must work with conveyor, but conveyors do not have to be solid.
<b>sky</b>
not much used in NS, sky gives a nice background to the outdoors with windows. it works with the 6 tga files, named in map properties. light from the sky is give off according to light env entity, but only if ALL sides of a sky brush are sky.
INSIDE a level a sky brush is just an invisible solid block without a wpoly like CLIP, but it does add a little fps lag.
<b>translucent</b>
a special, rarely used brush. good for solid looking curtains. it is not solid, but not an entity. starts with the prefix @.
<u>problems</u>
must be very thin, or may lead to hall-of-mirrors problems, somewhat experimental and TRANSLUCENT may not work with all mods....you know, i have't actually test it with NS yet. gotta do that. probably will work.
i hope this review is also of use to some.
What it does, is it makes lighting from texture lights much sharper. Using this, and using only 1 bounce, can make lighting much crisper and better looking.
If you do decide to use -dscale 1 you'll need to increase the intensity of your texture lights significantly (as there won't be that second light calculation), and bounce 1 will probably require increases in light/light_spot intensities as well.
At any rate, I've found it to be beneficial.
Other than this, our compile params are mostly similar, though I stick in -estimate because I like to know more specifically when my compile will be done. <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' valign='absmiddle' alt='wink.gif'><!--endemo-->
Oh well, at least I have my bookmark ready <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->.
Hm... @ textures? Funny, I've never heard of that. I'll have to check it out. How exactly does it work? Does it work like the Additive setting, or the Texture one? I'd imagine it's rendered fullbright, but then again, I've never heard of it.
So many thing about textures.. so many things about compile parameters.
Jeez.. i miss the good ol' days of HLDM mapping.
Make map
Texture map
Put weapons
Full Compile
Release!
Was so easy back then..
Hell im STILL doing it this way for my NS map and everything is still good.
<!--emo&::asrifle::--><img src='http://www.unknownworlds.com/forums/html/emoticons/asrifle.gif' border='0' valign='absmiddle' alt='asrifle.gif'><!--endemo-->
Anyhow...*bump*
stick to 2, 4, 8, 16, 32, 64, 128, 256 for your edge dimensions. sure, 48 and 96 and other divisible by 16 edge are LEGAL, they are not good.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
However, in a case where a texture has a 3 pixel repeating pattern, then because 'The larger the dimensions the more memory required', 48 is pretty much your only choice.
However, if you are making textures with 3-pixel-wide patterns, then you need a slap upside the head anyhow. Nice topic tommy. Its getting pinned.
you make a texture of solid colors, NOT see-thru blue or black. maybe a curtain. you name it @name.
then in the map you make a very thin brush of it. that is all, NO ENTITY, so no additive, no texture mode. then when you play you can WALK THRU IT like an illusionary, but it is opaque like a wall brush - you cannot see thru it and it stops light. best of all, AFAIK the @ translucent brush is a VIS BLOCKER too, unlike something like a door or an illusionary. and it is lit like any other regular brush.
sounds neat and it is, when it works for the mod. the problem is what are you gonna use it for? about all it is good for is a secret passage, or a curtain.....
<!--QuoteBegin--Merkaba+Jan 11 2003, 10:27 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Merkaba @ Jan 11 2003, 10:27 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
Oh, and I just found this out. Lowering your -maxnodesize setting in HLBSP also lowers your CLIPNODE limit, so be careful (I just tried compiling Hera with that option and it gave me a clipnode error) .<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
yes that can happen. it is not that your clipnode limit is lowered, but that the smaller maxnodesize is chopping up your map level into smaller leafnodes "pieces" = possibly more clipnodes. your patches and even total wpoly might also go up - but your r_speeds MAY go down in some trouble areas in corridors, & corners. or the r_speeds may go UP. those are some of the reasons i stongly urged folks to test their level first without changing the maxnodesize.
<i>whee! i got pinned!</i>
i use it for creating clip planes and shuch forth, mainly because IT DOSNT ADD TO WPLOY, whereas the CLIP brush does.
great for those func_illusuary railings <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'><!--endemo-->
The way the NULL texture works is simply to remove the textured face from the .bsp, AFTER the clipnodes have been calculated. That's all. It's especially useful on the sides of entity brushes - those faces which the player will never see, but will be drawn when facing him. There are many other uses too, but I can't list them right now.