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.
Possible use of btGhostObject for frustum culling
-
- Posts: 456
- Joined: Tue Dec 25, 2007 1:06 pm
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Possible use of btGhostObject for frustum culling
Frustum culling, as well as occlusion culling has been implemented using the btDbvtBroadphase acceleration structures.
Check out Bullet/Extras/CDTestFramework
Hope this helps,
Erwin
Check out Bullet/Extras/CDTestFramework
Hope this helps,
Erwin
-
- Posts: 456
- Joined: Tue Dec 25, 2007 1:06 pm
Re: Possible use of btGhostObject for frustum culling
Erwin wrote:
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.
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.Frustum culling, as well as occlusion culling has been implemented using the btDbvtBroadphase acceleration structures.
Check out Bullet/Extras/CDTestFramework
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.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 8
- Joined: Fri Aug 14, 2009 8:44 pm
Re: Possible use of btGhostObject for frustum culling
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
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
-
- Posts: 456
- Joined: Tue Dec 25, 2007 1:06 pm
Re: Possible use of btGhostObject for frustum culling
GameQ wrote:
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.
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).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.
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).If frustum culling using ghostObjects can be effectively done, then I want to take it a step further and use ghostObjects for my OctTree.
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.
-
- Posts: 8
- Joined: Fri Aug 14, 2009 8:44 pm
Re: Possible use of btGhostObject for frustum culling
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.
thanks,
~GameQ
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());
~GameQ
-
- Posts: 456
- Joined: Tue Dec 25, 2007 1:06 pm
Re: Possible use of btGhostObject for frustum culling
GameQ wrote:
).
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.
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: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());
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.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Possible use of btGhostObject for frustum culling
Did you run into problems, or you just didn't spend much time trying to get it to work?Flix wrote: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 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
-
- Posts: 456
- Joined: Tue Dec 25, 2007 1:06 pm
Re: Possible use of btGhostObject for frustum culling
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...Did you run into problems, or you just didn't spend much time trying to get it to work?
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).