Sign in to follow this  

what method of culling probably???

This topic is 4835 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

Im curious what techniques a game such as the following uses for culling, since theres small misc geometry scattered about the terrain. I figured probably octrees. hmm. Edit: let me refrase my question, would it be feasible to use an octree instead of a bsp? Also, im working on a small rpg with some friends. The world will use a 3d terrain and the characters, 2d. Anyway, the view will be limited so I was thinking I could use scissor testing for clipping. What that be a bad idea? (overhead style sorta zelda). Thanks. edit: I got that image from this site.

Share this post


Link to post
Share on other sites
Well, I can't tell what culling system they're using by just looking at the images. For all I know, it might just be brute force. But to be realistic, I think an octree system would work nicely, if implemented properly. It seems that most of the stuff in the scenes is static anyway...

As for octree vs. bsp, well, this has been discussed so many times on this board. So, I'm going to direct you to the very helpful search function. But if you want my opinion, I'd place my bet on octrees.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Usually, an octree is used for outdoor environments and a BSP tree for indoor ones.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Like the above poster said there is no way to know.

But I would personally use...

Top and middle: Quad-tree with occluders
Bottom: BSP, or possibly Oct-tree

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Usually, an octree is used for outdoor environments and a BSP tree for indoor ones.

Dammit, this post was mine. I forgot to put the password...

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Usually, an octree is used for outdoor environments and a BSP tree for indoor ones.


octree + outdoors? i somehow dislike this solution

since
a) quadtrees perform much better with outdoor environments
b) octrees should be used for leveled outdoor environments or maybe just for culling complex PVSs potential visible sets

i d do it a little bit different

1. use a quadtree
2. add convex hulls for indoor culling, can be done easily with brush based editors
use the faces of these convex hulls that touch those of other convex hulls as some kind of portal and link these portals into a quadtree

and give every quadtree a min max boundary of the geometry it gets assigned

Share this post


Link to post
Share on other sites
Quote:

octree + outdoors? i somehow dislike this solution


Octrees work quite well in highly culled outdoor enviroments. Especially when you factor in a highly used occlusion algorithm. Mainly with scenes which (as you said) are multi layered. The main difference is the extent of the Y direction required for validating the octree reference.

i suggest some other versions:
1) Loose octrees
2) ABT's

I'm a personal fan of ABT's & Occlusion Culling, and have sworn off any PVS/Portal system of any kind. These methods are really becoming a thing of the past.

~Main

Share this post


Link to post
Share on other sites
Quote:
Original post by duhroach
Quote:

octree + outdoors? i somehow dislike this solution


Octrees work quite well in highly culled outdoor enviroments. Especially when you factor in a highly used occlusion algorithm. Mainly with scenes which (as you said) are multi layered. The main difference is the extent of the Y direction required for validating the octree reference.

i suggest some other versions:
1) Loose octrees
2) ABT's

I'm a personal fan of ABT's & Occlusion Culling, and have sworn off any PVS/Portal system of any kind. These methods are really becoming a thing of the past.

~Main



well you are wrong with the PVS thing

in my engine you can place convex hulls, whose content is represented as a PVS ingame, this allows me to effectivly cull away everything that can not be seen from the players point of view

lets say you are working on a ww2 game and want to create a map like stalingrad, 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

imagine bombed out roads with complex indoor structures, it would be hard to cull these without a PVS implementation



as to octrees,you could use them for some kind of space simulation if you want to

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
imagine bombed out roads with complex indoor structures, it would be hard to cull these without a PVS implementation


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

Share this post


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

This topic is 4835 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this