Hintbrushes

Good evening,

First a quick introduction, I'm a old school mapper that has been out of the loop for awhile. After playing around in CS:Source I've decided it's time to try and reincarnate the knowledge of hintbrushing to the general mapping community. I'm toying around on the standard CS:S maps making a small divx? of how and why (it's going to take a while getting this one done).

In the meantime I'm going to drop by here every now and then trying to answer questions you might have.

I'll never understand why Valve still has hint brushes in the new tech when they have area portals as well. Makes no sense.

Backwards compatible? :razz:

I'll never understand why Valve still has hint brushes in the new tech when they have area portals as well. Makes no sense.

I have to admit I haven't studied the new portals techs. However when I see leaf(s) like this one mat_leafvis 1 , doing mat_wireframe 1 this to the vis information, I get a little upset (old school habit) and just want to do something.

The concept of area portal is much more intuitive than hint
brushes. Even after reading through numerous tutorials on the
subject, I am still just left with some vague idea of how to place them.

But area portals are easy to comprehend. But if someone has the
time and good will to prepare a tutorial on area portals, that'll be
great.

The concept of area portal is much more intuitive than hint
brushes. Even after reading through numerous tutorials on the
subject, I am still just left with some vague idea of how to place them.

But area portals are easy to comprehend. But if someone has the
time and good will to prepare a tutorial on area portals, that'll be
great.

I'll take the time to do the portal(s) research, you know it were called portals back in the good old Quake? days? I'm am however not sure in what way (if any) they are connected. I'll go look though the SDK to see if I can find any portals references.

It would be to great help if you could know of any documentation that valve has written on portal(s). Thank you.

edit: I realised some of my grammar had a "Norwegian" feel to them.

Well, Half-Life has portals, too, and even Unreal has its own form of portal (and anti-portal) tech. Hint brushes affect portals, but without basing the entire vis system around portals there's no good way to get the setup you need - you still have to guess around a bit.

I'm only familiar with portals in D3 and anti-portals in Unreal, but I assume the same principle applies here. You place a portal such that it seals itself against world geometry - for example, in a doorway, at the corner of a hallway, or anywhere else you'd like to use as a cutoff point for rendering. Say you have two portals like this (this is how D3 displays them via r_showportals 1):



In this case, we have two portals. We'll say the one on the right (portal 1) is closer and the one on the left (portal 2) is farther. Because the two overlap, we know it is possible to view parts of the area behind portal 2. Thus, they are both considered 'open' and are rendered.



Now we've moved somewhat, and portal 2 has moved outside of portal 1. We know for a fact that there is no possible way that portal 2 can be seen from portal 1, so it is closed and all geometry behind it culled.

When you combine this with more complex portal usage, you can get crazy culling in areas you never thought possible. Ever seen a 32 or 64 unit pillar block vis when you get up close? Or been able to close off visibility around a curve? :smile:

Unreal's anti-portals are the opposite in that anything behind them is culled. This means you can actually toss in an antiportal into a terrain mesh and get large terrain features to block vis. Pretty handy, and if combined with a portal system I think I'd crap myself. :razz: Instead of putting one of those in a door, you'd put it around the door, so only what is directly visible through the door is rendered. That's combined with zones, I think, which help define portals. It's been a while since I've used it, but it's also a nice system.

Hopefully HL2's portals work somewhat similar to D3's. :smile:

EDIT: Ack, I apologize, that's some hideous jpeg compression... Ah well, I bet Orph's happy! :biggrin:

Wow, Squirrel! After reading through that, I am more confused than ever. Perhaps it just reflects my low intellect.

My understanding is that area portals are placed where doors are, but I
am not sure whether I should use them for windows as well.

P.S. Should someone move this thread over to the "HL2 Editing"
section? The discussion sort of drifted from the initial request.

The only reference I've seen to area portals in HL2 is about linking them with doors to toggle rendering of what is behind them on and off, but to me this seems like only the tip of the iceberg when it comes to their potential. I think hint brushes are still plenty useful but once people get experimenting properly with area portals, they certainly seem to offer much more potential for control over what is rendered.

Well, Half-Life has portals, too, and even Unreal....

I see what you are saying, portals are basically hintburshes with more functionality.

Note on doors, in the old quake? days you would use a func_ to turn of vis information behind the door when it closed.

I'll try to put what KungFuSquirrel said in another way, hopefully it'll add to the perspective.

You are standing in portal/leaf A (from now on leaf), what happens then is Half-Life 2 (from now on HL2) will check what leaf(s) it can see from leaf A (it checks by looking up the vis information). The result might come up being leaf B to R, that makes HL2 draw all those leafs. By placing leaf(s) in such a way that they can't see each other you prevent the other leaf from being drawn.

In other words if you have a leaf that is taller than the fence you just built, HL2 will draw most the objects behind the fence. This is due to the fact that the leaf decides what is getting drawn, and it does see what is on the other side (being taller).

edit in:
This will go both ways, if you are in a small leaf that can see a tall leaf on the other side of the fence they still see each other. Thus what is behind the fence is still drawn.

What I mean when I say see is:
If you can draw a straight line from any point inside leaf A to any point inside leaf B, they can see each other.

hints and areaportals are used differently though, so their usage isnt
really overlapping. Hint basically just creates a portal and by
doing this you shape how portals interact with each other. Like
in the sdk_hints, they made portals at the level of the block, so that
the block basically culled everything on the other side, since the vis
group you were in is not as tall as the block.

Areaportals do the same thing except you can turn them on and
off. If they are open they act just like a normal portal
would. Closed they cull everything behind them. So using
them with doors is the most logical usage of them. Another usage
of them might be a really long long hallway. Somehow you would
want the portals waaaay down the hallway to be closed when the area on
screen is too small to make a difference anyways. However there
seems to be no way to make distance a factor in turning areaportals on
and off (except with extensive triggering mechanisms). For this it seems we can use a seemingly even more
useful entity: func_areaportalwindow.

This seems to be the optimal way to control visibility through windows,
through hallways like I described, etc. At a user defined
distance the portal will start to fade, and at another user defined end
point it will become totally opaque and close just like an areaportal
would, kind of like fog execpt it actually culls everything behind it.

There are a couple of confusing entries: rendered window, and
foreground bmodel. I am guessing that rendered window would be
what it renders all the time? Or maybe when it is closing, it
renders it? And then when it is totally closed it renders both
that and the bmodel? It'd take some experimentation for sure,
maybe I'll test it out some tomorrow. But surely anyone writing a
tut on this will have to explain exactly what these are unambiguously
as the help does not do a good enough job.

It seems like you can do everything an areaportal would be able to do
with the areaportalwindow, except that you don't have to bother with
any entity I/O to link areportals to doors like you would need with the
areaportalwindow.