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/