About How To Make Your Map Look Better.

tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
edited April 2003 in Mapping Forum
<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

Comments

  • tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
    edited December 2002
    #2 compiling tricks to make your map look better:

    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.
  • BiTMAPBiTMAP Join Date: 2002-11-08 Member: 7685Members
    wow thanks for that!
  • marcosmarcos Join Date: 2002-06-26 Member: 825Members
    edited December 2002
    great Tommy14! thx for sharing your little "secrets" with us <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->
  • chubbystevechubbysteve Join Date: 2002-10-14 Member: 1496Members, Constellation
    If there is a revised mapping guide (definitely a priority for the NS team IMO) some of this should go through to it.
  • PrivatePanicPrivatePanic Join Date: 2002-11-03 Member: 6546Members
    About the R_Speeds:

    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.
  • Lord_RequiemLord_Requiem Join Date: 2002-11-20 Member: 9481Members
    Its all a matter of taste. I used -bounce 4 on a compile last week and my map came out TERRIBLE, it totally screws up the shadows so you don't have almost any harsh shadows for skulks to hide in. It might make CS and DoD maps look better, but NS needs those harsh, dangerous shadows.

    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?
  • tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
    <b>PrivatePanic</b> - right and wrong. a 256x224 brush will make 2 wpolys if you do not scale up the texture. does not matter what texture size you use, or how much of it - wpolys are made at the 240(224 for tiling) division times the scale. If you want less wpolys, then you have to make the texture on 128x128 background and stretch it up. but then you lose some looks.

    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.....
  • tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
    #3

    <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.
  • MuntyMunty Join Date: 2002-11-01 Member: 2972Members, Constellation
    About the HL hullfile: When a maps been compiled with this hull file you wont fall through anything as an onos... but i have been able to jump through the roof and into the void as an onos... <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' valign='absmiddle' alt='confused.gif'><!--endemo-->
  • marcosmarcos Join Date: 2002-06-26 Member: 825Members
    do u use the orginal compiling tools, not zooners?
  • MuntyMunty Join Date: 2002-11-01 Member: 2972Members, Constellation
    Im using zoners...
  • marcosmarcos Join Date: 2002-06-26 Member: 825Members
    sry, my Q was for tommy <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->
  • BobTheDogBobTheDog Join Date: 2002-11-17 Member: 9065Members
    this should be pinned! nice infos <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'><!--endemo-->
  • HanzGruberHanzGruber Join Date: 2002-01-25 Member: 47Members
    Use the modified zoners tools that are included with ns....very very important...because they included the null textured brush stripping <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'><!--endemo-->
  • KungFuSquirrelKungFuSquirrel Basher of Muttons Join Date: 2002-01-26 Member: 103Members, NS1 Playtester, Contributor
    The null texture and all the other supposed NS-specific features have been included as part of Merl's custom ZHLT as long as they've been included with NS and the NSTR. Use the current ones, there's rarely any reason not to.
  • GreedoGreedo Bounty Hunter Join Date: 2002-01-24 Member: 37Members, NS1 Playtester, Contributor
    It might be a good time to bring this up, which was originally brought to my attention by Wolv, I believe. Something I've been using in my rad compile parameters for my map since I started making my map (and it might not be a good idea to change, as there may be a lot of required tweaking) is sticking in -dscale 1 What this does, and I'm most likely mistaken, is only calculate texture lighting once, instead of the default (and depending on your views, incorrect) double calculation. I'm sure someone could explain that better than I can, but I can't really say I care how it works.

    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-->
  • tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
    anyone have anything new to add to this?
  • Lord_RequiemLord_Requiem Join Date: 2002-11-20 Member: 9481Members
    Thank god you resurrected this one, I been looking for it all week. I saved it to my hard disk for future rad compile questions about quality. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->
  • FantasmoFantasmo Join Date: 2002-11-06 Member: 7369Members
    Could someone pin this? Great tips Tommy.
  • VyvnVyvn Join Date: 2002-08-24 Member: 1226Members
    *stabs with imaginary pin*

    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.
  • FatboyTimFatboyTim Join Date: 2002-11-13 Member: 8538Members
    Thanks tommy14! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->
  • BlackPantherBlackPanther Join Date: 2002-02-11 Member: 197Members
    OH god.. this is getting complicated.
    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-->
  • MerkabaMerkaba Digital Harmony Join Date: 2002-01-24 Member: 22Members, Retired Developer, NS1 Playtester
    Yeah, its not neccessary to do any of this stuff - but the topic does state that this is about how to make your map look <i>better</i>. It depends on how much you want to squeeze the engine's capabilities <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo--> I wouldn't personally reccomend this topic to people who are just starting up mapping, unless they can easily grasp what on earth tommy's talking about (this kinda depth of mapping discussion is always confusing if you have no idea how everything works).

    Anyhow...*bump*
  • MerkabaMerkaba Digital Harmony Join Date: 2002-01-24 Member: 22Members, Retired Developer, NS1 Playtester
    Oh, and I just found this out. Lowering your <b>-maxnodesize</b> 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).
  • FamFam Diaper-Wearing Dog On A Ball Join Date: 2002-02-17 Member: 222Members, NS1 Playtester, Contributor
    <!--QuoteBegin--tommy14+Dec 15 2002, 02:09 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (tommy14 @ Dec 15 2002, 02:09 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><b>texture dimensions</b>:
    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.
  • tommy14tommy14 Join Date: 2002-11-15 Member: 8839Members
    edited January 2003
    <!--QuoteBegin--Vyvn+Jan 9 2003, 01:01 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Vyvn @ Jan 9 2003, 01:01 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->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.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
    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>
  • quazilinquazilin Join Date: 2002-11-25 Member: 9880Members, Contributor, NS2 Playtester, Squad Five Blue
    Useful stuff and easy to understand when you write it tommy =)
  • PodPod Join Date: 2002-11-03 Member: 5745Members
    tommy : how about telling people on the use of the NULL brush.
    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-->
  • MerkabaMerkaba Digital Harmony Join Date: 2002-01-24 Member: 22Members, Retired Developer, NS1 Playtester
    Have any proof at all that the CLIP brush generates wpolys? I think you're wrong. Also, CLIP brushes do not block VIS whereas the NULL texture does (assuming you have the very latest version. There was a bug in a recent ZHLT release where if a brush was fully coated with the NULL texture, then that brush would become non-solid and wouldn't block VIS).

    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.
  • JasonBostwickJasonBostwick Blossom Join Date: 2002-04-14 Member: 444Members, NS1 Playtester
    That Fam and his 3 pixel repeating patterns...
Sign In or Register to comment.