Hi, I'm trying to fix physics in openrw. Actually we have two problems:
- high velocity cars can clip through world geometry
https://github.com/rwengine/openrw/issues/76
- weird work of suspension, actually we have tuned susp length, sitffness and max travel to make feel of riding maximal possibly real. But level of stiffness is to high. It's easy to flip vehicle. With reduced level of stiffness and optimal max travel; susp length, wheels are sinking.
topic: https://github.com/rwengine/openrw/issues/416
two main files with physics :
https://github.com/rwengine/openrw/blob ... stance.cpp
https://github.com/rwengine/openrw/blob ... Object.cpp
Example of problem: https://youtu.be/m87bJxE9hnU?t=2m50s
I will be grateful for help.
Btw. running openrw requires gta3 assets I have one steam key for gta if you want to try to test it.

Rolling at speed is realistic real cars use complex designs to fight it, such as Anti sway bars and keeping the centre of gravity as low as possible. In arcade games like GTA3, they actually used the physically impossible solution of making the centre of gravity below the car itself (about 2m under the road if I remember correctly)... 

Moving the center of gravity is a bit of a pain in bullet though. You can't just set the CG of a box shape by itself. IIRC, you have to add the box shape to a compound shape, where the compound is now the CG, and you can offset the box relative to it.

To stop the suspension "collapsing", make sure that the top of the wheel ray-cast is inside the vehicle chassis collision box (and the rays are set to ignore that body). 

As for tunnelling... Bullet sucks for high speed collusions with polygon meshes. It only has a very simple CCD solution that doesn't solve this. When I was using bullet for my racing game, I ran the physics at a fixed 600Hz update rate to reduce the problem.

4 hours ago, Hodgman said:

Bullet sucks for high speed collusions with polygon meshes.

Do you happen to know any Physic Engine that is not bad in such situation?

11 minutes ago, hyyou said:

Do you happen to know any Physic Engine that is not bad in such situation?

I switched to PhysX. Gor high-speed box vs trimesh collisions (vehicles at 500kmh), it's producing better results at 60Hz than bullet was at 600Hz...

4 hours ago, Hodgman said:

I switched to PhysX. ....

Thank Hodgman!  

Are there any feature of Bullet that you like but not exist in PhysX (except those related to legal/license/fee)?

Did you use much time to port your code from Bullet to PhysX?

On 4/30/2018 at 2:48 PM, hyyou said:

Are there any feature of Bullet that you like but not exist in PhysX (except those related to legal/license/fee)?

Did you use much time to port your code from Bullet to PhysX?

Bullet supports two sided triangle meshes, and a neat sphere-hull shape that I liked. Going the other way, PhysX supports defining the centre of gravity per body, and has better threading support. 

I ended with a #define that lets me pick between them at compile time though, so everything I use is supported by both (with workarounds in some cases). I think it took me a few weeks to do the port. 

On 4/30/2018 at 6:04 AM, hyyou said:

Do you happen to know any Physic Engine that is not bad in such situation?

Newton has a very accurate vehicle simulation that works at 60 Hz, see the demo sandbox: https://github.com/MADEAPPS/newton-dynamics/releases

Initially i used a common wrapper over both Bullet and Newton, so switching physics engines should not be much work. After some time i dropped bullet because it can't compete neither with performance nor accuracy for me.