Right now I'm using Predication to cull my BV tree after I first cull it with a few different view frustums, to get different ranges of objects to pass on to other parts of the engine. Life is good it works and has been a big save for me!

What I basically do is cull all the extracted BV trees nodes against the current depth buffer and it takes a few frames but I then do this:

 If g_pPredicate IsNot Nothing Then
        Dim tester As Boolean = _context.IsDataAvailable(g_pPredicate)
        If tester Then
            Dim ds As DataStream = _context.ImmediateContext.GetData(g_pPredicate)
            Predication = ds.Read(Of Boolean)
            ds = Nothing
        End If
    End If

to check the current occlusion of the BV tree node when I next update on the cpu, like I said it happens a few frames late but I can live with that for now.

The way I hide the lag is by only using the Predication result on tree nodes that are far from the camera and I also only update the visible tree nodes every 6 frames.

I also know after read the MSDN docs that I can use a different flag to just do the actual drawing of the object with the Predication hint and not return a value to the cpu but I don't think it will work with my instance drawing and I imagine that testing BV nodes would be faster than testing all the objects because BV nodes hold objects so if I cant see a node then I know that the objects want bee seen.

My question is, should I be down sampling the depth buffer and doing the Predication query's in a smaller resolution because that would allow me the get the returned value faster? Would it still take the same amount of time or am I doing it wrong?


1 Answer 1


Turns out after much testing that I should be using a standard occlusion query because I can read it back on the CPU, I found out by reading the MSDN doc that if I use the pred query with the hint flag then I cant read it back on the CPU and without the hint flag I had no point to use the pred query.

So the next part was the popping and query lag, I fixed this by reordering my update and occ querys, so now I fire off an occ query then once it returns I then fire off a new occ query and update update my mesh data with the old occ.

Because I only update mesh data every few frames I can have the query and update synced up and don't see any popping\query lag that's also because I cant move far enough in the time it takes to fire off and return querys so I end up sending out less and less occ querys, of course if I make really large jumps or fly up\run really fast then I de-sync a bit and spike occ querys but the player should never move that fast anyway and even with the testing spike because I check for the return in a none blocking way I don't really see any perf hit, just some popping until I slow to sain speeds.

  • \$\begingroup\$ I've found that occlusion culling works best with as view tests as possible. I also separate models into regions, and test against the region. If the region has a collision with my frustum I then step into the children of that region. Entire rooms are considered regions in my game engine. And some rooms have inner regions. \$\endgroup\$
    – Krythic
    Commented Nov 10, 2016 at 10:51
  • \$\begingroup\$ *with as 'few'...damn auto correct. \$\endgroup\$
    – Krythic
    Commented Nov 10, 2016 at 13:36
  • \$\begingroup\$ I too test against regions as testing object would be way to much, the more there is on screen the more fails the tests so it kinda self optimizes as I move along and I end up have to test less and less. Right now I use bounding boxes as my proxy for culling but I'm going to switch to a filled in box instead of just lines because sometimes a cell gets culled when it shouldn't \$\endgroup\$ Commented Nov 10, 2016 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .