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?


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
    Nov 10 '16 at 10:51
  • \$\begingroup\$ *with as 'few'...damn auto correct. \$\endgroup\$
    – Krythic
    Nov 10 '16 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\$ Nov 10 '16 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.