Bullet C API (again)

[khubert]

So, I know there has been some interest in the Bullet C API from various people. I happen to be one of them. Is there a goal or direction with this project? I'm asking because I'm getting tired of ODE, for it's lack of continuous collision detection, and for it's poor heightfield performance.

After investing so much time in a C engine, it's hard to just switch to C++. I took a look at the Bullet-C-Api.h and Bullet-C-API.cpp, and there is some good work in there, but it's not complete. After implementing a few functions I needed, I've almost replaced ODE. (On a flat plane anyways, I need to do some more work to support everything I need).

This is all great, and I could certainly hoard the cool new C API, but who could I discuss things with if I wanted to A) give it back to Bullet, and B) make sure the things I implement adhere to spec.

Is there a spec? All the stuff I'm implementing has prefixes of pl. Much like the bt prefix in Bullet C++. Does this naming convention refer to OpenPL? Or are we looking solely at a Bullet thing? Is this the right forum/board for these questions?

[Erwin Coumans]

We can discuss here.

Bullet main API is C++, and not much further work has been done on the C-API, so you are very welcome to contribute.
Please check the BulletDinoDemo (if you didn't do already), and come with some proposal/patch. I don't think the C-API is used much, so your proposal is likely to be accepted.

I just created an issue to track the status, and to add patches:
http://code.google.com/p/bullet/issues/detail?id=43

Do you already have some proposal/patch to complete it further? And can you provide a demo, or improve the BulletDinoDemo?
Thanks,
Erwin

By the way, the pl prefix was indeed to allow other engines. But that effort is not very serious. If you really want to have multiple physics engine, I recommend PAL, and add a C-API on top of that.

[khubert]

OK, this is good. I would very much like to contribute, although to be honest, "when it works for me" is probably where I'll stop. What about modifying existing functions? Won't this adversely affect Blender? When I touch this API, do I need to touch Blender?

I've looked at the BulletDinoDemo, and it should be straight forward to write a couple of new demos. The demos will be in C, so is it OK if I just use glut, like Dino, instead of figuring out how to mimic the whole demo C++ rig? These will not be demos in the usual Bullet look and feel.

Thanks for opening the issue, I'll post the patch there.

As far as work already completed, I don't want to release my graphics engine, so I don't have a demo to provide yet. I just modified the Dino demo to test some changes, and used my engine for the rest. I could supply the patch for the C-API without a demo, although, you may not have a way to test random code I submit without one.

I liked the look of PAL, except for it's C++ interface, :) We'll keep the pl prefix, it's sturdy enough for now.

[Erwin Coumans]

It would be best if you just modify the existing BulletDinoDemo (which is already C), rather then creating new demos.

Is it necessary to modify existing C-API? We can discuss if needed.

Can't you just add new functions?
Thanks,
Erwin

[khubert]

First of all, the Dino demo is really not complex. What about impulses and velocity? Other shapes than a box? I'm presuming that we would want tests for them.

Secondly, it has not been necessary to modify the C-API. I'm just checking with you to get a feel for it, I don't know what I'll encounter. We'll bring it up if/when that occurs.

Thanks,
-Kyle

[Erwin Coumans]

First of all, the Dino demo is really not complex. What about impulses and velocity? Other shapes than a box? I'm presuming that we would want tests for them.

Feel free to make it more complex, add other shapes etc.

Secondly, it has not been necessary to modify the C-API. I'm just checking with you to get a feel for it, I don't know what I'll encounter. We'll bring it up if/when that occurs.

Did you already do some work on the C-API? You can attach some work-in-progress to the issue tracker in googlecode if you like.
Thanks, looking forward to see your contributions,
Erwin

[khubert]

Hi, Sorry about that. I actually ran out of the country for over a week right after we started our conversation. (And no Internet Access!) Bad form, I know.

Anyways, I uploaded the files into Issue 43. The only *important* question I have so far is, what is the UserPointer for in a btCollisionShape? This doesn't appear to be a *user* pointer like ODE, to let us tuck in an arbitrary pointer. It appears to be, but when I stick in random structs, strange things happen, like me bobbing through the ground plane like I'm on water.

A not so important question. We have defines and enums tucked around in C++ headers, which I can't include in a C file. Like Activation States and Collision Flags. Do you know of a way to ensure they don't randomly change out from under us? A compile time warning would be fine. This isn't that important if you don't know, I can look it up later.

Finally, I'm so far using my own game engine for testing. We can shelve the demo topic for another day.

[Erwin Coumans]

The only *important* question I have so far is, what is the UserPointer for in a btCollisionShape? This doesn't appear to be a *user* pointer like ODE, to let us tuck in an arbitrary pointer. It appears to be, but when I stick in random structs, strange things happen, like me bobbing through the ground plane like I'm on water.

m_userObjectPointer can contain any arbitrary user pointer, just like every other physics engine. If this doesn't work, there must be some issue in the C-API or demo. It would be useful to use the BulletDinoDemo, for testing new C-API features and reproduction of issues.

A not so important question. We have defines and enums tucked around in C++ headers, which I can't include in a C file. Like Activation States and Collision Flags. Do you know of a way to ensure they don't randomly change out from under us? A compile time warning would be fine. This isn't that important if you don't know, I can look it up later.

Good point, perhaps we should move them in separate headerfiles that can be included by both C++ and C projects. For now, please duplicate them in the C-API file.

Thanks for the contribution, we'll check it out,
Erwin

[abaraba]

hello everybody,

khubert,
can you say a bit about changes you made, are there any demos ready and whats the further plan?

>>"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..."

are you referring to the changes you did or you saying there is something wrong with C API, if so whats that?

--------------------

anyone,
what is/was the purpose of C API next to C++, how they compare?



thanks
http://www.geocities.com/ze_aks/myos.html