bullet dynamics

[NaN]

The bullet branch has reached a usable state now.

Checkout and test: http://svn.vdrift.net/viewvc.cgi/branche...oot=VDrift
For Windows users: http://uploading.com/files/28e4225f/VDrift.zip/

Features:
- Bullet simulates car chassis collisions now.

Bugs:
- Simulation is frame rate dependent
- The game runs slower(stresses the cpu). I am polluting the broadphase with collision objects.

Todo:
- Run the simulation at a fixed time step (60Hz).
- Batch track geometry into a single collision object.
- Add wheels as collision objects.
- Move suspension into bullet.

[portets]

i get:

Code:

In file included from src/car.cpp:7:
include/tobullet.h:7:34: error: LinearMath\btVector3.h: No such file or directory
include/tobullet.h:8:37: error: LinearMath\btQuaternion.h: No such file or directory
include/tobullet.h:9:36: error: LinearMath\btMatrix3x3.h: No such file or directory
scons: *** [build/car.o] Error 1
scons: building terminated because of errors.

looks like it can't find a bullet directory?

edit: in "tobullet.h" i changed the back slashes to forward slashes and it compiled.

[NaN]

Oops, fixed in 2639.

[joevenzon]

Seems to work quite well already. Nice job!

[NaN]

Track geometry is a single collision object now(rev 2641). I looks like it's even a bit faster than the old vdrift code. I didn't do any profiling though.

I am looking for volunteers to test the new implementation with the tracks we have.

Windows build: http://uploading.com/files/mmb8m447/vdrift.zip/

[joevenzon]

Right now VDrift uses bezier surfaces to model a smooth track surface:
http://wiki.vdrift.net/Image:Track-smoothing.png

Does bullet support curved surfaces?

[NaN]

No support for curved surfaces in bullet. So we would have to do it by ourselves. This is a serious showstopper for cylinder wheels.

I've been thinking about a bounding sphere approximation.

This means solving a fifth order polynomial(point-patch distance) and rejecting the contact point(fall back to bullet) for certain wheel to surface angles(as the wheel is not a sphere).

An alternative would be to drop the patches and interpolate the track mesh normals to get a somewhat smooth surface.

[NaN]

Bullet runs with 60Hz, cardynamics with 10*60Hz now(rev 2642).
I think we could add a menu option to allow the user to set the simulation rate.

Windows build: http://uploading.com/files/347dm377/vdrift.zip/

Edit:
Oops rev 2642 is broken. Looks like a synchronization issue.
For the game running at 23fps we have 60/23 = 2.6 bullet steps per frame. This means two bullet steps(20 cardynamics steps) plus a 0.6 interpolation. I am not sure how bullet interpolates the next step. But as it is not precalculating the next step cardynamics will be wrong(not taken into account).

[zimluura]

I've been thinking about a bounding sphere approximation.

i'm a little out of my depth here, but don't tires always deform enough to have a flat rectangular contact patch with the road?

[NaN]

Yes, real tires do have a contact patch with the surface. There are also tire models taking this into account(google "dynamic tire friction").



VDrift is using a steady-state point-contact tire model. Steady-state means it is correct for constant velocities and wrong for acceleration. Point-contact means we do not integrate over a tire contact patch to get the friction forces.

In VDrift the contact point is determined using wheel rays. To be honest I am not sure if using rigid body cylinders here is actually an enhancement. You will still get a single contact point from bullet(bullet is a rigid body simulation so no contact patches here). This single cylinder contact might jitter over the whole cylinder width as the contact of a cylinder on a plane is a line segment. I think bullet caches/reuses previous contacts to stabilize this.

Another problem are the bezier patches VDrift is using. There are ways to calculate a ray patch intersection(VDrift is using this). It should also be possible to determine the distance of a point to a patch(sphere patch intersection test). But I have no idea how to test for a wheel shape bezier patch intersection.

[joevenzon]

Another option is to tessellate the bezier surface into a high poly mesh and use bullet's normal collision methods. The question is how much tessellation is necessary, and will bullet still perform fine with it tessellated at that level.

[sebiastisch]

Hi,

that is a very cool development there on the physics!
I think there are a lot of people interested in a real (open source) driving Simulation.


I'm not sure, whether you need interpolation with the cylinder. If you take the average collision point (like I do in my version), you already perform some kind of interpolation. (see the image)

(although i am not using the correct distance yet, when combining the points)

When you don't want the collisions to be spread over the whole cylinder width, just give it width zero. But it actually works better with the correct width. the points are most of the time on the outer/inner part of the wheel depending on the suspension settings.
It is especially better, when the car is not aligned to the ground (i.e. on slopes or when jumping, etc.). you can never get correct results with one ray.

When I am back from travel, I'll implement a version into NaNs bullet code. BTW: using several collision Points even allows to approximate a patch, when the cylinder is a little bigger than it has to be (which resembles the push in). that of course does not work in the example in the image above.

One last thing:
I tried a bounding sphere, but it did not work at all. the problem is (at least iI think that is the problem), that when the collision is not in the lowest point (in car coordinates) the point goes up.

[NaN]

I think I've got a solution for the bezier patch problem. We could create a ray from the cylinder contact point and use it to determine the contact point on the bezier patch.

[joevenzon]

What direction would the ray point?

[NaN]

The ray would go through the contact point in the negative contact normal direction.