Real-Time Physics Simulation Forum

Hi,
long time lurker and first time poster

I have a few questions regarding pybullet and how it can be used with the recent C# bindings that make it possible to connect to a Bullet server within the Unity3d game engine, makes for interesting possibilities!

1) If we wanted to simulate collidable terrain, would we have to generate the geometry elsewhere and import it as a mesh to then generate colliders? Would that be extremely slow to simulate in a large environment? Is there a better solution to create collidable terrain with pybullet?

2) Are there any known drawbacks or bottlenecks when using pybullet in terms of performance? I'd presume the simulation aspect is as fast as Bullet can be, as it's on its own server, however concerns are around the time it takes to talk between server/client and whether we'd be better off implementing Bullet directly (which would most likely imply moving away from Unity3d)

3) I'm mostly interested in pybullet because of its multiBody approach, as well as all the machine learning and robotics stuff, which tie in perfectly with a game design prototype we'd like to work on, however I'm wondering if implementing Bullet directly, and not using pybullet, is a more reasonable approach, not clear however how much of the machine learning and AI stuff belongs to pybullet and how much is part of the latest Bullet itself.

Any feedback would be highly appreciated!

Because no one answer ...

I am pretty sure that C++ Bullet is faster than its derivatives.

In practice, especially game, C++ itself is generally faster than python.
It is a reason that I lack knowledge to answer most of your questions.

patrick_c wrote: ↑Wed Nov 01, 2017 12:22 am Hi,
long time lurker and first time poster

Welcome!

I have a few questions regarding pybullet and how it can be used with the recent C# bindings that make it possible to connect to a Bullet server within the Unity3d game engine, makes for interesting possibilities!

1) If we wanted to simulate collidable terrain, would we have to generate the geometry elsewhere and import it as a mesh to then generate colliders? Would that be extremely slow to simulate in a large environment? Is there a better solution to create collidable terrain with pybullet?

Possibly, but why would it be slow? pybullet is all C++ under the hood, using acceleration structures. We can add some optimizations if needed, preloading or streaming large worlds if there is strong demand or a pull request.

2) Are there any known drawbacks or bottlenecks when using pybullet in terms of performance? I'd presume the simulation aspect is as fast as Bullet can be, as it's on its own server, however concerns are around the time it takes to talk between server/client and whether we'd be better off implementing Bullet directly (which would most likely imply moving away from Unity3d)

You should be able to use any graphics engine with pybullet. If synchronization of rigid body transforms becomes a bottleneck (unlikely but possible), we can work on that.

3) I'm mostly interested in pybullet because of its multiBody approach, as well as all the machine learning and robotics stuff, which tie in perfectly with a game design prototype we'd like to work on, however I'm wondering if implementing Bullet directly, and not using pybullet, is a more reasonable approach, not clear however how much of the machine learning and AI stuff belongs to pybullet and how much is part of the latest Bullet itself.

It is a large amount of work reproducing all the pybullet / URDF to btMultiBody robotics/RL features, so why not evaluate it first?
pybullet is all written in C/C++ and the idea is that synchronizing between C++ and python/C# is not too frequent/costly.
All pybullet features are also exposed through the C-API.

I think it would be great if we had pybullet vs bullet benchmarks to show people the performance differences. I can take a stab at it.

PyBullet uses Bullet C++ under the hood. As long as you don't use many python calls before/after each 'stepSimulation' performance should be the same. Note that PyBullet is configured for VR, robotics and RL by default, with a small timestep (1./240) and a large number of solver iterations (50) by default. You can configure this to be similar to regular game settings (60 Hertz, and 10 iterations).