You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by pasqualemilano February 19, 2024
Hi, this is the first time I post here:
I've been working with bullet for some time, I use it for testing some parcel behavior running on Conveyor belts:
I already read and follow suggestions from forum (something like: https://pybullet.org/Bullet/phpBB3/viewtopic.php?t=6730) and engine work well.
Recently I found out a really weird case, which seems more like a bug than a my code error.
In this explanation I'll try to simplify as much as possible:
As I told before, standard belts with bullets work fine.
Then I try to use a belt applying a drift angle, and again everything works fine.
In the following image there are two belts with drift angle and no drift angle: the behavior is exactly what I expect:
Then I try to simulate TWO drift belt that works in opposite drift, at the same speed and a parcel on it exactly on the middle:
The combined speed result faster than the speed applied.
I also check if negative drift can mess up something, but working exactly like positive drift.
Then I Ask to a friend to recreate the same case on a commercial software that use the same bullet engine: "Emulate3D" (actually the screenshot are from that software, is very simple generate a similar case): again the same problem.
This commercial software handle different engines, so we switch to another one and... the problem disappeared!
I search into open issues if there is something related but I didn't find anything.
This seems happen when the set of btManifoldPoint of the same rigidbody has different and partially conflictual direction (m_lateralFrictionDir1)
I can show you my code (that is inspired to the code suggested in the link that I wrote at the beginning of the post) but after the last "external" test I start to exclude the coding error and think about the engine bug.
Anyway I am available for any clarification.
thanks
The text was updated successfully, but these errors were encountered:
Discussed in #4577
Originally posted by pasqualemilano February 19, 2024
Hi, this is the first time I post here:
I've been working with bullet for some time, I use it for testing some parcel behavior running on Conveyor belts:
I already read and follow suggestions from forum (something like: https://pybullet.org/Bullet/phpBB3/viewtopic.php?t=6730) and engine work well.
Recently I found out a really weird case, which seems more like a bug than a my code error.
In this explanation I'll try to simplify as much as possible:
As I told before, standard belts with bullets work fine.
Then I try to use a belt applying a drift angle, and again everything works fine.
In the following image there are two belts with drift angle and no drift angle: the behavior is exactly what I expect:
Then I try to simulate TWO drift belt that works in opposite drift, at the same speed and a parcel on it exactly on the middle:
The combined speed result faster than the speed applied.
I also check if negative drift can mess up something, but working exactly like positive drift.
Then I Ask to a friend to recreate the same case on a commercial software that use the same bullet engine: "Emulate3D" (actually the screenshot are from that software, is very simple generate a similar case): again the same problem.
This commercial software handle different engines, so we switch to another one and... the problem disappeared!
I search into open issues if there is something related but I didn't find anything.
This seems happen when the set of btManifoldPoint of the same rigidbody has different and partially conflictual direction (m_lateralFrictionDir1)
I can show you my code (that is inspired to the code suggested in the link that I wrote at the beginning of the post) but after the last "external" test I start to exclude the coding error and think about the engine bug.
Anyway I am available for any clarification.
thanks
The text was updated successfully, but these errors were encountered: