Fabien Sanglard's doom3 code review has some interesting stuff on that:
http://fabiensanglard.net/doom3/renderer.php
Not really sure how state of the art engines do it though. 

You could do something with hardware occlusion queries.

Beware that vis data is needed on both client and server. The server uses it for determining which entities to write to the client, but also for line-of-sight target checking in PF_newcheckclient and PF_checkclient. 

just render everything!

Is the question how to do Quake-vis in real time or more general? Saurbraten obviously uses different data structures...all depends on what your goal is? 

Culling the Battlefield: http://www.slideshare.net/DICEStudio/culling-the-battlefield-data-oriented-design-in-practice

Uses software rendering to a low-resolution depthbuffer with artist-placed low-resolution occlusion geometry in order to determine what's visible and what's not. In other words that's not something you're going to be able to do with existing content (and I can confidently predict that you'd meet some resistance from mappers if you were to suggest them building occlusion geometry for new content too). 

I don't know about that ... I think many mappers would build occlusion geo if the offset was they didn't have to spend 60 hours running VIS. 

Is that anything like hint brushes? 

 

is a viable option though. I do it in TrenchBroom and get 60 FPS even on large maps. I don't think that adding light maps will make much of a difference, but dynamic lights might pose a problem. 

Wouldn't all the entities being visible and active be a problem? 

I mentioned this above, but PVS is not just used for rendering. Without PVS you'll also be sending all entities to the client each frame, and line of sight testing for targetting will also always succeed. You may be able to get away without PVS for rendering in a map editor, but you almost certainly can't get away without it for the latter two in the actual engine itself. 

I'd wager it wouldn't matter all that much in the end. How many entities are actually doing anything each frame? Most monsters are standing around waiting for the player to show up. Everything else just animates statically.

So, really, how much additional network traffic is there going to be? 

Err, by animates statically I obviously mean animates but doesn't move. :P 

Most monsters are standing around waiting for the player to show up.

Not in a Tronyn map... 

Is it vis compile times? 

For me, VIS times on most of my Travial maps was beyond brutal and VIS ran for days. But I was also using a 1.3GHz Pentium 100. I added to the problem by designing maps without respecting the engine and its limitations. The burden of long VIS times cut into time and machine resources that could have been used for further creative work. 

So have you tried using func_detail and tyrann's tools? 

If vis takes longer than a couple of hours then you either need to update your tools, learn how to use them properly or both.

And, as Mh says, without PVS all enemies will wake on map start. 

Or even Q3BSP and manually creating portals.

OK, OK, I'll stop it. 

How many entities are actually doing anything each frame? Most monsters are standing around waiting for the player to show up.

And how do they know that the player's shown up? By doing a vis test, that's how (like I said, look at PF_checkclient and PF_newcheckclient, both of which use the PVS). So if you run with the "just draw everything" approach, ignoring vis data, then that vis test will always pass. And then they're no longer just standing around doing nothing. 

Testing e1m2 with protocol 666, the network traffic difference is a factor of 10. 

"And how do they know that the player's shown up? By doing a vis test, that's how (like I said, look at PF_checkclient and PF_newcheckclient, both of which use the PVS). So if you run with the "just draw everything" approach, ignoring vis data, then that vis test will always pass. And then they're no longer just standing around doing nothing."

Sure, but then you come up with a different method. :)

I'm just noodling around the ideas here. I think VIS was great 20 years ago ... not sure there aren't better solutions these days. 

"Testing e1m2 with protocol 666, the network traffic difference is a factor of 10."

This only affects people playing across a network and ... well, I guess both of them would have to find a new hobby or something. :P 

I guess where my brain is heading is a thinking exercise for engine programmers ... what if VIS didn't exist? Go. 

I guess where my brain is heading is a thinking exercise for engine programmers ... what if VIS didn't exist? Go.

Just to be clear are we talking about something that requires no pre-processing step? Also, how much work should the designer have to do? 

I don't know. I think anything is fair game ... LDs placing portals or totally automated. It's just interesting to think about. 

I always thought Doom 3's system was pretty decent - designer places the portals, and the compile time is measured in seconds. 

concerning bsp portals, the phrase "good luck with that" comes to mind once you get into the realm of Tronyn-style monstrosities (and I don't mean that word in a negative way). 

kinn, doom3's system is fucking horrible. try portaling anything that isn't room-corridor-room and there's no fucking way.



Run the existing vis algorithm as the map is played? In the first few unrendered spawn frames, vis only the leaf the player is in, assume all other portals closed. All the right monsters will still wake up, because portal visibility is a symmetric relationship. Keep up with the player's current position vising one leaf at a time as he runs around, use any spare frames to follow the bsp structure outward to try to keep ahead of him. Cache it all to the same PVS structure. Areas that players or monsters never go will get skipped naturally.

Then, if you've still got a poorly build monstrosity of stupidity that would have taken six hours to vis, the framerate will just be bad :P 

kinn, doom3's system is fucking horrible. try portaling anything that isn't room-corridor-room and there's no fucking way.

I guess it is. I never tried doing anything fancy (layout-wise) when I was tarting about with D3. 

this thread is awesome... it's probably my utter lack of knowledge on this subject that makes my maps such technical problems for vising (and despite the time-sink of trying to finish a degree, I hope to put out a couple more visbreakers yet...). 

...to run vis using hardware occlusion queries at load time, rendering to a lower-res offscreen surface (you'd actually need a cubemap (or 6 renders) because vis is agnostic to orientation), which should have substantially speeded things up, as well as successfully dealing with map layouts that aren't amenable to the standard software vis.

A typical modern GPU that can handle Quake at 1000+ FPS should easily be able to crunch through most maps in seconds. The whole "portal flow" paradigm just doesn't scale, and the simpler option of "build a depth buffer and do a depth test" is more robust in the face of geometric complexity in a way that portals aren't.

The only gotcha lies in the fact that occlusion queries work from a single point, whereas leafs occupy a volume.

Even so, and if this can be overcome, an offline pre-processing tool using this idea should also work, and remove all of the burden of long vis times.

But the real appeal of run-time vis is being able to dynamically move around large sections of the world and still have valid visibility. Load-time or even accelerated pre-processing would lose that. 

And since we don't have dynamic sections of the world moving around ... 

Since we're talking about dynamic stuff moving around, Quake 2's areaportals system would also be a useful addition to Quake, and would give you a good starting-point for run-time visibility. 

although, designwise, areaportals are a poor substitute for static limitations in visibility. An areaportal is only a good idea when the player for whom visibility is being limited is the one opening the door. If the thing that's stopping you from seeing into the next room and getting slow performance is just one door, and a monster comes through it while you've got everything in view, for at least part of the time that door effectively isn't there and performance is as bad as if you'd just left it open.

Whenever I get annoyed that I have to still build some kind of visblocker on one side or the other of a door, I remember that that's better design anyway and the lack of areaportals is simply reminding me of that. 

Surface flags instead of alpha entity, r_whatever alpha, and texture naming hacks. Also external textures.

On-topic: DP has built-in vis? Not sure if orealtime. 

Sauerbraten's precomputation apparently uses this. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.6463 

Thanks for that link and perhaps I can use it to find others like it. 

I've been thinking more about the idea I mentioned above (using occlusion queries) and it seems to me that something may be possible by using a combination of the world bounds and reducing to the same 16-texel scale as lightmaps.

So what I'm thinking here is to divide the world into a grid of 16x16x16 boxes, then for each box do a Mod_PointInLeaf on the center. If it's in solid don't bother, otherwise run a 6-view-draw with occlusion queries and merge the resulting leafs into visibility for this leaf (which will have been cleared to nothing visible at initialization).

Obviously there are probably edge cases that I haven't fully thought through, but overall this is an interesting enough approach that I might even code something up. 

I guess your only concern there is memory usage but these days, who cares? 

what about the case where there is a point in between your chosen sample points that can see more than any of the neighboring sample points? That seems like a really common case. 

Like I say, I haven't really thought through everything yet. It may be possible to use a finer grid, or you may be able to say things like "if leaf A can see leaf B then leaf B can also see leaf A", or whatever.

I'm not going to let "what ifs" detract from putting together a proof of concept; at the very least I'm interested in comparative performance on a known vis-breaker, and if it runs well enough then it'll be worthwhile putting in the extra effort to deal with this stuff. 

Might I suggest a certain UnVISable Qonquer map from the last map jam. :P 

(I've long wondered if vis doesn't intentionally show a little bit behind walls for WinQuake's dynamic lighting. Like a lavaball on the other side showing through. Because I'm not aware of anywhere that a dynamic light won't show through a wall, which means the server sent the rocket or lavaball to the client or a player with Quad.) 

That's a good suggestion.

One other advantage I can think of to this approach is that it should no longer be necessary to seal a map.

@Baker: start.bsp in ID1 - if you go to the normal skill hall, stand near the left-hand wall and look towards the right-hand wall: no shine-through. It's easy enough to add an r_lockpvs cvar for testing purposes. Otherwise the answer is in SV_FatPVS. 

I think you'd still need a seal BSP tho. Otherwise you'd have no way of knowing what is void and what is valid game space. 

technically you don't, you'll just have tons more leafs, faces, marksurfaces, lightmaps, clipnodes, etc. I think vis can be modified to accept leaky maps as well, it will just take a lot longer due to all the extra leafs it needs to process. 

I guess that's true ... there WOULD be void on the inside of brushes. But you'd have to basically place those vis sampler nodes he's talking about throughout the entire Quake world grid/cube since it would all be playable game space in a leaking map. 

yeah true. With this technique, the processing time scales with the total volume of non-solid space, rather than the total number of leafs. 

The point about the GPU-accelerated approach is that this shouldn't matter. It will still take longer because a lot of formerly CONTENTS_SOLID leafs will now be CONTENTS_EMPTY, but it should take significantly shorter than software vis because you're just rendering 6 views and reading back occlusion query results. The resulting visdata may also be much higher quality.

For release-quality maps sealing is of course a must, but as a development aid, faster vis times and a higher quality result should be a win. 

Why not just make a realtime raytracing engine. It's been done before (albeit with hardcore CPUs)

http://www.q3rt.de/
http://www.q4rt.de/ 

 

I want to try making a version of light.exe that runs on the gpu (OpenCL).
I'm pretty sure it's possible, only question is whether it will be much faster than the cpu version. 

Where can I find source code for modern vis tools? I'd like to learn how some of this stuff is implemented. 

You probably don't. :) Modern tools are stapled on top of the old code. And the old code will drive you to drink, trust me. 

There's no hope for this project if the code is THAT bad :-) 

He's talking about a whole new methodology ... something done at runtime. I haven't seen the game code itself so I don't know how hard it is to mod but I suspect it's been improved in the various engine code bases.

The tools ... not so much. :) 

and shit, if you're re-writing engine code to vis during runtime, then you might as well make a whole new map format to boot. 

...is that it really operates on too fine-grained a level for a modern renderer. Like a lot of things in Quake, it made sense for a software renderer on a lower-specced PC, where every polygon you could save performance by not drawing was a win, but with even halfway reasonably decent hardware acceleration that just goes out the window.

Some relevant notes about the XBox 360 port of Quake 2: http://www.eurogamer.net/articles/digitalfoundry-2015-quake-2-on-xbox-360-the-first-console-hd-remaster - it just didn't bother using vis at all and still managed 60 fps with 4x MSAA at HD resolutions.

Culling of unseen polygons is also eliminated in the Xbox 360 version, deemed unnecessary due to the paltry number of triangles used per map - meaning that the entire world is drawn each and every frame.

That's fine for original content but is obviously going to fall down (badly) on some of the more brutal modern maps. But it does highlight that the really fine-grained per-leaf visibility is essentially disposable when dealing with more modern PCs than the original engines targetted.

if you're re-writing engine code to vis during runtime, then you might as well make a whole new map format to boot

This can seem to make sense on the surface, but you need to dig a little deeper. One of the reasons why BSP2 was successful is that it changed as little as possible in the format. There were discussions about what features it should have while it was being specced (and I did the original spec and implementation so I can be 100% certain about this) and it kept on coming back to making it as easy for other engine authors to implement as possible. So while it could have had features like built-in RGB lightmaps, 32-bit textures (or even a separate palette per-texture), or others, it didn't. It didn't even change the .map format so that mappers could continue using their favourite editors, and all that was required in the engine and tools was a few #defines, some new structs and a bunch of copy-and-paste code.

What's really required to make Vis more efficient is to change it's granularity from per-leaf to something like per-room. I have no idea what that would entail in terms of tool-work, but engine-side it could lead to better efficiencies from less BSP tracing while drawing and being able to build static batches from world geometry. 

we have per-room vis already, in a way, if the mapper makes heavy use of func_detail.

crazy idea, maybe you can recover the "leaf clusters" in the engine if you want coarser granularity vis data for rendering. Just group all leafs together that have the same visdata? 

BSP2 was limited by the requirement that it needed to work with Worldcraft and a Fitzquake derived engine, because switching editors proved to be an unpopular idea and dropping our sympathic newborn engine for Darkplaces or FTE seemed too heartless even to me at the time, although it would have been the right thing to do in retrospect (and it was the first thing I did afterwards.)

In the big picture, BSP2 is a foul compromise but a nice thing if you want to keep the Q1BSP pipeline.

About reducing the VIS detail:

Add a compiler switch that lets the mapper disable automatic vising. Then add a new custom texture (like "trigger") that lets the mapper create portals manually.

I did a similar thing in my single-player maps (which are both very large and very detailed) when I still used FBSP and it resulted in a HUGE performance boost. Despite already using detail brushes. I inserted just enough portals to cull far away areas of the map, instead of going overboard with it like the Quake compilers do by default. Performance is then mostly limited by batching.

The performance increase was comparable to the improvement in Vis time after using func_detail.

I got the idea from looking at how Call of Duty (1) does it, since that's a Quake 3 based game with relatively large outdoor maps. Turns out they changed it completely and yes, the mapper has to manually portal the map in that game.

Quake 1 (and Quake 3) vising was developed for corridor shooters running on 90s consumer hardware. No wonder they tried to cull every little bit whenever possible. But hardware and Quake mapping have changed so much that this formerly very effective method has turned into an obstacle, and a massive obstacle at that.

It is probably less noticeable with deathmatch maps, and thus Quake 3 maps. But single player maps are bogged down by this massive amount of unnecessary info. 

So just for laughs I flew around jam6_ericwtronyn - which is about the heaviest thing I can throw at the quake engine right now (I think) - and noted that in the most epic view I could find, I was getting around 30,000 wpoly and 70,000 epoly. I think this map is unvised, but looking at the structure of it, I can't imagine vising it would bring those polycounts down much.

Now, unless I'm missing something, those kinds of polycounts shouldn't trouble any sort of even vaguely modern hardware (didn't Doom 3 have like 150,000 polys in a typical scene in 2004?)

So...questions...

I get a solid 60fps with jam6_ericwtronyn on a reasonably modern laptop running Quakespasm. Does anyone here get bad performance in this map, and if so - what hardware/engine you running it on?

Are there other factors at work that cause unvised quake maps to perform slowly that are not to do with polycount? Things like 400 monsters running LOS checks? 

I got poor performance on some maps with Mark v on my surface pro. My pro can run dark souls, burnout paradise and some other decent games so it's no slouch.

Dark places and Rmq tend to be better performance for big maps 

I think it's just the old rendering code. It probably spends more time figuring out what not to draw than it would take to just draw it... 

TB just renders everything in every frame and it's fairly smooth. I'm sure with proper optimization it could be faster by a factor of two. 

Most engines were focused on features and that was many years ago. Modern engines that break some hardware compatibilities can do it. Iirc it's VBO, as mh did. 

I think it's just the old rendering code. It probably spends more time figuring out what not to draw than it would take to just draw it...

So...in an engine that uses some reasonably modern rendering code, an unvised map would run quicker than the same vised map? Is this the case with Quakespasm? 

Potentially. A lot of modern games are throwing around props in scenes that have more triangles than entire Quake levels. 

an unvised map would not run quicker -- but it might run at nearly the same speed with the right engine code. The only way unvised would be quicker is if the engine detected this case and used different code to render it compared to a vised map.

But the main point still stands, polygons are not the bottleneck for quake on modern hardware, it's things like draw calls, lightmap uploads, and (perhaps) geometry uploads.

I believe the ideal quake renderer for modern hardware would reduce draw calls down to 1 per texture, put all geometry in vertex buffers (potentially ignoring vis to make this work,) and do lightstyle calculations in hardware. 

It would definitely be a revolution to leave VIS behind ... imagine the iteration times if level designers only had to QBSP and LIGHT. 

Even if you stick the entire map into a single vbo and draw it with a single draw call (which is possible, except for sky+water), you will still suffer from overdraw.
those individual props with more polys than entire quake maps do not have 15 different rooms overlapping each other.

it might be interesting to throw the entire map at the screen in a single draw call, both with and without an early z pass... 

Quakespasm has upgraded world and mdl rendering paths vs Fitzquake, if I disable these with the "-novbo" option my framerate goes from 60 -> high 20s in that map.

However, I think QS would still run faster if this map were vised - it could skip drawing entities, and skip draw calls for the world (there's a draw call for each batch of polys that share a texture and a lightmap.)

IMO all maps should still be vised, if someone did develop an engine that was faster ignoring vis data, that engine could just ignore the visdata.

What would be interesting, I think, is an upgraded / state of the art vis tool that could give less exact results but finish in a reasonable time. I wonder if there's some off the shelf, open source vis algorithm that could be used. I tried to vis the jam version of jam6_ericwtronyn but the progress indicator got stuck at the end after 2 weeks, it didn't finish in the following week so I killed it.
Vis isn't going to do a ton on this map, but if it could just separate the cave and outdoor sections that would help.

it might be interesting to throw the entire map at the screen in a single draw call, both with and without an early z pass...
I'm curious how you'd handle the texture switches when drawing the world in 1 call, is there a better way than a texture atlas? When I read about atlases, they sounded like a big pain because you have to partially tile the textures in the atlas so texture filtering doesn't read into adjacent textures. 

Thanks, some cool info there :)

I tried to vis the jam version of jam6_ericwtronyn but the progress indicator got stuck at the end after 2 weeks

o_O

To what extent were detail brushes used in that map? I figured that kind of solved the vis time problem, even for crazy bonkers tronyn stuff. 

It made good use of func_detail too, had something like 7k clusters, 24k leafs - so vis only had to be computed for the 7k clusters.

Could be it's just the map layout being open. For comparison I've tested ijed's telefragged.bsp and it full vises in about a minute! 

I just realised the map source is provided so I fired it up in radiant, pressed Alt-2 to only show the world brushes, and...yes I see the problem :) 

Yes, overdraw is the thing I forgot... Still need a good solution for that. 

I'm having some trouble understanding the technical bits - so I assume drawing X triangles that are all stacked behind each other (lots of overdraw) is slower than drawing the same number of triangles spread out on a sheet but still all in view (no overdraw) ? 

Carmack himself stated a while ago, you can ultimately throw brute force at every problem once the hardware is fast enough. Vis is a clever solution to a problem, precalculate instead of doing things during runtime.

Afaik the main problem with overdraw is related to shading, ie too many fragment-shader invocations per pixel ( scenes with many overlapping particles tend to show this, makes older GPUs rev up nicely ), but shouldn't early-Z take care of this for opaque surfaces ?

But it probably still overdraws during the z-phase as you end up trying to draw a lot of unnecessary polygons, so it depends on the player hardware.

Any software engine people want to chime in ? I guess it might be quite bad for them at least. 

Everything seems to run well for me, I guess the intel GPUs are finally good with Broadwell :-) 

"but shouldn't early-Z take care of this for opaque surfaces "

It does. If the depth buffer rejects a pixel, you won't eat the rendering.

Overdraw is really only a problem on systems without depth buffers or stacks of non-opaque surfaces - like particle systems or glass. 

The main reason to always use vis, even if an engine is faster by disregarding vis entirely, is serverside culling and networking bandwidth even if the client totally disregards it.
culling realtime lights via vis is also very useful, although I suppose you could also use oclusion queries for that.

@ericw
use GL_ARB_bindless_texture
atlasing or texture arrays are also an option, but more fiddly (but also more likely to be supported by hardware).
water+skys could be done with subroutines.

@Kinn
overdraw is when you draw the same pixel multiple times. the earlier times become redundant and are essentually become a waste of memory bandwidth.
typically, graphics cards utilize an 'early z' optimisation which massively reduces the cost of overdraw, so if you draw the only world's depth first, then draw it normally (with depthfunc gl_equal), then you're not wasting time calculating the colours+textures of geometry which will never be seen.
really the advanttage depends on how expensive your fragment shaders are (including the cost of texture lookups+bandwidth).

Quake's software renderer had a zero-overdraw strategy. vanilla glquake draws triangles as they come from the bsp tree (nearest first). all modern glquake ports instead batch by texture, which can result in excess overdraw.
it'd be nice to return to a single-draw-call nearest-first renderer. best of both worlds - assuming your hardware+drivers are recent enough... 

it'd be nice to return to a single-draw-call nearest-first renderer

I don't know much about current hardware capabilities, but is this even possible, given that there are typically dozens to 100 textures in a bsp, plus a bunch of lightmaps that, even with atlassing, probably can't fit in a single texture? Are there enough texture units on modern cards to accommodate all of this? 

GL_ARB_bindless_texture
no binding = no texture unit limit.
pass the texture via a vertex attribute.

GL_ARB_shader_subroutine
efficient branching, based upon vertex attributes.

both together and you have some serious dependancies on modern hardware... but should be able to draw the entire world in a single draw call - so long as your graphics card has enough memory (probably not an issue with vanilla textures, but will undoubtably be an issue with replacements).

I've not used either, so while I'm sure its possible, I'm not sure on the actual practicalities, but hey... 

Post #38, quoting here (from mh)

I've been thinking more about the idea I mentioned above (using occlusion queries) and it seems to me that something may be possible by using a combination of the world bounds and reducing to the same 16-texel scale as lightmaps.

So what I'm thinking here is to divide the world into a grid of 16x16x16 boxes, then for each box do a Mod_PointInLeaf on the center. If it's in solid don't bother, otherwise run a 6-view-draw with occlusion queries and merge the resulting leafs into visibility for this leaf (which will have been cleared to nothing visible at initialization).

Obviously there are probably edge cases that I haven't fully thought through, but overall this is an interesting enough approach that I might even code something up.

Ignoring the realtime thing (the subject of this thread) - if an offline vis tool was developed that used such a GPU-based occlusion approach to create the vis data - would this theoretically lead to higher quality visdata than the current portal-based method?

It would certainly allow for much more open maps, surely? 

Kinn, it does sound like a tempting/cool idea.
I'm not sure if the vis quality difference would be noticeable.

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.

The disadvantage is you'd be moving to a system that could, in corner cases, draw less than it should. I'm thinking a hole in the wall where you have to stand just in the right place to see through, and the sample points used by vis never line up with that spot. Probably a 16x16x16 grid would be fine enough that it'd never happen in practice.

The other concern is, how fast will it be? An 8192x8192x8192 box is the worst case. That's 512^3 vis sample points using a 16x16x16 grid, and if each vis sample point can be computed in 1ms (rendering all 6 views and getting the occlusion query results) that gives you 37 hours. 

The problem with open maps is not how vis tests visibility, it's how the world it's testing is split up into a tree. If the splits in the tree don't correspond to occlude-able pockets of geometry, it doesn't matter what method you use to determine which ones can see which ones, you're always going to be 'seeing' geometry you think you shouldn't.

The solution you're looking for is careful construction and planning of your big open map, and hint brushes. 

Hint the lot and trust the player has 256 allocated... 

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.