R_speeds (again)
Kalopsia
Join Date: 2003-05-15 Member: 16331Members, Reinforced - Shadow
Join Date: 2003-05-15 Member: 16331Members, Reinforced - Shadow
Ok well i think i know most of the basics for keepiung em down but heres another question:
<span style='color:red'>Q. Do R_Speeds only apply to what the player can see, or do they make up the entire map, meaning in your whole level you can really go over 800 poly or does that apply to each room ?
A. ?</span>
<span style='color:red'>Q. Do R_Speeds only apply to what the player can see, or do they make up the entire map, meaning in your whole level you can really go over 800 poly or does that apply to each room ?
A. ?</span>
Comments
A common solution to intersecting world brushes is to use vertex editing or if possible simply resize the objetct or move it away so that it is one unit away from the wall/floor/etc, applying the NULL texture to the side one unit of the wall/floor/etc not visible to the player. Crates can be placed one unit of the floor and their under side textured with NULL to avoid splitting. entities generally do not split up surfaces, a crate made of a func_wall will not split a floor even when standing on it but the compile tools will treat it as non-visible during VIS(thus making a wall a func_wall will allow the engine to think that you see whats on the other side, thus increasing r_speeds). Non visible surfaces of entities like func_walls should generally be textured with NULL so the engine doesn't think it has to draw them.
high detail areas are usually shielded of pretty well, look at the eclipse hive for example, when inside the hive you are prevented from seeing anything outside by a big pillar type wall on one side and a short bent corridor on the other.
edit: If you like you can take some screenies with gl_wireframe 2 and let me/others willing take a look and see if we can suggest something.
<img src='http://www.members.optusnet.com.au/nambucca/r_speeds2.JPG' border='0' alt='user posted image'>
<img src='http://www.members.optusnet.com.au/nambucca/r_speeds2.JPG' border='0' alt='user posted image'><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
All of those wireframe lines are showing faces that contribute to r_speeds, which tell you how many polygons the engine is drawing. Only polygons that are being drawn during that frame count, but most of the time the engine draws faces that aren't actually visible to the player... this is due to the way that the Half-Life engine determines visibility--if you're up for some technical reading, Michael Abrash, the co-author of the Quake engine, has written a series of <a href='http://www.gamedev.net/reference/articles/abrash/abrash.pdf' target='_blank'>articles</a> on how the engine works. The first article describes visibility matricies and how the engine determines what to draw.
If you're not up for the read, just know that running VIS -full should store information in the map telling the engine to skip drawing the rooms below that vent, and should lower your r_speeds at that point.
<a href='http://countermap.counter-strike.net/Tutorials/tutorial.php?id=2' target='_blank'>http://countermap.counter-strike.net/Tutor...torial.php?id=2</a>
i use a couple of those hint brushes but not sure if i still used em right, i used em where i thought they were right.
yes
<img src='http://www.members.optusnet.com.au/nambucca/hint1.JPG' border='0' alt='user posted image'>
<img src='http://www.members.optusnet.com.au/nambucca/hint2.JPG' border='0' alt='user posted image'>
otherwise you just get more leafes, faces and w_poly.
hint brushes split up all faces they touch causing more w_poly!!!
Placing hint brushes in doors is no bad thing but rarely needed.
It rarely improves w_poly (most ti mes increases), sometimes lessens the leaf count.
When you look straught trough a hint brush it does nothing!!!
<b>Best usage of hint brushes is in L-shaped corridors/vents in the turn (45°) to make it impossible to look around turns.</b>
<!--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-->NULL is your friend<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
SKIP works, too.
Also i have ran my map in full vis and r_speeds have gone down but some places still high, does this require the hint texture nearby to stop VIS from drawing it ?
SPECIAL TEXTURES:
Name: NULL
Function: Whatever is textured with NULL is removed from the visible faces in the bsp during compile. A
face with NULL on it will <b>not</b> contribute to wpolys or r_speeds, which is nice.
Location: ns.wad
Name: HINT
Function: In short, it splits vis leafs along the plane the texture is on, in areas where too many out-of-sight
wpolys are being rendered and thus making r_speeds too high.
Location: ns.wad
More Info: <a href='http://collective.valve-erc.com/index.php?doc=1043477348-95410300' target='_blank'>Click for more info</a>
Name: SKIP
Function: [edit] This only has a use for texturing the sides of a HINT brush that you don't want to break up
vis leafs with. The sides with SKIP are completely ignored by the compiler. [/edit]
Location: ns.wad
Name: CLIP
Function: An invisible texture that simply creates a collision hull. Skulks can only climb on world brushes and
wall entities, btw, but <b>not</b> plain clipnodes or the SKY texture. Bullets also pass through CLIP, too.
Location: halflife.wad
More Info: <a href='http://www.vlatitude.com/tutorials.php?tutID=25' target='_blank'>Click for more info</a>
Name: SKY
Function: This face doesn't really appear, and may or may not generate a collision hull (depends on your
compile tools) but renders a skybox wherever the texture is. Generally a brush should have all of its faces
covered with SKY.
Location: halflife.wad
Name: NOBUILD
Function: An NS-specific texture, this creates a surface that can't be built on. Duh.
Location: ns.wad. Duh.
Name: ORIGIN
Function: This is used for some rotating entities. Use this to texture a brush that indicates the point around
which the entity will rotate. ORIGIN is invisible after the map is compiled.
Location: halflife.wad
<a href='http://collective.valve-erc.com/index.php?go=rotating_objects' target='_blank'>Click for more info</a>
Name: AAATRIGGER
Function: I'm not sure about what this does specifically, but generally it should only be used for texturing invisible brush entities.
Location: halflife.wad
I was filled with a desire to write them all down. I am insane. If anyone has any additional info, I'll edit this post.
Question: With the hint texture, is it possible to put it in gaps between to rooms or something, that way it stops r_speeds affecting where ur looking.
Ok the trick about VIS is that your whole maps volume gets split up into "leaves" (volume parts just like brushes).
Leafes have "portals" on their borders that connect neigbour leafes to each other or show a wall with its texture. (leaves are stored in a bynary data tree, thats why its called leaf)
Now VIS checks what leaf is visible from what other leaf creating a vis matrix that shows if you can see leaf 1945 from leaf 6792 or not.
Now ingame when you stand in one leaf its like you stand in ANY position of this volume piece looking in your 180° field of view.
black = leafes and its portals/borders.
red dot = player position.
blue dot = leafes can "see" from here, imagine you stand there, too.
blue lines = imaginative lines of leafes sight.
green = visible leafes from your leaf/position. you see all players and textures in there when its in your 180° field of view.
purple = hint brush face splitting leafes.
When you stand in a long straight hallway, that is one leaf for example, its like you are standing at each place of this hallway at once seeing into multiple rooms like you look around corners. (upper left pic)
Lower left pic shows how it seems that you look around 3 corners but the leaf you are standing in can see that other room and so can you.
The right pics show the best usage of hint brushes in general in the upper pic, without hint brush, you can see around the corner.
In the lower, with a hint brush in 45° angle, you cant.
now hint brushes split texture faces causing more w_poly in general.
They also increase the leaf count what makes your map more complex, bigger, longer to compile and even laggyer... but you wont notice that.
Yes, but if you try to use it with something other than HINT you'll get a mixed brush content error.
SKIP is actually ignored during hull processing and doesn't contribute to any hull (hence the name). When NULL is used in a hint brush, it behaves almost same way--the brush content type is set to CONTENTS_HINT by the HINT texture and NULL doesn't change it back; as a result the NULL faces aren't compiled into the clip hull. They are, however, still considered cutting planes for the vis hull, resulting in cuts that SKIP wouldn't make.
The two textures are both usable for hint brushes, but I prefer using SKIP so I know at a glance that those faces aren't going to contribute to the hulls. It's also slightly cleaner to use SKIP since NULL still cuts the vis hull along the plane of its face when used with HINT brushes.
I have a small question. This technique was mentioned in another thread: Using the NULL texture on every face that the player can't see (I.E the walls on the outside of the map or the backsides of large, wall-adjacent brushes), This usually entails texturing the entire map in NULL and only texturing the inside of the map.
Does this actually work? Will it lower r_speeds significantly, or is it not worth the effort?
I have a small question. This technique was mentioned in another thread: Using the NULL texture on every face that the player can't see (I.E the walls on the outside of the map or the backsides of large, wall-adjacent brushes), This usually entails texturing the entire map in NULL and only texturing the inside of the map.
Does this actually work? Will it lower r_speeds significantly, or is it not worth the effort? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Using NULL on the faces that are "outside" of your level is redundant because BSP already removes the outer shell of your level when it processes. NULL face removal actually takes place after the removal of the outer leaves, so any NULL textures on the outer walls don't make it to the NULL processing step (edit: or NULL ignoring step, to be more accurate) anyway. IMO, it's not worth the effort of carefully texturing the interior surfaces a face at a time.
The only time it would have a significant impact on r_speeds would be when the level has a leak and the outer shell isn't being removed -- but when that's the case, other extra information like excess leaf and node information isn't being removed, either. It's far better to fix the leak than to NULL the outside of your level.
There may be a slight difference in your level's r_speeds you see if you're not good about finding places to use NULL -- it may be easier for some people to "turn on" NULLed faces than to work in the other direction; I'd expect the impact to be minimal if you know how to use NULL properly on the inside of your level and are actively looking for opportunities to optimize your level.
I've found two places to use NULLs to slightly (but significantly) decrease wpolys and r_speeds. One is on the backside of brushes that are <i>in the map</i> but you never see that side or can't get behind the brush (say, on the back of a round pipe placed a few units away from a wall.) The other is on solid brush entities, on the sides that are flush with or inside the walls (these sides are still visible a lot of the time, because brush entities don't integrate into the level geometry or get culled.) This can really help if you use a lot of func_walls or somesuch to prevent funny shapes from breaking up your faces too much.