Comments on: Software Occlusion Culling

By: ben

ben — Sat, 24 Apr 2010 00:14:49 +0000

Where can i find the source code to your ingenious solution?

Regards,

Ben

By: convex graph

convex graph — Mon, 29 Mar 2010 01:46:20 +0000

[...] … the slope of my utility function strictly convex. Trust me ladies, with me there is no …Software occlusion culling | .mischief.mayhem.soap.Old occlusion culling method becoming cool again! … Instead of rendering occluders to buffer, you [...]

By: realtimecollisiondetection.net - the blog » Catching up (part 2)

realtimecollisiondetection.net - the blog » Catching up (part 2) — Mon, 08 Jun 2009 08:52:05 +0000

[...] Sinilo wrote a good post on software occlusion culling. I know of several games (from different companies) that have used software-rasterized occlusion [...]

By: admin

admin — Sun, 02 Nov 2008 19:44:03 +0000

I rasterize about 1200 faces per frame in 0.8-1.2ms (boxes consists of random number of small polys, just to increase complexity and make it more realistic). Transformation seems to be a bottleneck and takes ~3.5-4.5ms. Occlusion test of AABBs – up to 1.5ms (I test 8 points). I expect it can be speeded up noticeably, I didnt spend that much time on optimizations.

By: Arseny Kapoulkine

Arseny Kapoulkine — Sun, 02 Nov 2008 18:44:29 +0000

I meant the occlusion performance actually – i.e. for some of that screenshots, how much time does it take to draw how many occluders in occlusion depth buffer and how much time does it take to qualify how many objects (OBBs?)

By: Thread Profiler | .mischief.mayhem.soap.

Thread Profiler | .mischief.mayhem.soap. — Sun, 02 Nov 2008 14:16:52 +0000

[...] degree. Old habits die hard, though, and I noticed it when experimenting with occlusion culling (recent note). For some reason, the first version of my multithreaded triangle rasterizer would run slower than [...]

By: admin

admin — Mon, 27 Oct 2008 07:12:15 +0000

ed: interesting idea, didnt think about it. You couldn’t clip/intersect in full 2D, though, as depth is important here as well. Getting the “shape” of occluder may not be trivial, also.
Arseny: I imagine it should work very nicely with SPU especially. About performance numbers, I didnt post them, because the scenario isnt terribly realistic — rendering is rather cheap (just skinning+texture+directional light) and on the other hand there are many occluders. Anyway, normally I render about 150-170k faces at 17ms per frame without occluding and 70-90k at 10ms with occlusion culling (that’s normal situation, nothing extreme, like standing in front of a huge cube etc). Tested on my crappy laptop (GF8600).

By: Arseny Kapoulkine

Arseny Kapoulkine — Sun, 26 Oct 2008 20:29:30 +0000

Interesting, I wanted to implement it both for PC and for SPU but did not have the time to try. Perhaps I’ll find some after your post :)

What are the performance numbers?

By: ed

ed — Sun, 26 Oct 2008 20:25:37 +0000

Wouldn’t be better use software clipping in 2d ? Instead of rendering occluders to buffer, you would just project occluders into 2d space and make a list of 2d convex (or non-convex) polygons. Then you can clip-intersect objects with this list. This would solve fig. 6. Additionally since modern processors have good paralel computing capabilities but still struggle with memory bandwidth; having few more computations can be better than memory accesses (especially that you need to sample more points to avoid fig.6).