Car wheels behaviour looking strange

[jose1711]

Look and especially the behaviour of wheels on the cars is a bit unnatural. Looking at a random video of yorg on youtube this may be something only my system/configuration is suffering from. Anyway, video is worth thousand words..

https://user-images.githubusercontent.com/1406222/103159333-8e380780-47c8-11eb-8598-813a3602da55.mp4

Latest master, Xorg, Arch Linux 64bit, GPU: Nvidia 750Ti with closed-source driver

[cflavio]

Hi! Hmm, unfortunately, I can't replicate the issue. I tested on my computers and I can't observe it, sorry. In order to isolate the issue, do you observe it if you try a build from me? Thank you very much!

[rdb]

Perhaps you are using an outdated version of Panda3D? Some time ago there were some fixes to the BulletVehicle wheel synchronization.

[jose1711]

Hi! Hmm, unfortunately, I can't replicate the issue. I tested on my computers and I can't observe it, sorry. In order to isolate the issue, do you observe it if you try a build from me? Thank you very much!

Happy to report there are no such issues when I try your binary build.

[jose1711]

Perhaps you are using an outdated version of Panda3D? Some time ago there were some fixes to the BulletVehicle wheel synchronization.

Same issue with latest Panda3D (1.10.8)

[cflavio]

Ok, the build that works is made with the official Panda3D's SDK (1.10.7, since 1.10.8 was not available some days ago), and it uses Bullet 2.84. In the page you linked in the other issue, it looks like you are using a newer version of Bullet. I am wondering if something has changed there.

[jose1711]

I downgraded bullet to 2.89 and recompiled Panda3D 1.10.7. The problem is still there though.

[cflavio]

Hi! I've tried it on Manjaro (installed and upgraded today), and it works for me. Here is the build that I've just done on Manjaro. Does it work for you? (if it doesn't start, it may be that some options are incompatible with this build - since I have removed some tracks and cars for building it fast - if this is the case, please remove ~/.local/share/Yorg/options.json)

[jose1711]

Thank you @cflavio, this build works fine too. But like before - this one is using local libraries (Panda3D, bullet..) not the system ones. Maybe the difference is in the compilation options of these libs?

[cflavio]

Actually, I use the Bullet library provided by Panda3D (and I think I should exactly use/support it :) ). Your version should be misaligned. What is happening should be a behavior introduced by a Bullet's later version. I know that package managers provide their dependencies for the applications they deploy, but it is not uncommon to see games that deploy their versions of libraries (it has several pro and cons). Couldn't you to use Panda3D's version of Bullet? Thanks!

[jose1711]

Couldn't you to use Panda3D's version of Bullet?

Please can you help me how to compile one? If bullet is not installed at the beginning of Panda3D compilation then it seems to not be compiled in.

[cflavio]

Hi! Before trying this, please double check if the Bullet version that you're using is different than the Panda3D's one. In order to verify this, please launch your build, then check in the file ~/.local/share/Yorg/p3d_log.log the line which contains bullet version: if your version is different than 284 then you're actually using something different. Please note that I'm not sure that the misalignment is the culprit here, but it may be.

Then, if the version is actually different, then you may try to recompile it. I've always used the version which comes with Panda3D, so I never recompiled it. Anyway, I think that here is where the Bullet's magic happen, so you should find there the info you need.

I don't know the exact process that you are following for you build, so I don't know where a replacement for the library may be forced, or if an external library may be deployed as an application's asset. Thank you once more for your efforts here!

[jose1711]

Hello and thank you for your reply. I compiled bullet 2.84 today + recompiled Panda3D 1.10.8 and guess what.. the wheel issue is gone. :sunglasses: Now that would mean there is something going on between bullet 2.84 and 2.89 which is causing this misbehaviour. I will try to narrow this down to the difference between adjacent versions.

Update: Turns out that 2.87 is the last version working fine. Since 2.88 I am seeing the wheel problem. There are 1327 commits between 2.87 and 2.88 but since it takes more than an hour on my computer to compile both bullet and consequently Panda3D I am not planning bisecting.

[cflavio]

Thank you for your investigation! Starting from it, it looks like this may be the commit that changed the behavior. I've recompiled Bullet and Panda3D reverting that commit (i.e. applying the following patch) and the original behavior seems restored (tested with Bullet 2.89, Panda3D 1.10.8 and up-to-date Manjaro).

Unfortunately, I couldn't find a workaround in my code for having a correct behavior with their update. I've double-checked the axles of the wheels and everything seems correct on my side (and indeed it has worked so far). So, the only way that doesn't use Panda3D's Bullet lib seems patching Bullet, then recompile it and Panda3D.

I presume that when Panda3D will offer a version of Bullet >= 2.88 we can observe if this issue will impact other Panda3D projects or if it is something that affects only my project. So, I presume that the easiest way (right now) is to temporarily patch Bullet.

diff --git a/src/BulletDynamics/Vehicle/btRaycastVehicle.cpp b/src/BulletDynamics/Vehicle/btRaycastVehicle.cpp
index fc70d8e63..a207b757f 100644
--- a/src/BulletDynamics/Vehicle/btRaycastVehicle.cpp
+++ b/src/BulletDynamics/Vehicle/btRaycastVehicle.cpp
@@ -109,18 +109,11 @@ void btRaycastVehicle::updateWheelTransform(int wheelIndex, bool interpolatedTra
    btQuaternion rotatingOrn(right, -wheel.m_rotation);
    btMatrix3x3 rotatingMat(rotatingOrn);

-   btMatrix3x3 basis2;
-   basis2[0][m_indexRightAxis] = -right[0];
-   basis2[1][m_indexRightAxis] = -right[1];
-   basis2[2][m_indexRightAxis] = -right[2];
-
-   basis2[0][m_indexUpAxis] = up[0];
-   basis2[1][m_indexUpAxis] = up[1];
-   basis2[2][m_indexUpAxis] = up[2];
-
-   basis2[0][m_indexForwardAxis] = fwd[0];
-   basis2[1][m_indexForwardAxis] = fwd[1];
-   basis2[2][m_indexForwardAxis] = fwd[2];
+   btMatrix3x3 basis2(
+       right[0],fwd[0],up[0],
+       right[1],fwd[1],up[1],
+       right[2],fwd[2],up[2]
+   );

    wheel.m_worldTransform.setBasis(steeringMat * rotatingMat * basis2);
    wheel.m_worldTransform.setOrigin(
@@ -522,7 +515,7 @@ void btRaycastVehicle::updateFriction(btScalar timeStep)
                const btTransform& wheelTrans = getWheelTransformWS(i);

                btMatrix3x3 wheelBasis0 = wheelTrans.getBasis();
-               m_axle[i] = -btVector3(
+               m_axle[i] = btVector3(
                    wheelBasis0[0][m_indexRightAxis],
                    wheelBasis0[1][m_indexRightAxis],
                    wheelBasis0[2][m_indexRightAxis]);

[jose1711]

Heh, it's you who did all the detective work. Thinking about it.. do you think it may be worth raising an issue at https://github.com/bulletphysics/bullet3/issues?

[cflavio]

To be honest, I don't know that portion of code deeply, so I can't have a personal opinion about its correctness. We should obtain an opinion by someone who knows that better. Anyway, in order to open an issue there, we should provide a minimal example that shows that it doesn't work (since this project has too many layers in between that may interfere).