I'm working on a map right now that is very open, so I've had to creatively work with my brushwork to fully optimize things.

To be blunt: I've hung a hint brush over the top of the map (very much in the style of the example Flash file) and, even being an outdoors map, I've managed to fit a few stone walls that reach up to this hint brush (and go far below my dislpacements to meet with the nodraw brush that forms the base of my map). A few may be an understatement; there are enough walls that the majority of visibility from one side of the map to the other should be greatly reduced.

Anyway, it didn't work out as well as I hoped. When playing it using mat_wireframe 1 and mat_leafvis 1, I noticed that buildings on the opposite side of the map were being rendered when I know they shouldn't be (based on the leaf I was in and knowing what other leafs it can see). I also have a tunnel in the map (meaning it's VERY concealed) and from that very concealed leaf with extremely limited visibility I noticed buildings above ground on the far side of the map were still being drawn.

Something I thought of while typing this is that I'm doing a FAST compile for both vis and rad... could this be a reason for this?

Another thing I wanted to bring up: I've decompiled most of the official maps to study techniques and such, and one thing I'm noticing a lot is that among the hints strewn about there are also brushes completely covered with the trigger texture nearby... however, when examining properties it just states it's "a solid with 6 sides"... so I'm not sure how it's significant to the hint brush.

You are having the same problems as me then.Unfortunatley this seems to be the one area that no-one is 100% sure about. You can decompile 6 maps and they will all be optomised using different methods.

In Flash if you highlight the hint brush and look at the 2D view you will see that you actually run around the map and play within a hint box just above head height. The remainder of the optomising is done with area_portals. Problem with these is they are not easy to get right as they have to be completely sealed or they will leak. Again if you look at the Flash vmf you will see that the area portals are sealed to the skybox using clip brushes.

I don't think you will find that the trigger brushes have anything to do with the optomisation.

The best explanation I have found is here http://www.student.kun.nl/rvanhoorn/Optimization.htm but it's still not crystal clear. Unfortunately I think it's a case of trial and error and just hope that what you do doesn't make matters worse which is one of the characteristics of optomising.

One thing you could try is puting some vertical hint brushes in that touch the ground and the underside of you horizontal hint brush as this seems to be a commonly used method. Try decompiling Kalt as this is how they have optomised that map and Donner.

Sorry can't be of more help.

I'm not sure if this is something should be be considered, but logically it seems like a possibility. Maybe the lower nodraw brush should not be so far down. Remember that displacements are treated as details and won't block visibility, which could possibly cause extraneous drawing - especially in a tunnel situation.

Not that I've actually been in a situation to do so, but most displaced obstruction, like hills or wall-ish stuff, should be lined with simple no draws... yea?

Its because youve set FAST for the VIS

also some leafs might be very large and see others that are on the other side of your house so even if you have lowered the leafs heigh,try placing hint faces at the houses corners as well.

I don't think people realise the importance of a full compile a lot of the time. A fast compile is exactly that, fast. You should not run a fast compile unless you are quickly testing minor changes to see how your map is coming on.

I played in a playtest yesterday, and the map had ran a fast compile, FPS was awful! You can't test a map done on fast compile! Its well worth the wait for a full compile.

FAST VIS means "who cares about calculating visibility I just want to see how it looks"

NORMAL VIS means "Ok lets calculate all the possible visibility between leafs,it might take time but It will save so much fps"

FAST RAD means "Lets quickly calculate a preview of that radiosity thing that takes ages ..."

NORMAL RAD means "Heres an accurate approximation of how shadows and radiosity should look like."

EXTRA RAD means "This is exactly how the light behaves in that map."


Final compiles must ALWAYS be done in FULL vis (sometime NORMAL RAD is acceptable even for finals when the EXTRA is really taking ages,some maps in HL2 are compiled in NORMAL instead of EXTRA)

So dont be afraid to choose what type of compile you want to do,either its one to test performances or another setting to test what your map looks like.

Hope it helps.

Thanks for all the replies so quick! Yeah, I read your post about fast compiles in another topic El Capitan, and about how they're sleazy as far as calculations but good for seeing how the map is coming along. I decided to switch over to fast (with full intention of doing a full for a final version) because my compiles were getting to the 1 to 2 hour point and I'm the kind of guy who likes to compile often and try stuff out. Anyway, the map isn't quite done but I was getting antsy to test performance... and I completely forgot that the fast compile does a crappy job at that.

So is it true that those trigger brushes have nothing to do with those hint brushes? Yeah, I noticed the mapper of Flash makes use of areaportals and the overhead hint... and the mapper for Donner uses primarily just hint brushes and trigger brushes. I was asuming maybe during the decompile it messed up the properties of the trigger brush, but if that's not the case they're just all the more confusing to me.

Yeah theres nothing wrong with using fast compile to test stuff out, just dont release a fast compiled map :P Also dont worry too much if you get terrible fps on a fast compile because on a full I get about 20-30 more than on fast.