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.