Quote:

Not really, as you'd using some form of occlusion culling ( a HOM for instance ).

That's correct.

PVS was good for games and graphics, but the fact is, it's old news, and old technology. Now-a-days (and more specificly future-days) PVS actually causes more problems than solutions, and by not taking full advantage of the hardware abilities, you're limiting yourself and your engine.

ABT + Occlusion culling allows for very diverse environments, in that the visibility isn't pre-copmuted, it's dynamic.

Imagine trying to create your bombed out city in-game w/ a PVS. You just couldn't. The created portals and new visible holes will allow you to see through those PVS areas. You'd have to re-compute the entire PVS set every time a bomb went off.

Because of the nature of occlusion culling, it handles that scene without any additional overhead.

And when you really get to it, all that extra work to create PVS/Portal systems is just redundant. Take advantage of the technology that's around you.

Quote:
you could either use a octree quadtree culling method where you have a lot of overdraw or you use a manual PVS implementation where you cull away entire parts of a city

That's an incorrect statement. Or atleast I don't know why you said you'd get "overdraw." That doesn't exist in good implimentations. I'd reccomend implimenting occlusion culling before making broad generalizations like that.

~Main

and yes this statement is correct

2 streets behind each other

with a octree you won t cull the invisible street, only what s outside your viewfrustrum, so you get overdraw

with PVS +quadtree i can limit the overdraw to a minimum since i only render the outdoor scene and not the indoor scene

and since modern engines use z occlusion culling to avoid processing expensive shaders for overdraw pixels i ll only get a minimum overdraw for a few outdoor polygons instead of setting up and performing a dozen of statechanges to render multiple lightsources and other complex shader effects on geometry that can t be seen anyways

+ i can cull the PVS againt the view frustrum as i do with the quadtree nodes and thus don t have to perform visibility checking against PVS that are out of view

an no you don t create holes and have to recreat your PVS you can simply create a fake portal which is activated when for example a wall gets bombed away or you tread func_breakables * the classname of breakable objects in q* engines * as doors and don t cull things behind them

This needs to be cleared up, because I'm not sure you have a handle on the differences that you're stating.

Quote:
with a octree you won t cull the invisible street, only what s outside your viewfrustrum, so you get overdraw

Pure oct/quad tree usage only sets up for frustm culling, which yes, you'll get visible overdraw. Advanced quad/octree culling (which uses Occlusion Culling, and is what we've been talking about) does visibility determination on invisible objects and removes them from the render queue. Occlusion culling does not result in overdraw.

Quote:
with PVS +quadtree i can limit the overdraw to a minimum since i only render the outdoor scene and not the indoor scene

Occlusion culling will give you the same thing. Without the precompution. It can be done on the fly. PVS is not the only solution for visibility, it's just an old one.

Quote:
and since modern engines use z occlusion culling to avoid processing expensive shaders for overdraw pixels i ll only get a minimum overdraw for a few outdoor polygons instead of setting up and performing a dozen of statechanges to render multiple lightsources and other complex shader effects on geometry that can t be seen anyways

1) Occlusion culling != early z rejection. OC happens before the render queue is created. Z rejection happens at the pixel shader level.
2) Occlusion Culling = visibility determination.
Quadtree = Scene subdivision.
Octree != Occlusion Culling.
I hate to say this agin, but i don't think it's getting understod: Occlusion culling removes non-visible geometry. Your scene subdivision only sets up the environment in a method to actually preform visibility determination (be it PVS or OC) BSP, Octree,Quadtree, ABT, these are all just spacial partitioning. In it's root existance, it does not account for any type of visibility determination. OC/PVS - THESE are visibility algorithms, which both do the same thing: remove non-visible geometry from the scene.

I suggest reading the following threads, Yann has already covered most of this, in a far better way that I can:
link1
link2
link3

to quote yann:

Quote:
If you create a new engine from scratch, don't use [bsp/pvs]. Use Occtrees (or similar) for indoor and outdoor geometry. You can still use portals, even with octtrees. You can't use PVS anymore, but that's no real problem, if your portal system is good. You could also throw in some occlusion culling, which renders even the portal system obsolete.
.
.
.
but it's funny how some people hang on old technologies, and try to deny by all means the fact that those technologies have reached the end of their life cycle. BSPs are a thing of the past, and have been replaced by better alternatives. Deal with it.

From the man himself.
~Main

just to get back to the nv occlusion query he mentioned

you have to sort your octree/quadtree leafs before rendering into the depth buffer which i am going to do anyways

right?

ZSorting in general isn't needed for OC. You can do it, depending on if you have a home brew OC algo, but for the extentions, it's not needed. The extention tests weather or not the pixel passed the z test, which is the same test it goes through during normal rendering, in which z sorting just speeds things up a tad(but speed isn't the issue during the OC queary, the engine bubble is) Home brew engines can't test against the pixel, so they have to zsort beforehand in order to make sure that the objects are coming into the scene properly.

~Main

just create a logfile of your viewangles and rotate you view a bit during logging

around 3-5 frames with high fps are always using the same angles