The biggest advantage, I think, would be vis time being proportional only to the interior volume of the map. Also func_detail would be unnecessary.

vis time was the main thing I was thinking of, and also that vis time would scale linearly with map size meaning that complex "vis breaker" maps would no longer be an issue. 

I'd need to do some research to understand more how hint brushes work in order to apply them to a big open map.

Is there a way to visualise portals in quakespasm or another engine? 

 

The portalization is discarded following the vis process; all that's stored in the BSP file is a list of which leafs are potentially visible from each leaf. 

I have found Darkplaces has r_drawportals 1 command. So what is that visualising? 

 

load up any map in darkplaces, and do r_drawportals 1. Doesn't need a prt file. 

Intersections between leafs or something? 

IIRC DarkPlaces does it's own realtime portalization. That would be what it's visualizing. 

I'm afraid I'm gonna be asking some stupid questions for a while.

The only other portal-based rendering I'm familiar with is Doom 3 and the portalling there is hand-placed and is coarser than quake I think? (it's done per room, more or less).

Is the portalling in quake on a per-leaf basis? i.e. (ignoring detail brushes for now), are visportals created for each bsp leaf? 

There's no such thing as a stupid question; particularly when it comes to something like this, where the knowledge actually isn't anywhere that's publicly accessible.

Anyway - don't know. Somebody else is going to have to chime in with that one; this part of tools work makes my head hurt. 

Is the portalling in quake on a per-leaf basis? i.e. (ignoring detail brushes for now), are visportals created for each bsp leaf?
afaik that's correct, same with what Spirit said, "Intersections between leafs". So, they're super fine-grained. With "r_drawportals 1" in DP you are seeing the portals, but it's also a visualization of the leafs at the same time.

Bringing detail brushes into the picture, the info on which faces/leaves were detail is not stored in the bsp file, so DP's "r_drawportals 1" will be showing portals as if all detail was converted to world first. 

Thanks guyz, so...if I compiled the map without detail brushes (I think the "jury-rigged" bjp compiler lets me do that)...then viewed it in DP with "r_drawportals 1", can I trust that i'd be seeing the actual portals that vis.exe will be using? 

you can load the prt file q3radiant aswell, there is a plugin for that.
Quark also loads and displays the portals of a map.
Comparing those may help you. Idk what you are up to tho. 

Thanks for info

Idk what you are up to tho.

Just wanted some help with visualising what happens when I dick around with hint brushes, because right now I don't have a scooby doo of how I'd go about hint-brushing a massive open map :/ 

i feel you, i have always got advice from a friend to use hint brushes, if i want to optimize vising times/quality.

I never bothered to, actually i am playing around with those atm. Hint brushes can make a big difference, thats all i know by now. 

from what I understand, hint faces force qbsp to split along those planes, before using any other faces as split places. just imagine doing a 3-point clipping on the whole map, putting the clip points on the surface of the hint face. I think qbsp picks the order in which to do these splits, but it will always do the hint faces first.

Also how do you actually use them? I assume a brush with one face textured "hint" and the others "skip", and I assume it gets deleted from the final bsp, otherwise they would be annoying. 

Yep, using "wedge brushes" for hint seems to be the way to go. Hint texture for the desired split, hintskip on the sides that can be discarded.

I have produced some serious HOMs with that already, discarding more protals than it should i assume.
It is tricky, and the tuts that exists for using hint/hintskip brushes all rely upon HL2 compilers.

Hmm.. 

Paraphrasing the best explanation I can recall of hint brush functionality:

Imagine a large room with a high ceiling. It is divided by a wall taller than the player but which only reaches halfway to the ceiling. What you'd want as a level designer is for the space on one side of the wall to be invisible when you're on the other side.

QBSP on its own will take the vertical faces of the divider wall and split the world vertically, leading to two tall leaves corresponding to the two sides of the wall and one narrow one that's on top of the wall. The entire map is visible from everywhere this way, because if you're standing in the bottom of one of the 'wells' you can see the top of the other well's full-height leaf, so the whole leaf is visible all the way to the floor.

If you place a wide horizontal hint plane so that it lines up with the top surface of the divider wall, it splits the room horizontally instead. Now the two leaves on either side of the wall do not extend higher than the wall itself, so the wall fully occludes them from each other until the viewpoint passes the top of the wall, and the entire top half of the room is now one big leaf, so when you're on top of the wall the inside of both wells is still drawn as you'd expect.

Hinting an outside area is really tricky if you've got trisouped rolling terrain, because you've got to find whatever the equivalent of the divider walls is and it's often not as obvious or convenient as a wall. Having this in mind when you make your rolling terrain in the first place makes your life a lot easier.

It's worth remembering that if your big open space is suitably split by big un-see-overable divider walls, you could just have a wall of sky texture stick up out of the top of the divider and make your life easier that way instead. If that's not desirable - maybe the player will at some point be high enough to see over (or will stand on top of) said dividers - then from that vantage point the whole outside area is going to draw anyway, and that is what will set the minimum performance bar for your level. If a given computer can handle that view playably, it doesn't matter if drawing the entire outside area at other times is in principle 'more than necessary.' It's going to become necessary when the player makes his way up there. 

especially Lunaran with that super useful post - essentially what you described is what would in theory solve my map - imagine a town where the player is mainly low with most of the rest of the town occluded by walls and other buildings. Tall spires and towers rise above the walls though and should be visible from a distance.

If I can fudge things with hinting so that a fair amount of the structures below the walls are hidden, then that will probably do the trick.

Of course there are times when the player gets a bit higher and sees a bit more, but at least I'll be able to say I made a bit of an effort :} 

Best of all is that this hint plane can be from a 16x16x16 brush. 

Do it hierarchically, so that there's a second tier of taller buildings that forms a higher barrier for the rooftops of the tier-1 buildings.

And use lots of arched passages and tunnel alleys.

because those are cool. 

Lunaran: it has all those things and more :}

Question:

In the creation of the bsp tree, do hint planes *always* take priority over structural brush planes when building the tree?

I.e. if I make a map with one obscure little hint plane somewhere, does that form the very first split in the entire bsp tree? I'm guessing no, as that could lead to very unbalanced trees? 

Looking through the bsp.exe code it appears that a structural plane won't be chosen for a bsp split if that plane splits a hint face, but otherwise the splitting planes are chosen that produce the least face splits (no matter whether they are hint planes or structural planes).

So...

Best of all is that this hint plane can be from a 16x16x16 brush.

The size of the hint face should matter though surely? If I have read the code correctly, a whopping great hint face vs a small hint face (but both faces on the same plane) should cause the bsp tree to be split in a different way. 

Hint brushes get along really bad with liquids.
And by really bad I mean not at all.

The latest version of the Good Compilers doesn't throw a mixed contents error anymore at least, but as I remember it still clips away liquid surfaces inside hint brushes and gets really confused about leaf contents in general.