2
\$\begingroup\$

I'm wondering if it's possible to use or hack Bullet 3d Physics (or another free 3D physics engine) so that I don't need to "import" my static geometry into Bullet - instead I want to do it the other way, so Bullet uses some sort of callback system to check geometry properties of my mesh/polygons.

Sort of like that Bullet would expect a method in my static geometry classes "checkRayIntersection" or similar, and I take care of the details and optimizations myself. The meshes are immovable, so the only thing that I expect Bullet to care about is intersections and their normals, but I might be missing something..

EDIT: as an example, consider a 10 million polygon terrain mesh which is changing all the time. You probably don't want to keep parallel data structures in the render-engine and in the physics engine for this. You don't want to use an approximation for the physics either.

Bullet uses something called MotionStates to solve this problem for its output - I was hoping there was a similar design pattern for passing geometry input.

|improve this question
\$\endgroup\$
  • \$\begingroup\$ Why would you want to? Besides personal preference, do you have some actual need to break a 3D physics engine like this? Just let it do its job. \$\endgroup\$ – Nicol Bolas Nov 3 '11 at 18:44
  • \$\begingroup\$ if the physics engine can use the vertex buffers exactly like they are passed to OpenGL, then its ok of course. I was under the impression that Bullet needs the structures in its own format, so you 1) waste time transferring it and 2) waste memory keeping it. \$\endgroup\$ – Bjorn Wesen Nov 3 '11 at 20:27
  • \$\begingroup\$ Why are you passing physics and collision information to OpenGL? I'm not talking about your rendering meshes; I'm talking about your world collision volumes. They aren't necessarily the same thing, you know. And if they are, then your case is either extremely simple (so "wasting memory" isn't a real concern) or something very special. Furthermore, even if it could use a buffer object directly, you never want to read from a buffer object like that. It would be a far worse idea performance-wise than "wasting" memory. Think of it as a memory/performance tradeoff. \$\endgroup\$ – Nicol Bolas Nov 3 '11 at 21:25
  • \$\begingroup\$ I already have highly optimized intersection-lookups in a million-face mesh, I just don't want to download that into Bullet.. Actually it would not be "breaking a physics engine", there is already an analogous class-relationship for output as MotionStates. I guess I'm lucky that Bullet is open source :) \$\endgroup\$ – Bjorn Wesen Nov 3 '11 at 21:40
3
\$\begingroup\$

Posting this here in case someone else has the same problem.

It seems like both Bullet and ODE can be manipulated into doing custom collision-handling. It's described here in the ODE wiki and on p.21 in the Bullet User's Manual. I should have read the manuals more closely before posting :)

In essence you provide a function which checks the collision and fills in a contact point structure with the position, normal and penetration depth (just like I wanted).

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Note that you are both allowed and encouraged to accept your own answer if you've solved your own problem :) \$\endgroup\$ – ZorbaTHut Nov 4 '11 at 13:35
  • \$\begingroup\$ @zorba ok, seems there is a time quarantine on that still though :) so there is still time for a Master of the Domain to come with infinite experience and wisdom :) \$\endgroup\$ – Bjorn Wesen Nov 4 '11 at 14:08
  • \$\begingroup\$ I'd +1 if you game more detail for Bullet than "on p.21." Thanks. \$\endgroup\$ – MichaelHouse♦ Apr 15 '12 at 9:32

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.