elchtest mod :)

[CrystalH]

It's ok now. (In that 2610 version I couldn't drive more than 20 seconds without ending flying in the sky).
But it required to lower center of mass for cars, because now they tend to flip more easily. The collision with walls is now also more realistic.
Anyway I managed to flip the car up side down, its like always - a dead end, flip button would be a good thing. Also slip sound is now the same on every surface.

All in one I would say that VDrift is the best car simulation (but the 1st place is occupied by Richard Burns Rally, still my favorite game).
The last thing (in simulation) that is bothering me, is the way that the collision of chassis is handled.
It's not dynamic, the car is not a dynamic body in world of bullet. This way you cannot properly interact with track nor with dynamic objects. It's just something like a character controller that cast rays and can only receive impulses form track or ground by chassis.
I know it would require for the car to use a dynamic body in bullet simulation not the body in VDrift. This would loose your own integration code, but would gain dynamic collisions from bullet.
Are there other reasons its not like that from the beginning of using bullet ? Are you planning this feature, or such dynamic behaviour when car is flipping (making multiple turns) or can interact (in both ways) with some dynamic objects on track ?

[NaN]

The slip sound comes from the latest surface modifications. The track mesh surface properties are used now. I haven't really looked into this code yet. So no idea how to fix.

As for physics, I'd go for bullet too. But that would mean to touch a lot of code(actually to replace current physics). I am new to vdrift so I've tried to avoid drastic code changes.

Is a physics rewrite a priority for vdrift users(except you and me)?
If you have a look at the issue tracker. There is a lot of other functionality to be implemented http://code.google.com/p/vdrift/issues/list

What I'd love to see is a most wanted features/bugfixes priority list. Maybe voted by vdrift contributors/users?

[joevenzon]

I fixed the slip sound in R2615.

[sebiastisch]

We are using the vdrift car physics for a simulation.

We are using bullet as basic lib and just decoupling the car physics, which are calculated by vdrift. actually this is not as easy, as it appears, because the way both engines update their states is very different. BUT you gain very easy integration of objects (also dynamic) and crashes are much more realistic. further you can drive on everything and don't need that complicated differentiation between track, other cars, etc. Even soft body integration could be pretty easy. There is also the possibility to throw away that ray cast down the car axis to calculate wheel collision, as one could use bullet cylinder shapes for that.

i guess, there are a lot of fun things you could add to vdrift with those options?! why not add an arcade style jumping and levels to a realistic racing simulation?

[joevenzon]

I think that's the way to go... use bullet dynamics for the car body integration (also allows you to make track objects like cones dynamic) and have the current VDrift physics engine compute additional forces to add to the body.

Moving to cylinder collision queries instead of raycasts for the wheels is a great idea (as long as it's fast enough) -- that could be done now, even before integrating with bullet dynamics.

[sebiastisch]

The problem is indeed the coupling of both.

Currently we are getting the velocities calculated from vdrift, stuffing them into bullet, which integrates them, adds collisions and constraints and then update the vdrift-car from that.

at first we also just wanted to take the bullet forces and add them in vdrift, but that didnt work out, due to the pipeline in bullet.

the question is how to get wheels and body synchronized, when the collisions of the wheels are calculated by bullet, but the constraints (suspension, ..) between both are in vdrift. there is also the question of how to set the wheel collisions correctly in vdrift. where is the " wheels cant dip into the surface" constraint modeled in vdrift?

The current solution starts to oscillate and ends somewhere in the sky or under the earth after some time...
OR you get a gummibear-car (when neglecting the constraints), which looks like an interesting game idea, but nothing like a simulation...

[NaN]

We could model the suspension in bullet too(hinge constraint and others). VDrift would provide the wheel torques(engine, brakes). The rigid body simulation would happen in bullet.

[sebiastisch]

I'd love that (as it would obviously help me a lot ), but i guess it is a lot of work to do. probably this would result in completely discarding the current physics...

[NaN]

I've been thinking about modifying vdrift to be able to plug btRaycastVehicle into it as a first step.

[sebiastisch]

To give you some details, what our intention is.
We need a simulation environment to develop and test autonomous cars.
We found vdrift to be a good base for that, as the consequences of actions can be much better evaluated than with current 2d- kinematic simulations.
Currently we use open scene graph for the graphics, which is synchronized with bullet by osgbullet. the vdrift physics are squeezed into the rigid body, which which will (hopefully) integrate cars seamlessly.
environment(or "tracks") will be given by 3d-Laserscans, which is a spin off of our SLAM algorithm.

So maybe, we can cooperate a little. I personally think, that vdrift is a very cool program!

[NaN]

I will try to hack btRaycastVehicle into vdrift asap. The next step will be to integrate vdrift tire friction model into it.

Hey Joe, how do you think about a bullet physics branch?

[joevenzon]

Yeah sure, branch it.

I have my doubts about how much of the car physics bullet will be able to handle, but it'd sure be cool if we could input suspension geometry and have bullet come up with reasonable behavior. Note that VDrift's car physics currently run at 1000 Hz, mainly due to the particularly stiff tire friction problem (longitudinal tire friction causing tire rotation).

[NaN]

OK, I think it's time for an update.

I had a closer look at bullet. The btRaycastVehicle is actually a simpler version of our current CARDYNAMICS code. It looks like the usual bullet simulation speed is about 60Hz(there are some guys running it at 1kHz). So I think it's not an option to run the tire simulation in bullet.

My current plan is to keep our current wheel/suspension code running at 1000Hz and run the chassis/world collision stuff in bullet at 60Hz. This would mean to apply averaged suspension/wheel forces to the chassis. I think it should be OK as there is no truly rigid chassis in the real world. It should be even possible to move the suspension simulation into 60hz bullet world. Let it act as a low-pass between wheels and chassis.

The new branch(no dynamics integration yet, will see if i find some time at the weekend):
http://svn.vdrift.net/viewvc.cgi/branche...oot=VDrift

Some interesting links:
http://docs.google.com/Doc?docid=0AXVUZ5...4Zmo&hl=en
http://bulletphysics.org/Bullet/phpBB3/v...b76fbc18db
http://bulletphysics.org/Bullet/phpBB3/v...it=vehicle

[NaN]

Hmm, there is an interesting problem. The wheels are geometrically constrained relative to car rigid body in the current code.
So I see two options at the moment. Allow the wheels to move relative to car and correct their position incrementally. Or keep the current chassis rigid body at 1000Hz and update btRigidBody velocity with 60Hz to fit chassis new velocity/position.

[sebiastisch]

Well I was by the time able to incorporate the vdrift car into the bullet world. I had to do some scruffy stuff (like inherit from btDiscreteDynamicsworld), because the normal bullet callback and action interface didn't give enough access.

this is how i "solved" it:
- i inherited my own carphysics class from btrigidbody.
- i overwrote predictunconstrainedmotion. if the rigid body is a car, it will be set forward in vdrift. i only use the rigid body velocities produced by vdrift and throw away the position/orientation. the internal car state (engine, suspension, ...) are updated though.
- bullet integrates those velocities, does collision checks, and updates the positions and velocities of the rigid body.
- i push back those rigid body velocities and state into vdrift to keep it in sync.
- when applying the set forward routine in my car physics class i update vdrift several times (as it needs a high update rate, although i didn't understand why exactly).
- car contacts are calculated in every vdrift tick by a ray routine (similar to the bullet vehicle) on the bullet world. (i still want to replace that). I already modeled the wheels as rigid body. but they are still part of the internal model.

so what is possible with that?
you can drive on very hilly terrain, insert bullet objects (the number almost doesn't matter for the performance) , kick them around and get feedback on the car. new cars can be added by inserting my class into the bullet world. jumping is not very realistic because of the way wheel collisions are calculated.

tire position is still a mess. after some time, the getwheelorientation/position functions give me very strange results (sometimes leaving a wheel behind or the orientation is totally wrong).

but i am not sure, if this is of use for you. despite of the nicer interface bullet offers, i can't see a lot of advantages for you.

perhaps you can give me some advice for the cylindershape wheel contact calculation. as i will do for our simulation anyway, i can help adding it to vdrift, too. should i use the SetWheelContactProperties function then, too?