Unstable behavior using VehicleWrapper in blender 2.70 test build #38895

New Issue

Hugo Barreira · 2014-03-01T00:59:07+01:00

Hugo Barreira commented

2014-03-01 00:59:07 +01:00

System Information
Ubuntu 13.10
'GeForce GT 425M/PCIe/SSE2'

Blender Version
Broken: (Blender 2.69 (sub 11) Hash 10f4c62 , Blender 2.69 (sub 10) Hash 2038eb1 Linux:64bit)
Worked: (Blender 2.69 (sub 0) Hash 60991 , Blender 2.66 (sub 1) Hash 55252 Linux:64bit)

Short description of error
Works fine in previous versions, but the same file in the test build for 2.70 makes the wheels jump continuously

Exact steps for others to reproduce the error
add a 'Cube' add 4 Cylinders to use has wheels, rotate and aply rotation, make the apropriate logic brick to use the script(you may use the one provided in the blend file, add a 'plane' to use has a ground, change to game engine, set wheels to 'no collision' in the physics panel, the 'cube' to 'rigidbody'. Press 'p'. The 'vehicle should fall to the plane and stop. The behaviour seen in the newer version is that the wheels don't stop jumping.
Note: this behaviour happens with other values with different configurations(meshes, mass, sizes, etc)
I'm just providing this file has a test of the problem. Not sure if this is a bug or some change was made to the game engine physics to correct previous bugs and now this is the new expected behavior.
test_bug_270.blend
More instructions are in the blend file attached.

**System Information** Ubuntu 13.10 'GeForce GT 425M/PCIe/SSE2' **Blender Version** Broken: (Blender 2.69 (sub 11) Hash 10f4c62 , Blender 2.69 (sub 10) Hash 2038eb1 Linux:64bit) Worked: (Blender 2.69 (sub 0) Hash 60991 , Blender 2.66 (sub 1) Hash 55252 Linux:64bit) **Short description of error** Works fine in previous versions, but the same file in the test build for 2.70 makes the wheels jump continuously **Exact steps for others to reproduce the error** add a 'Cube' add 4 Cylinders to use has wheels, rotate and aply rotation, make the apropriate logic brick to use the script(you may use the one provided in the blend file, add a 'plane' to use has a ground, change to game engine, set wheels to 'no collision' in the physics panel, the 'cube' to 'rigidbody'. Press 'p'. The 'vehicle should fall to the plane and stop. The behaviour seen in the newer version is that the wheels don't stop jumping. Note: this behaviour happens with other values with different configurations(meshes, mass, sizes, etc) I'm just providing this file has a test of the problem. Not sure if this is a bug or some change was made to the game engine physics to correct previous bugs and now this is the new expected behavior. [test_bug_270.blend](https://archive.blender.org/developer/F79292/test_bug_270.blend) More instructions are in the blend file attached.

Hugo Barreira commented

2014-03-01 00:59:07 +01:00

Changed status to: 'Open'

Hugo Barreira commented

2014-03-01 00:59:07 +01:00

Added subscriber: @HugoBarreira

Hugo Barreira self-assigned this 2014-03-02 02:10:53 +01:00

Hugo Barreira commented

2014-03-02 02:10:53 +01:00

Just noticed that it's also broken in,
version 2.69 (sub 10), '2014-02-10' , hash '2038eb1', Linux:64bit
worked in
version 2.69 (sub 0), revision b'60991'.2013-10-29', Linux:64bit
version 2.66 (sub 1), revision b'55252'.'2013-03-14', Linux:64bit

Just noticed that it's also broken in, version 2.69 (sub 10), '2014-02-10' , hash '2038eb1', Linux:64bit worked in version 2.69 (sub 0), revision b'60991'.2013-10-29', Linux:64bit version 2.66 (sub 1), revision b'55252'.'2013-03-14', Linux:64bit

Hugo Barreira removed their assignment 2014-03-02 02:30:01 +01:00

Thomas Dinges commented

2014-03-02 18:39:07 +01:00

Added subscriber: @ThomasDinges

Inês Almeida commented

2014-04-17 08:24:57 +02:00

Added subscriber: @brita

Inês Almeida commented

2014-04-17 08:24:57 +02:00

I can confirm this with the current master.
This is assertion is failing:
blender-source/extern/bullet2/src/BulletDynamics/Vehicle/btRaycastVehicle.cpp:384:
void btRaycastVehicle::applyEngineForce(btScalar, int): Assertion `wheel>=0 && wheel < getNumWheels()' failed.

I can confirm this with the current master. This is assertion is failing: blender-source/extern/bullet2/src/BulletDynamics/Vehicle/btRaycastVehicle.cpp:384: void btRaycastVehicle::applyEngineForce(btScalar, int): Assertion `wheel>=0 && wheel < getNumWheels()' failed.

Mitchell Stokes commented

2014-05-16 01:10:27 +02:00

Added subscribers: @sreich, @Moguri

Mitchell Stokes commented

2014-05-16 01:10:27 +02:00

Sergej, you seem to be our resident Bullet expert. I have tracked down the issue to the 2.82 Bullet update. We are running into the issue mentioned in this thread: http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=9662. It seems prior to Bullet 2.82 the default btConvexCast for btCollisionWorld::rayTestSingleInternal() was set to btSubsimplexConvexCast via compiler prgamas (#ifdef, etc). However, in Bullet 2.82 btGjkConvexCast became the default.

So, my question to you is, should we force using btSubsimplexConvexCast, or do we try to figure out why btGjkConvexCast doesn't work for us? The following patch will force the BGE to use btSubsimplexConvexCast for its vehicles:
bge_vehicle_simplex.diff

Sergej, you seem to be our resident Bullet expert. I have tracked down the issue to the 2.82 Bullet update. We are running into the issue mentioned in this thread: http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=9662. It seems prior to Bullet 2.82 the default btConvexCast for btCollisionWorld::rayTestSingleInternal() was set to btSubsimplexConvexCast via compiler prgamas (#ifdef, etc). However, in Bullet 2.82 btGjkConvexCast became the default. So, my question to you is, should we force using btSubsimplexConvexCast, or do we try to figure out why btGjkConvexCast doesn't work for us? The following patch will force the BGE to use btSubsimplexConvexCast for its vehicles: [bge_vehicle_simplex.diff](https://archive.blender.org/developer/F89134/bge_vehicle_simplex.diff)

Sergej Reich commented

2014-05-16 13:25:47 +02:00

Using the old raycast method should be fine, we did that for #37673 as well.