Real-Time Physics Simulation Forum

Here is how I would do it: Rather than apply impulse I would implement a custom "action" (e.g. derive UprightCharacterAction from btActionInterface) which behaves like an "angular spring" and slams the velocity of the character toward an upright position. The main reason I don't like to operate in i...

The shapeA-shapeB narrowphase collision algorithms are registered into a indexed array and called for the right parings. Box-box gets its own specific entry. Other pairings may fallback to more general purpose convexShape-convexShape algorithms, dunno for sure. I've chanced upon the relevant code du...

The box-box algorithm does not add the margin. For more info watch this youtube video.

No, our build configs are not the same.

I think I'm using Bullet 2.87. I copied most of your StovePipeDlg.cpp code into another project I had already had cmake build configuration all setup. I'm building on linux with g++ 7.4.0.

The enum values are powers of 2 and represent binary bits in a numerical value. Multiple modes can be enabled by setting more than one bit.

You were returning 3 = 1 + 2 which is both DBG_DrawWireframe and DBG_DrawAabb.

When I run it I get: d12 = -0.0800091 d21 = -0.0799984 These values seem close enough to me. The GJK algorithm is an iterative algorithm which must decide when to exit. Depending on its path through the Minkowski space it could take a longer or shorter path and end up with slightly different answers.

CollisionDebugDrawer::drawLine() takes a color argument which you appear to ignore. I would bet that if you actually use the color argument the bounding box will show up a different shade than the shapes. It probably represents the bounding box of the object in the broadphase, which I think can be ...

Yes, when using an axis-sweep broadphase you have to decide at construction time its bounds. The sweep algorithm usually quantizes the bounds of the elements inside, so it needs to know what are the world limits so it can set the quantization. This also means if you use Really Big world bounds then ...

hyyou 's idea does work fine if you don't need to pick up velocities from the moving parts. That is, if your rabbit is a slow statue and you want to be able to bounce fast balls off of its changing shape. The rabbit's leg, while changing position over time, won't have any inherent velocity to it so...

Reducing the substep is sorta equivalent to reducing the velocity. So I'm surprised your exploration of shorter substep duration didn't solve your problem. Maybe you didn't make it small enough? Theoretically, if the problem starts to vanish at 50 units/sec but you want the projectiles to move up to...

Does the animated thing need to "react" to collisions from other objects? Or should the animation continue unimpeded and only the other objects be affected? If the animated thing does NOT need to react to outside collisions then its collision shape could be approximated using multiple keyframed Rigi...

That is really strange. How fast are your spheres moving? What happens when your spheres move much slower (maybe disable gravity for that test). Or to put it another way: What happens when you enable continuous collision detection? I know you're using a C# wrapper, but in C++ it might look like this...

Thanks for the suggestion, but I already disabled the deactivation. Any other ideas? Ah yes, so you did. And I realize now: I should have actually watched your videos. It isn't that the objects stop outright, but that they sorta bounce around in place instead of advancing along the path. Your vibra...

You say the objects stop moving. Perhaps they are being deactivated by the simulation? One thing to try: flag the objects to never deactivate: body->setActivationState(DISABLE_DEACTIVATION) If the objects never stop moving then that is your problem: object deactivation because the objects aren't mov...

Yes, chains of constraints will do that: they can get "soft" at the ends, however usually only two or three constraints should be pretty stiff. The first thing to try, I think, is to reduce the substep duration in your simulation, if ammo.js allows it. The lower the better... although there is such ...