Should we wrap only pybullet or the complete bullet3 API

[jice-nospam]

I'm creating this issue to discuss this subject and see how / if we can do something else.

I'm looking at the btCharacterControllerInterface which is exactly what I've been trying to do for weeks in my current project. Looking at the implementation, it requires much more low-level API than what pybullet provides.

pybullet is ok as long as you only need to apply impulse/torque to your game entities. It's perfect for car/tank games but not sufficient for fps/platformers where some entities does not behave in a physical realistic way.

On another hand, most of bullet3 API is object oriented C++. I'm not sure whether it's possible to wrap it...

[not-fl3]

It looks that we are working on very same kind of games! :) Check videos of nphysic's version https://twitter.com/BringerShar. So I am highly interested in exactly the same things - character controller, motion states etc.

Generally, there are two options:

Use C API

Find some existing C API

Most of the projects found are legacy, support only bullet 2 and only subset of methods. For example, https://github.com/rweichler/bullet_luajit/blob/master/bullet_wrapper.cpp or https://github.com/dfelinto/blender/blob/master/extern/bullet2/src/Bullet-C-Api.h

Made our own C API

Reimplement PhysicsClient with our own abstractions. As for me - is the most interesting idea.

Maybe combine that two ways - found some C API and start building our own on top of it. The problem here - we will loose that fancy bullet's visualiser, networking and upstream fixes from bullet's team. Advantages - we may use whatever we want with low overhead and build abstractions we want.

Use PhysicsClient

Maintain our own fork of bullet3

For instance - we can add CharacterController methods as a commands to PhysicClient's command processor.

Somehow interact with bullet's maintainers and make pull requests to upstream bullet.

https://github.com/bulletphysics/bullet3/issues/1328 check this issue for my initial conversation. As far as I undestand the situation - pybullet is built for robots and is not really intrested to give full API to bullet :(

Its really hard to decide, and maybe I am missing some alternatives, so any opinions highly welcome! My plan for now - extend PhysicsClient and build bindings on top of it. And if I'll find some really nice better way - switch to it.

[not-fl3]

Just as an idea - maybe its possible to call c++ directly somehow. https://github.com/rust-lang-nursery/rust-bindgen/blob/master/book/src/cpp.md. No experience with c++ bindgen.

[jice-nospam]

Form my experience, wrapping C++ is a nightmare whatever road you choose. c++ compilers don't event have the same mangling conventions.

Building a C API from scratch or extending the PhysicsClient API seems a lot of work.

At that point, I'm investigating switching to Open Dynamic Engine that has a complete C API https://www.ode-wiki.org/wiki/index.php?title=Manual:_All&printable=yes It looks like a rust wrapper would be easier to do with ODE (it already has a python wrapper)

Is there a reason to stick with bullet?

[not-fl3]

Bullet is in active development while ODE is not (as far as I know for about 10 years). That is why I want to build bullet wrapper - its performant, modern, supported and feature-full.

[h4yhay41]

I would personally use bullet3 API

[jice-nospam]

Actually ODE is still quite active here : https://bitbucket.org/odedevs/ode but I have no preference as I have few knowledge of both engines.

According to bullet's main readme, they're moving from bullet2 to PhysicsClient API. Not sure if bullet3 low level API is safe / stable enough to wrap. I would agree with Fedor on the fact that the safest way is probably to build our own C API on top of low level bullet3. This API should be written in a way that makes it easy to wrap it with other languages (i.e. avoid use of pointers and structs in parameters and rely heavily on integer handles)

[not-fl3]

I tried bindgen on bullet's headers and its working pretty well. Calling bullet's method directly just as they are in bullet's docs sounds really interesting!

[not-fl3]

But before switching to bindgen or something like this I should reach the point of complete disappointement in PhysicsClient idea. While I still have some hope on it..

[not-fl3]

Asked a direct question to origin bullet3's issue: https://github.com/bulletphysics/bullet3/issues/1328#issuecomment-339654060

[not-fl3]

Check the answer here: https://github.com/bulletphysics/bullet3/issues/1328#issuecomment-339688290

We may try to implement plugin for character movements just to check how smooth that ways works. Also, I am going to continue experiments with bindgen, I personally am really into calling just raw c++ methods.

[jice-nospam]

ok nice. We have a path! Let's follow it :)

2017-10-26 17:40 GMT+02:00 Fedor Logachev notifications@github.com:

Check the answer here: bulletphysics/bullet3#1328 (comment) https://github.com/bulletphysics/bullet3/issues/1328#issuecomment-339688290

We may try to implement plugin for character movements just to check how smooth that ways works. Also, I am going to continue experiments with bindgen, I personally am really into calling just raw c++ methods.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/not-fl3/bulletrs/issues/11#issuecomment-339708007, or mute the thread https://github.com/notifications/unsubscribe-auth/AHcbDxAOVJYSK7FYRgX6LzYFY_DJYERmks5swKfXgaJpZM4QEFvA .

[not-fl3]

https://github.com/not-fl3/bulletrs/blob/bindgen/tests/bindgen.rs bullet's tutorial is working well!

[not-fl3]

https://github.com/not-fl3/bulletrs/blob/bindgen/examples/sphere.rs and more rusty version :)

[not-fl3]

Decision made, code migrated. Closing issue now.