Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conveyor belts and combined drift speed: wrong speed result #4581

Open
pasqualemilano opened this issue Feb 21, 2024 Discussed in #4577 · 0 comments
Open

Conveyor belts and combined drift speed: wrong speed result #4581

pasqualemilano opened this issue Feb 21, 2024 Discussed in #4577 · 0 comments

Comments

@pasqualemilano
Copy link

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:
sample1
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:
sample2
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!
sample3

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant