Details, Borders, and cutting brushes. Created 12 years ago2012-03-06 01:46:53 UTC by camplo

I want to add things like a side walk, borders on walk ways, windows...etc etc
Is it really better for me to cut up my ground brush and wall brushes to add these things or would I benefit from using more brushes of func_detail, func_wall, and func_illusionary. The goal is to keep w_poly at its lowest.

Well I just did my own test and came to the conclusion that as long as the faces not showing have null on them that do not affect w_poly, I made a small world 256x256, a floor with a sky box. The variable was identical to the first with the exception that the floor was cut into 8 blocks with only the face, facing the world textured while all other faces where null. Both maps had a w_poly of 1.

Ok heres my guess...... The compilers can merge faces...but not brushes. So lets say you have a solid square made out of 2 smaller square brushes. The compilers can merge all faces as long as they are on the same plane?...thus it would big the same w_poly as if it where only one brush....

Ok heres where I am at... My w_poly has way more to the with surface area of rendered texture than the amount of brushes and or cuts, cutting, faces, bla bla bla.

Goldsource, dude.

It literally doesn't matter. Nobody has a PC that gives a shit if a HL map isn't perfectly optimised anymore.

Seriously, you're using a 14 year old engine which is itself based on a 16 year old engine.

Just cause its old doesn't mean I don't want to understand how it works, dude, not to mention its the engine for the most popular fps ever..

Not too mention are you guys even mapping for multiplayer? W_poly and map design is very important and can be the difference between a map that can be played when the server is full and not lag like crazy and map that causes people to frickin time out. It, makes, a, difference.

It really doesn't. We have broadband now, y'see.

It's cool that you want to understand how it works, but it'll have no impact on the end-user.

Also, you'd really need a more complex test for w_polys. What you did is like comparing the taste of two different single grains of sugar.

Hey again, I thought I'd chip in because I dont agree with Archie (sorry mate :))

The way the Half Life engine splits brushes is due to textures and being 'carved' by other brushes. Load a map and type in the console 'gl_wireframe 2'. This will show you how the game splits up based on textures. This is the reason why scaling textures to 2, 3 or more is a really good way to lower w_polies and r_speeds.
Here is a screenshot of a 128x128 texture on a 256x256 brush. The textures are scaled (from left to right) 1, 0.5, 0.25 and 0.1:If the texture is rotated at an angle, that will change the direction of the 'splitting' of the brush.

The second method of splitting brushes is the one that you are asking about here - putting a brush on top of another brush (like a cube crate on top of the floor) causes the floor brush to be split and this is pretty much the worst thing you can do when mapping for half life.

When two brushes touch each other then it acts as if you have used the carve tool. Anyone who has mapped for half life and used the carve function with a cylinder will pretty much know how bad that is.

Apart from splitting the brush (which is bad enough, and when you have rotated brushes 'carving' into each other then its bad news) it also splits the clipping of the game. If you have ever been stuck on a brush, this is why. You can use the Hint and Clip textures to cover detailed areas and eliminate this, but its till covering up a problem that you shouldnt have caused in the first place.

Also, splitting brushes means that more faces are created. each individual face is calculated for lighting. This is why compile times are longer for maps that have used the carve tool inappropriately. Calculating light is one of the main things that add to compile times and is incredibly easy to fix.

So, to avoid these problems there are a few solutions. The easiest is to tie a crate to a func_wall. This means that the crate is no longer carving into the floor. However there is an entity limit (512) that can be displayed on the screen at any one time. This includes enemies, models and sprites such as muzzle flashes, so you really want to lower the entity count in larger maps or areas. You can tie a lot of brushes together as one func_wall, and this is especially useful for brushes that are close together. I use it a lot for things such as wooden beams:Another workaround is to place the brush 1 unit (the smallest you can make the grid in Hammer) away from other brushes, so it is essentially hovering in mid air. This optical illusion is good for crates because the player can never see that the crate isnt touching the floor when done in a place such as a corridor where you can't view the crate at odd angles and heights.

You can't tell in game, such as on this container here:This method I prefer where possible, but it just doesnt work in a lot of places - such as when a crate is against a wall that the player can walk past - it will become obvious the crate isnt flush against the wall and you can see the back face of the crate (and as you should texture all unseen faces with the null texture will add more faces you need to texture)

Also if you have crates piled on top of each other, the top crates will be obviously floating at head height so cant be used there.

Using func_walls is a great way to lower r_speeds and this allows you to put much more detail into your map.

Wow cool writeup dude! Submit this as a tutorial!

Would be cool if you could do one for source as well =) Also, those screens look nice what are they fromski?

OK, thanks for the informative post. Lotta good stuff in there but nothing pointing to the fact of whether or not the splitting of faces increases w_poly significantly. You know I had a map that was fairly open and unhint brushed. At first my ground texture was scaled to 2, but I later tried the texture at a scaling of 1 to find out.... I only gained like 80-50 w_poly, which ain't worth a pinch of salt so I of course went with the higher resolution, better looking, ground texture scaled to 1. I think right now at this point in my understanding level, my argument is that the amount of textured surface area being drawn is the deciding factor in whether or not an area has "too much" w_poly or not. So in this war the null texture is the first hero since its gets rid of a huge amount of unseen surface area and the 2nd hero would be keenly placed hint and skip brushes which as well remove large amounts of unseen textured surface area AND in the case of multiplayer, stops the drawing of players who should not be seen.

I just noticed that you were actually trying address my post.

"The second method of splitting brushes is the one that you are asking about here - putting a brush on top of another brush (like a cube crate on top of the floor) "

Thats not exactly what I meant. They say that to brushes touching cause cutting and thus more w_poly. What I said vrebatim above was

" So lets say you have a solid square made out of 2 smaller square brushes. The compilers can merge all faces as long as they are on the same plane?...thus it would big the same w_poly as if it where only one brush...."

In other words You have a cube....its 128x128x128. You clip the brush in half horizontally....then what? I'm under the impression that the compilers will merge the faces from 64x128 back to 128 x128 as long as it doent get cut by the sub divide that is....

OK I think I got. Using Func_detail will eliminate uneeded cutting. Especially important when A brush is twisted. Any face that is mergable will be merged....A square made out of one brush versus 6 pyramids will have the same w_poly....A brush that is a func_detail still is affected by surface area and texture scaling....but it won't cut world brushes causing more unneeded faces.....

@ Captain Terror:

glad that stuff I spouted was helpful I don't map for source unfortunately so I cant help with that. The map is from a mod i map for called Arrangement.

@ camplo

Sorry I didn't address the merging faces thing Yes, if all the faces are on the same plane and have the same texture properites then it should be merged to one face when the game compiles. Usually I use vertex manipulation to make each surface one face if possible, it just makes for cleaner mapping and easier editing later.

As to func_detail: When you tie a bunch of brushes into an entity it acts the same as brushes when it come to splitting faces, the only difference is they wont split other entities or world brushes by touching them, BUT they will still split other brushes in the same entity. This means that if you put a cylinder ontop of a square brush and tie both together as a func_wall, the cylinder will split the square brush like it was carving it (like normal brushes do).