Currently, Bullet mainly provides a C++ API. However, there is a rudimentary start for a C-API proposal.

Currently only two know places that use this C-API: - A demo that uses it (see Bullet/Demos/BulletDinoDemo) - Blender uses the Bullet C++ API in the Blender Game Engine, and Bullet C- API for some internal Blender collision tasks (Blender is mainly C-code).

Complete it further. See discussion here: http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=9&t=1976

OK, this is very much a work in progress. All sort of things are not quite right, and I wouldn't suggest this for public consumption just yet. But, to get a feel for it, see attached, Bullet-C-API.cpp and Bullet-C-Api.h.

khubert,

Thanks for the patch. Are you interested in finishing your work on this? What do you feel needs to be done before this is good enough to be committed?

Thanks, John

Here's my small contribution to the C wrapper. I add static mesh support (using function declared in Bullet-C- Api.h file, but not present in c file). More to come I think (raycast). If someone can check my work... it seems so simple that maybe I posting something bad here.

Thanks! Pilo

Looks like some people are switching to ODE, because they find that C-API easier to use than the Bullet C++ API:

http://www.youtube.com/watch?v=M7c0bc5pXWo&feature=channel http://groups.google.com/group/ode-users/browse_thread/thread/afaa9ae22254c057

When using libraries from languages other than C and C++ a C API is very much preferred. While C++ might be the preferred language for some people to program in it isn't a very good language to write public libraries in if the author doesn't include a C API.

In todays world people write applications in a whole lot of different languages: Ruby, Python, Perl, Lua, Scheme, C, C++, etc. For me it's Common Lisp and talking to C libraries is a breeze. C++ libraries less so and one almost always has to write wrappers in C and talk through those to the library, introducing extra dependencies and also burdening the library user with C and C++ programming which is exactly what he or she was trying to avoid.

I'm very happy that there's at least a minor C API for Bullet and at the moment I'm writing bindings for it for Common Lisp. My preferred 3D engine (Ogre3D) doesn't have a C API which almost made me switch to Horde3D.

Here are some minor additions from me. Added plNewStaticPlaneShape and plSetLinearVelocity.

The current C API attempts to be a general-purpose "OpenPL" API. Would it be better to focus first on a Bullet-specific C API rather than assume the concepts are general? Or is Bullet the system on which to base such a standard?

For such an "OpenPL" API, I would think that there should a be a strong focus on support for the library as a dynamically-loaded dll/so. That is, if a hardware-accelerated version came in conjunction with specific hardware (as can be the case for OpenGL), then the application/game wouldn't be statically linked with it.

Therefore, I think such an OpenPL, for example, couldn't use concepts like plReal as a float vs. double. Rather, I would think the API would need consistent type sizes (perhaps with alternative function versions such as supported by OpenGL), and behind the scenes either floats or doubles (or other) might be used by the engine.

Some naming conventions might also best be changed slightly to look more like OpenGL-style naming. But I think this is less important than the better support for dynamic linking and type size expectations.

I think Bullet C-API can learn from PhysX. It would be great if Bullet C-API is compatible with commercial PhysX.

PhysX is proprietary, and compatiblity might not be allowed legally.

If we were to pick an existing C-API, I would pick the ODE API. Anything wrong with the ODE API? Actually I've done some basic test in the past, and got an incomplete ODE wrapper around Bullet, that could compile, link and run some of the ODE demos without any modifications.

One of the benefit from Bullet C++ API is extensibility and making it easy to customize inner workings, but people who don't care about that might want to just a C API like ODE.

What do you think? Are there important API features in PhysX, compared to ODE?

See also Daniel Price comment here: http://tinyurl.com/y9p33l8

"I keep using ODE because I like the API (it doesn't force an entire class hierarchy and math library down your throat - I have my own thanks)"

Here is my slightly improve C-API. I made it when I worked on a C# interface of Bullet 2.75 . The C# interface then being used in Matlab. The code consists of : Bullet (C# wrapper +C-API) + OpenTK + Matlab code. I've been using it to test ideas, theories in physical simulation.

I have created a revised Bullet-C-API. This revised version is able to easily interface with the Vala language and it's vapigen program: http://live.gnome.org/Vala

I have included a revised BulletDinoDemo.c for use with this revised C-API. As well as a version of BulletDinoDemo written in the Vala language as a MonoDevelop project.

Version Infos: Vala 0.11.2 , Bullet 2.77

The vala BulletDinoDemo (vBulletDemos) project was made with Monodevelop 2.4.0 in 32-bit Ubuntu 10.10 inside of Virtualbox 3.2.10 on Windows7 64-bit.

Updated bullet.vapi, Bullet-C-API

Hi Binh,

Thanks for the updated C-API. Aside from the additional new-lines (function name on a second line) it looks OK.

Don't you need a __declspec(dllimport), when linking against the import library for a DLL, as counter part of __declspec(dllexport), used at creation time of the DLL?

Hi Cessation, I rather not change all naming conventions. Was that necessary to bind it to Vala?

Might I ask what happened to aerique's contributions? They don't seem to have gotten committed.

Binding to Vala with .vapi file requires extremely specific naming conventions. So yes it was necessary, though perhaps the vapi definition is more flexible by now.

I'm not entirely sure how to proceed with this project. C and C++ are not something I am used to working in regularly, so this project was pushing my limits pretty hard. I stopped at the point of binding c++ vtables to C, which I would have gotten past. But the next step would have been to bind c++ events back to C code, which I did not see how to do. I would like to get back to this project in the future, if someone could point me at some information explaining how to bind c++ events back to C code.

My current project involves binding C++ code to Scala to use DirectInput and DirectX (using the NativeLibs4Java library). I am hoping the experience will make this project seem a little easier.

See https://github.com/bulletphysics/bullet3/issues/130