Forum posts

@ 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).

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.

Hey guys, I'm new to the forum, but i've been mapping for hl for a very long time. I thought I'd throw some information about brush entities (like func_wall and func_detail) out there:

Brush entities do not block VIS - only world brushes do that (This is the reason the map will have a leak if the map isnt sealed with world brushes).
This means that the bare bones of the map should be made with world brushes.

You can however put a lot of func_detail brushes INSIDE the map - for example making the floor of a corridor using the triangle method and making that a func_detail (with a brush underneath textured entirely with the NULL ttexture as the actual 'bottom' of the corridor).

If you look at one part of an entity, the entire entity is rendered. This is the main reason that an entire level cant be made with a func_detail. If you put a 6 sided crate in your level made as a world brush and you look at it, only the faces you can see will add to your w_poly (probably 3, two side faces you can see and the top). As an entity it will render all 6 sides (or 5 if the bottom face is a NULL texture). While this isnt crippling, it can definately add up when making really complex detailed brushes.

This is also the reason why its not always best to tie a lot of brushes together as one huge func_detail, because seeing a part of it makes the whole thing rendered, even if not all of it is seen by the player, and is hidden behind world brush walls.

This way of rendering entities (it does this with models) is the main reason why too many models can be bad for a level and how wallhacks work in games like counterstrike - because each player model is rendered at all times.