Hello,
not a strictly bullet-related question, but I hope you guys won't mind ...
I am using bullet as a visibility engine, i.e. to perform rays casts from point A to point B to check if B is visible from A (i.e. no objects are intersected by the ray from A to B).
And then, the two questions:
- first, I understand I am using a physics engine for a very specific and not very physics-related task. Is Bullet very efficient for my task, or I should better look to other libraries or techniques (implementing one is not a major issue)?
- second, are there any bullet settings that you recommend to make these kind of tasks as efficient as possible?
Thanks for any help!
bullet as a visibility engine
Re: bullet as a visibility engine
I view the Bullet engine components as a great way to perform the kinds of visibility testing that you've mentioned. If you dig into the library code, you'll see that the BulletDynamics project is built on top of what can be viewed as a totally separate component: BulletCollision. Since you're only concerned with collision testing, you'd really only need to make use of the contents of that project in particular.
1. Seeing as how Bullet performs well during realtime physics simulation, I would argue that BulletCollision is a fine choice in doing the geometry queries that you've mentioned. It may be overkill in the sense that you likely won't use much of the more complex functionality that BulletCollision can provide, but it will get the job done.
2. I would suggest sticking to simple collision geometry. Various collision testing algorithms in the library are more compute-intensive than others, so the simpler the collision shapes are, the better. You won't have dynamic objects bouncing around- you're just testing for collision. Use simple approximate shapes when possible.
1. Seeing as how Bullet performs well during realtime physics simulation, I would argue that BulletCollision is a fine choice in doing the geometry queries that you've mentioned. It may be overkill in the sense that you likely won't use much of the more complex functionality that BulletCollision can provide, but it will get the job done.
2. I would suggest sticking to simple collision geometry. Various collision testing algorithms in the library are more compute-intensive than others, so the simpler the collision shapes are, the better. You won't have dynamic objects bouncing around- you're just testing for collision. Use simple approximate shapes when possible.
Re: bullet as a visibility engine
Thanks for the reply.
Yes, I am using just BulletCollision. And it gets the job done, surely!![Smile :)](./images/smilies/icon_smile.gif)
I am just wondering if there could be other solution to this specific problem ...
I am currently using full resolution meshes as collision shapes because I need precise visibility result, but I'll make some tests with simpler shapes to see how that would impact accuracy and speed.
Yes, I am using just BulletCollision. And it gets the job done, surely!
![Smile :)](./images/smilies/icon_smile.gif)
I am just wondering if there could be other solution to this specific problem ...
I am currently using full resolution meshes as collision shapes because I need precise visibility result, but I'll make some tests with simpler shapes to see how that would impact accuracy and speed.
-
- Posts: 19
- Joined: Thu Jun 28, 2012 5:06 pm
Re: bullet as a visibility engine
If you are using OpenGL or DirectX, you can use hardware occlusion queries.
Re: bullet as a visibility engine
Not really: the latencies involved in round-tripping makes them non-trivial to use at best. There have been a few papers on that, not to mention they burn precious batches. Add the various driver behaviours and hardware configurations and we sure have a real beast to deal with.