Jump to content
  • Advertisement
Sign in to follow this  
yodaman

what method of culling probably???

This topic is 5447 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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



Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
The way I managed the occlusion queries was to give each node an ID, this also doubled up as an occlusion index;

--frame cycle start--
Now with your frustum culled nodes z ordered, start from nearest working your way back.
For each node check for occluders -> render to depth.
Start a query, render node to depth.
Continue for all nodes (in frustum).

Once all the queries have began, I render the scene - as it would have been in the previous frame.

Next I fetch back the results, this allows me to store off the scene (which I will render in the next frame).
--frame cycle end--


Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Not z-sorting will greatly reduce the efficiency of occlusion queries. The reduced efficiency from latency hiding is bad enough, without reducing occlusion efficiency even more with sub optimal rendering order.

Of course, z-order is temporally coherent, so you can manage with not doing a full sort every frame which saves time.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Yeah, I use frame to frame coherence.
Also get a nice boost by drawing the occluders/nodes at half resolution - but you cant go too far with this or you'll get really bad results.
In general, my occluders are very simple hand placed objects. Mostly just rectangle shapes.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!