Possible use of btGhostObject for frustum culling

[Flix]

I don't know if frustum culling has already been implemented in the Bullet Demos (and I'm not sure if it would be an useful addition for benchmarching application too).

Anyway I'm wondering if it is possible/efficient to use a (convex hull) frustum shaped btGhostObject to perform frustum culling.

I've got some questions about it:
1) Is this approach possible/efficient ?
2) To center the frustum convex hull in the camera position, can I use simple convex hull shape centered in the camera position, or I need to use a convex hull shape (centered in its own center) inside a btCompoundShape centered in the camera position ?
3) I don't know much about btGhostObjects, but I've seen that in the Character Controller Demo this class is not directly used, but a class that inherits from it. Which are the differences?

Thank you in advance for your answers.

[Erwin Coumans]

Frustum culling, as well as occlusion culling has been implemented using the btDbvtBroadphase acceleration structures.

Check out Bullet/Extras/CDTestFramework

Hope this helps,
Erwin

[Flix]

Erwin wrote:

Frustum culling, as well as occlusion culling has been implemented using the btDbvtBroadphase acceleration structures.
Check out Bullet/Extras/CDTestFramework

Well, I had some trouble to compile the code, but now I've managed to do it (with a few changes), and in the next days I probably will dig into it to see if it's easy to implement frustum culling in btDbvtBroadphase worlds without using a frustum ghost object.

In the meantime I've make an extension to the BasicDemo that implements frustum culling by means of a frustum ghost object with narrow phase collision detection: it's a big overhead and probably not suitable to speed up Bullet Demos, but maybe can be useful in bigger demos with many objects positioned around the camera.

Hope it can be useful for somebody.

[GameQ]

I want to revisit this topic. I am making a game engine and have had Bullet plugged into it since day one. I actually already have frustum culling but I noticed that I was basically do a lot of checks that Bullet already can do for me (and most likely faster). So I want to change my system to build a collision shape for the fustum and then use the Ghost contact manifold for my draw loop.

I looked at Flix's code and ran it and it seems to work but not perfectly. Objects that are on the edges of the frustum will get culled out early making them blink in and out.

If frustum culling using ghostObjects can be effectively done, then I want to take it a step further and use ghostObjects for my OctTree.

~GameQ

[Flix]

GameQ wrote:

I looked at Flix's code and ran it and it seems to work but not perfectly. Objects that are on the edges of the frustum will get culled out early making them blink in and out.

No,no, the code works perfectly. That seems to happen just because I did not set the collision margin of the ghost object shape to zero. Once you do it, you'll see it (the shape collision margin is probably useful only to recover objects from collisions, so I suggest to set it to zero when using "transparent" ghost objects).

If frustum culling using ghostObjects can be effectively done, then I want to take it a step further and use ghostObjects for my OctTree.

For sure it can be done. Keep present that this "ghost" approach is good if you want to perform "narrowphase" frustum culling (i.e. frustum culling based on the "real" Bullet shape, good for culling out expensive rendering geometries), otherwise you can use the "embedded" frustum culling implemented in btDbvtBroadphase (based on the Bullet/Extras/CDTestFramework demo).

I tried them both and I made some time testing:
I can say that (in my demo) the second approach is, as expected, faster, but only once you get rid of all glGetMatrix(...) calls, that make the code much slower (more than 3x) than the "ghost" alternative (thus I believe that the code as it is in the CDTestFramework demo can be made faster): once done, the bottleneck remains the calculation of the 6 frustum planes each frame, which is not needed when using the ghost object frustum. At the end I made the second approach about 1.5-2.0 times faster than the ghost object approach, but there further margins.

I wasn't able to exploit the additional "occlusion" boost of the btDbvtBroadphase (I don't know even if it can be used or not in a pratical application).

The advantages of the ghost object approach are mainly:
1) Full narrowphase collision detection.
2) Simple implementation (no need to calculate the 6 frustum planes each step).
3) Works with all the broadphases (= more flexible).

The speed after all was not so bad in my demo, but it may depend on the physic complexity of the shapes colliding with the frustum (I suppose that the btDbvtBroadphase culling implementation is probably more stable as frame rate).

That's all I've experimented on the topic. I hope it can be useful.

Regards.

P.S. I forgot to mention that I've tried to simplify the ghost object frustum convex hull shape by reducing the vertices from 8 to 5: I expected an improvement of 3/8 in speed, instead the performances were very similiar.

[GameQ]

I finally got it all working in my code base, thanks for your code Flix, it acted as a good guide.

One Question Though:

What it this line? I found that I did not need it, and putting it in seemed to just slow me down.

Code: Select all

m_dynamicsWorld->getDispatcher()->dispatchAllCollisionPairs(m_ghostObject->getOverlappingPairCache(), m_dynamicsWorld->getDispatchInfo(), m_dynamicsWorld->getDispatcher());

thanks,
~GameQ

[Flix]

GameQ wrote:

What it this line? I found that I did not need it, and putting it in seemed to just slow me down.
Code:
m_dynamicsWorld->getDispatcher()->dispatchAllCollisionPairs(m_ghostObject->getOverlappingPairCache(), m_dynamicsWorld->getDispatchInfo(), m_dynamicsWorld->getDispatcher());

Nice found. Well AFAIK, in short that line "should" recalculate (or refresh) the list of contact objects (of the ghost object), and I'm pretty sure that when I wrote the code I needed it (that's why a few lines below I wrote:

Code: Select all

if (collisionPair.m_algorithm) collisionPair.m_algorithm->getAllContactManifolds(m_manifoldArray);
		else printf("No collisionPair.m_algorithm - probably m_dynamicsWorld->getDispatcher()->dispatchAllCollisionPairs(...) must be missing.\n");
[

).

Now the code seems to work without it (maybe now the Bullet library refresh "narrowphase" ghost object automatically each frame, and so it's no more possible to just put one in the world and just "ask" it once in a while...; now the behavior is consistent with "aabb" ghost objects, that did not require any method call to update them AFAI remember). Or maybe it's just me messing around. I hope that somebody can clarify that.

[Erwin Coumans]

I wasn't able to exploit the additional "occlusion" boost of the btDbvtBroadphase (I don't know even if it can be used or not in a pratical application).

Did you run into problems, or you just didn't spend much time trying to get it to work?

The occlusion culling feature of btDbvtBroadphase is used in the Blender 2.49 game engine, some occlusion culling info is at the bottom of this page (also available as this occlusion culling google document)
I'm probably going to use it also in the new GameKit project.
Thanks,
Erwin

[Flix]

Did you run into problems, or you just didn't spend much time trying to get it to work?

Well, mainly the latter , but it was a bit more difficult to "extract" the occlusion query code from the Bullet/Extras/CDTestFramework demo, since it used an additional extern class (an oriented bounding box AFAIR), which I had to understand a bit deeper...

Anyway before digging into it I just wanted to understand a general explanation of its usage.
I mean maybe, even if I can find out that an AABB is fully covering other AABBs, the body inside the first AABB might be smaller, and so I should draw the objects in the covered AABBs as well: is this correct?
I've no experience in this field, so I need to understand the subject a bit better before digging into it.

Thank you for the links, maybe I will find them useful for future reference (and I hope I will find the info I'm looking for as well).