Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


Occlusion culling ideas


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 wildboar   Members   -  Reputation: 281

Like
0Likes
Like

Posted 19 May 2011 - 07:35 AM

I am interested to know what you guys use for occlusion culling these days?
Or you dont bother with it?

It seems there is only umbra occlusion booster and CHC++ solutions these days.

Umbra is ridiculous in a way that the developer can only evaluate for 30 days.
I would gladly pay them after game is made, or even take a loan and pay on the day of release.
But who knows when my game will be made, maybe it will take 3 years, so I have to pay crazy amounts of money
every year.

CHC++ seems incredibly complicated and uncomplete.

Is there any other solutions out there? I am mainly interesting in OpenGL hardware occlusion queries or software.

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 32049

Like
4Likes
Like

Posted 19 May 2011 - 08:08 AM

Occlusion culling was around long before hardware occlusion queries. Hardware occlusion queries do have their uses, but in my personal opinion they are a pretty terrible tool for general scene culling at the moment (predicated drawing and GPU-generated draw-commands may sway my views on this in the near future).

The best choice of culling algorithm is going to depend highly on the type of scene you're trying to draw.

Is it static and can you process the data at build time? If so, just use PVS. If you can't pre-compute a PVS, use portals and occlusion shapes.
For dynamic scenes, I'm currently pretty impressed with modern implementations of the HZB.

Regarding Umbra -- evaluation periods are standard practice for expensive middleware. Their business is not targeting cashless indies.

#3 smasherprog   Members   -  Reputation: 432

Like
2Likes
Like

Posted 19 May 2011 - 05:54 PM

Occlusion culling is very Engine specific. There is no one culling-technique-to-rule-them-all. Like the above posted said, there are other factors that can affect your decision: pre calculated scenes (static); outside, open scenes; portal culling, etc. It does not take much time to develop your own technique and I have found that the best choice is not often the one you thought. Culling --or removing-- work to be done is always a good thing, however, most of the culling techniques will end up costing more and are not advantageous to use. I am mostly targeting the Octrees, or other spacial partitioning methods. You should be very carefull with how you divide up your world because there are lots of objects --or work-- that can be batched which will yield a nice performance increase. I babble about Octrees , and provide some code if you wan .octree and coherent hierarchical culling
Wisdom is knowing when to shut up, so try it.
--Game Development http://nolimitsdesigns.com: Reliable UDP library, Threading library, Math Library, UI Library. Take a look, its all free.

#4 mhagain   Crossbones+   -  Reputation: 8286

Like
2Likes
Like

Posted 20 May 2011 - 09:02 AM

GPU queries are good for determining that something is not visible, but you have to assume a safe default of everything that's in an undefined state being visible, and you have to be prepared to accept that results may lag a frame or two behind what you see on-screen. Creating and deleting query objects has some overhead, and if you do need to fetch the results as soon as possible, then you need to stall the pipleline while waiting for them to finish. In other words they're a bit lazy and sloppy, but sometimes lazy and sloppy is plenty good enough for your need, so don't discount them.

Occlusion culling is very Engine specific. There is no one culling-technique-to-rule-them-all. Like the above posted said, there are other factors that can affect your decision: pre calculated scenes (static); outside, open scenes; portal culling, etc. It does not take much time to develop your own technique and I have found that the best choice is not often the one you thought. Culling --or removing-- work to be done is always a good thing, however, most of the culling techniques will end up costing more and are not advantageous to use. I am mostly targeting the Octrees, or other spacial partitioning methods. You should be very carefull with how you divide up your world because there are lots of objects --or work-- that can be batched which will yield a nice performance increase. I babble about Octrees , and provide some code if you wan .octree and coherent hierarchical culling

This, in a nutshell, is very very wise advice. Sometimes it's better to take the overhead of extra polygons that won't be visible in exchange for not having to break a batch. Example (backface, not occlusion, but it's just an example): you can quickly determine if a poly is backfacing in software, and not add it to your draw list if so, but if you've already got all of your data on the GPU in a VBO, this may hurt you - you'll need to break batches and you'll need to rebuild a dynamic VBO. On the other hand, if you just draw the thing the GPU will backface it for you, and the cost is just a few extra per-vertex ops and some command buffer entries. Both methods have a cost, but which is the cheapest? Any kind of culling is all about choosing between tradeoffs, and balancing them so that you come out on top for your own particular needs.

It's also worth trying to dig up Mike Abrash's notes from when he was working on Quake; they're old but I believe parts of them are still relevant, in particular the core point that it's not about culling as agressively as possible but more about performance levelling between your worst case and your best case. Example: a solution that runs 20 times as fast in the best case than an alternative, but one-twentieth the speed of the same alternative in the worst case, is probably not an appropriate solution for your needs.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS