Integration of Bullet physics with Panda3D has been requested more than once. I have been working on this for some time now, and here is a PRELIMINARY solution:
The .zip file contains the source code, a few samples, and binaries for Windows 32 and Ubuntu 10.10. The binaries are built using Panda3D-1.7.1 and Bullet r2388 (unpatched).
PRELIMINARY:
This is work in progress, and I am still searching for the best way to integrate Bullet with Panda3D. Don’t expect the API to be stable yet!
OPEN ISSUES:
Character controller nudges objects and is nudged by objects.
2011-05-20: We have moved this project to Panda3D’s source code. Bullet support will be available starting with version 1.8.0, if there are not fundamental problems. For the latest binaries please download the current development snapshots.
Misread it, I thought the “build” folder was empty because of it.
Anyway… Im gonna study the code now.
From the other thread, I dont know what you mean by Blender not supporting tetrahedra. Although I dont have any Bullet knowledge, but Blender supports softbodies and it uses Bullet for physics.
I’m not an expert on Blender too, but from what see I assume that they do it the same way as in the soft body sample provided here: they use Bullet SoftBodyHelper to DERIVE a tetra mesh from a convex hull at RUNTIME.
In Blender this happens behind the scenes. Blender users never see the tetra mesh, and as far as I know there is no way of exporting it. And I don’t know any file formats for storing a tetra mesh (besides “proprietary” or “custom” stuff like e.g. PhysX uses).
Sidenote: PhysX has a small application which is also deriving a tetra mesh from an arbitrary triangle mesh, and then saves the tetra mesh to a file (binary or ascii). Then a PhysX game just LOADS the saved file at runtime, which is obviously much faster, and allows better optimization of the tetra mesh.
So… generating one at realtime isnt fast.
The only option I see is make a small application that generates it at realtime from a 3d file, then dumps it to another file.
“egg2bullet” or something.
Though Ive heard about a .bullet format that has expoters for maya and blender. Maybe it supports such thing.
And how do we link the vertices of the “3D file” (.egg for example) with the vertices of the tetra mesh? Just having the softbody simulation is not enough - People want to see a visual proxy of the softbody, something that get’s rendered, a triangle mesh. It’s good practice to have a visual mesh at high resolution (looks good) and a tetra mesh at low resolution (fast simulation).
.bullet file format a binary format to serialize different Bullet objects (and ONLY Bullet object). It is quite new, and nowhere stable. I have added code to save/load single Bullet shapes around r4/r5, and by r7 the code has been broken again. No idea why.
Anyway, .bullet is not the right way to go. On the long run we need something independent from any particular physics engine, like .egg or .dae
If you think extending egg or dae is the only option, then I guess you will say its best to wait for complete Collada support in Panda. So I guess this is another feature to be added for 2.0 I hate waiting…
COLLADA (.dae) does support some physics, right, but only the very basics. For example soft body, fluid or character controllers are not yet part of COLLADA. I have been reading the COLLADA 1.5 specs more than once during the last weeks.
I have been tossing in .dae because I have been expecting this very discussion. Here is my point of view on .dae:
pro: .dae is a standard. Ok, a new and emerging standard, but nevertheless a standard.
contra: .dae covers only basic physics. We want a modern physics engine integrated in Panda3D which supports advanced features like e.g. softbody. Extending COLLADA by us is not possible, and waiting until the Cronos group has added those features to COLLADA (might be years) will take too long.
I should add one of the thoughts I have for Panda3D 2.0 & physics. It’s about the collision system:
Every physics engine uses it’s own collision system. So the collision system is an integral part of physics, and it is not possible to have a “standard” P3D collision system but different physics engines.
Panda3D already has a collision system (which is not used by any physics engine except the built-in physics). Lot’s of code is written for this collision system, and replacing it by something completely different will break a lot (too much in my opinion, but this is just my opinion).
.egg files can hold information about collision shapes. The .egg importer create CollisionSolids within the scene graph when loading a .egg file.
COLLADA importer currently does not create CollisionSolids from COLLADA physics tags, but it COULD be extended to do so.
Panda3D support for ODE or PhysX currently requires the user to create “collision objects” (and other, like bodies etc.) through code, and not by importing a model (.egg). ODE or PhysX can not make use of loaded CollisionSolids. They just clutter the scene graph if using ODE or PhysX.
How to improve things:
Way A: .egg loader and all other loaders which are able to load collision geometry create, depending on what physics system (built in, ODE, PhysX, …) is used, collision objects for the physics engine used. Unfortunately ODE and PhysX collision objects are not part of the scene graph…
Way B: .egg loaders and all other loaders which … always create CollisionSolids, and the physics system used should search for CollisionObjects when creating a new body, and use this information.
I’m in favor of way B, and would like to experiment with this way for the next level of Bullet integration. What is your opinion?
Way B does seem superior to way A, because way A would require that the COLLADA loader interfaces with every physics engine supported; or we’d need to have some kind of registering system, which would only complicate things.
If way B could work goodly (I assume this would mean that the Bullet integration uses the existing collision structures), then I’d say go for it.
I agree. Not only the COLLADA importer, but also the .egg importer and so on…
The registering system is something I have been pondering too, since it would be a step towards a engine-angostic physics API, but this would mean to remove the current CollisionSolids (and the whole collision system) too. Not my intention.
So far the here presented Bullet code has it’s own collision objects, which get not loaded by Panda3D’s importers. What I am talking about is the next level of Bullet integration. I don’t want to give a date for a first release.
A downside of this is that I will have to add new CollisionSolids, e. g. for convex hulls, concave triangle meshes or heightfields. Not every physics/collision system will support every type of CollisionSolid. For example Bullet won’t support the inverse sphere. Also we have to be careful about the “modifiers” like e. g. “trigger”.
Other downsides are that ODE or PhysX won’t automatically benefit from this way. The modules would have to be rewritten too. I’d say not to start on this until the experimental Bullet integration work’s well.
Finally, the physics objects (rigid bodies) have to “query” the part of the scene graph below them for CollisionSolids, or state changes of CollisionSolids, since the CollisionSolids don’t push such information to these objects.
I have a look at the PAL source code quite often. It’s a great library from a technical point of view, but not what Panda3D needs. At least in my opinion.
Anyway, thank you very much for pointing us to this library, Anon.
I hate waiting…