Bold ideas for our physics engine

[marsch84]

1. When the car is rolling back for some reason and I engage the engine to move forward the car suddenly stops and suddenly jumps forward. It is nice however that it also reflects that motion with obvious pressure on the suspension. This gives it a great realistic touch. Nevertheless this sudden change doesn't feel right.

I think one reason for this behavior was, that there was bug in the previous version, that caused only the non-driven wheels to brake. I fixed it and the braking should be more balanced now.

1. Hitting trees and other vegetation now actively pushes back. For that reason it feels more like the bouncers in a pinball machine than just physical obstacles.

Do you have an example track on which you see this effect? The underground has some effect on the crash behavior. As far as I understand, the problem is more the linear reaction (away from the obstacle) and not so much the angular effect (spinning of the car).

1. Steering is somewhat mushy on gravel but practically impossible on tarmac. (For exampe in the single race map "Jumpy" I still can not get the car to steer in the direction I want because it keeps being locked to one or the other extreme steering position without middle ground and very high resistance to changing direction.)

I tested the track with the latest suspension settings and it is quite fun to drive. Do you think the handling on this track is OK in the latest version?

1. Driving on ice and snow has surprisingly little effect on the physics.

I think this depends a lot on vehicle tuning. Especially the line of code I mentioned has a huge impact. If you lower the parameter 1.8 to a lower value, the ice might become more slippery. Maybe you also see an improvement with the latest suspension settings.

vehicle->getWheelInfo(i).m_frictionSlip = 1.8f * mf_coef * (1.0f - 0.5f * damage);

As promised I attached the source code of the new version. In general all vehicles are drivable in this version. There is just one hint. The parameter "fineffect" is used by the Fox cars and has a negative impact on stability. Please remove the it from the vehicle files of the Fox cars before testing them.

Vehicle parameters are the next big topic in my opinion. Many existing parameters do not fit the vehicle model from Bullet and are not required any more. On the other side, there are new parameters introduced by the new model that are hard-coded right now and that should be moved to configuration files. Farrer developed a new format for the vehicle files which I think is a good start. You can find an example at the link below. Once we decide to go ahead with Bullet, I will take over Farrer's implementation, so that we can start tuning the vehicles on this base.

https://github.com/farrer/trigger-rally-bullet/blob/master/data/vehicles/cordo_kitcar/cordo_kitcar.vehicle

[Onsemeliot]

Unfortunately the impossibility to steer specifically at low speeds persists. In most maps ("Lab Rally" for example) I can't possibly stay on course. Each time I try to correct the orientation of the vehicle the car takes ages to actually accept that I am steering into the other direction than the wheels are locked into. This leads to the effect that I only can get forward by driving in ridiculous meanders on the road because the wheels will only accept full steering on to the other direction and only when I the car is already perpendicular to the road again.
When I get to slow in "Snowdrift" I experience the same problem. In addition I was placed under the landscape when I pressed "q" to reposition at the last checkpoint. It seems like the vertical coordinate position isn't used and therefore the car falls downward under the landscape after re-positioning. And I can't do anything about it. Probably the height positioning of the last point on the road is used instead of the height positioning of the last checkpoint. (And the horizontal car orientation isn't adapted to the orientation of the last checkpoint either.)
With the old physics engine the car would slow down when I hit some bushes or even grass because the resistance of those objects wasn't enough to actually bring the car to a halt. Now the car just spins like on ice instead.

But the car speedometer values look much more reasonable to me finally even if the kit cars are rather slow.

[marsch84]

I can reproduce the problem with the reset triggered with the "q" button. I suspect, that the vehicle collides with the terrain from below. Objects in Bullet can be made non-colliding for a certain time, so I assume this easy to fix.

The point with the strange crash behavior and the non-driveability on the maps "Lab Rally" and "Snowdrift" is really confusing to me. I can definitely not reproduce the bouncy crash reaction and the two maps are really easy drive on.

Since you had the problem with the wheel turned inside-out I assume you might have a different version of Bullet than me. Maybe the version 2 and 3 of Bullet lead to different reactions of the objects. Can you please let me know which version of Bullet is installed on your machine?

On Debian-based distributions you can find this out through the following command:

apt search -n libbullet-dev

This provides the following output on my computer:

libbullet-dev/hirsute,now 3.06+dfsg-4build1 amd64  [installiert]

[Onsemeliot]

Indeed, Debian Buster has by default an older version:

libbullet-dev/stable,now 2.87+dfsg-3 amd64 [installed]

Fortunately, a new Debian version will be released very soon.

The problem with steering seems to be more related to the speed than to the map. If I can manage to speed up somehow then the problem gets weaker. But if I drive slower than 40 mph it is almost impossible to progress in the direction I want to go because the wheels lock into one of two extreme steering positions and can only be switched between those suddenly and after long and hard pressing the arrow buttons.

[marsch84]

Yes, that is an older version. That definitely explains why the wheels were inside-out on your side, as there was a change in the Bullet vehicle code affecting this point in between our two versions.

I will try to install 2.87 on my machine and check, if I can reproduce the odd driving behavior you observe.

[marsch84]

I attached a new version of the source code. This version fixes the reset bug (the car was indeed colliding with the terrain from below). I assume I also fixed the strange turn-in behavior at low speeds. I had the parameter "drivingassist" set to 0.0 all the time. After changing it to the default value I experienced the same issue that you reported, so I could easily fix it. Nevertheless, I recommend to change the parameter to 0.0 to experience the driving in a more unfiltered way.

The only point I could not reproduce is the crash behavior. I installed Bullet 2.87, but the crash reaction was the same as before. Do you have any track on which the crash reaction is the worst? Then I can try to reproduce the issue there.

[Onsemeliot]

As usual you were right. The culprit was the driving assist. And the reset bug also seems to have vanished in the new version.

Even the notoriously difficult "Delta" single race map is now easy to drive. In fact it feels like the car would sit on rails even on maps like "Frozen" where the car clearly should slip on the ice. (I didn't test different friction values yet.) The question now is why in reality cars tend to drift under certain circumstances. It probably has something to do with friction/grip and weight distribution.

I suspect the car behaves like a stick when hitting a solid obstacle because the stiff body can't absorb the force by condensing the chassis. We would probably need a real 3-dimensional physical damage model that can transform the body shape to do so.

... a little later ...

Now I altered the friction value in vehicle.cpp and I think in principle a lower (more realistic) value feels better but now the steering is to stiff to make up for the lower grip. Maybe making the steering more flexible could bring back some of the drifting experience when we give cars more weight on the front wheels and less on the back (if something like that is even possible) to have that kind of additional front wheel grip for drifting to work. (I suspect the opposite would be sensible for back wheel drive cars.)
On "Frozen" I can even drift sometimes with a friction value of 1 but the car doesn't react to the breaks or steering in the opposite direction very much if it already slips. Of course it is a delicate balance since a to sensible steering can make the cars totally unstable.

[marsch84]

Even the notoriously difficult "Delta" single race map is now easy to drive. In fact it feels like the car would sit on rails even on maps like "Frozen" where the car clearly should slip on the ice. (I didn't test different friction values yet.) The question now is why in reality cars tend to drift under certain circumstances. It probably has something to do with friction/grip and weight distribution.

In case of the new implementation, the car is actually also slipping on the map "Frozen". The difference to the old implementation is, that it does it on the front axis instead of the rear axis. With the Bullet implementation the car is understeering. This means it slips over the front axle. Understeering can be translated to "I want to turn in a lot, but the car does not follow". So you can have the feeling, that the car is like on rails, because it does not follow you steering command. This is the usual behavior of front wheel driven cars. You can also make them slip at the rear axis, but you have to have some skill for that.

In case of the old implementation, the vehicle slips at the rear axle. This is called oversteering. In that case the car turns in more than you want it until it finally loses traction, if you do not counter-steer at the right moment. If you counter-steer ate the right moment and are able to keep the car in that state, this is called drifting. So the car does not drift by itself, the driver makes it drift.

As I already wrote, many arcade games initiate some fake drifting, if the car tends to understeer to achieve a good driving experience. The question is what is the intended driver experience. All I know is, that I can clearly understand why the cars are behaving like this in the Bullet engine. The load changes of the chassis and the impulses at the wheels are as in the schoolbook. On the other side, I have no idea why the front wheel driven cars oversteer so much on "Frozen". The funny thing is, that the Fox car which is rear wheel driven (so it should oversteer more) is more stable on that map.

As you said the, the behavior of the car can be influenced by vehicle settings. One of the most important ones is the parameter 1.8 in the line I quoted above. This parameter defines how good the wheels interact with the ground . There are also suspension settings which can be optimized. The center of mass of the vehicle can be moved more to the front or he back, too. I also forgot to activate load balancing between the left and the right side of the car. In a corner this puts more force on the outer wheels than the inner wheels. After activating this, the cars feel at little bit less like on rails.

I suspect the car behaves like a stick when hitting a solid obstacle because the stiff body can't absorb the force by condensing the chassis. We would probably need a real 3-dimensional physical damage model that can transform the body shape to do so.

I can still not see the issue. The cars behave very close to the old engine on my machine. As far as I understand you, the cars are bouncing back from an obstacle on your computer. And you can also not drive through grass and bushes. Can you record some kind of video of such a crash? I will also look into the code to check possible root causes.

[Onsemeliot]

Maybe I should have been more precise. Of course I noticed that on Frozen the car slips too. I was more talking about drifting than anything. And for that to work on ice the front wheels need more friction and the back wheels probably less. How and if that can be sensibly done I am uncertain.

So the car does not drift by itself, the driver makes it drift.

Yes, that is certainly true. But I am uncertain if we can get this option in an interesting amount while keeping the better physics.

I can still not see the issue.

With version 5 of your src folder it became less and cars now just behave like a stick would. The cars do not bounce back any more but they swivel away from the trees like a stick would. In the old engine they would just be abruptly stopped and the excess energy wasn't converted as much into a spinning motion. Grass doesn't have much effect but bushes now also cause the cars to quickly get out of control instead of just mostly being slowed down. This is however probably a good thing since it is most likely more realistic. But in the case of trees the fast spinning motion doesn't feel as realistic. I will try to record a short video when I am using a stronger system since my old laptop can just about perform well enough to play the game but not to also record a video without crashing.

[marsch84]

Maybe I should have been more precise. Of course I noticed that on Frozen the car slips too. I was more talking about drifting than anything. And for that to work on ice the front wheels need more friction and the back wheels probably less. How and if that can be sensibly done I am uncertain.
So the car does not drift by itself, the driver makes it drift.
Yes, that is certainly true. But I am uncertain if we can get this option in an interesting amount while keeping the better physics.

That is correct. If the rear wheels are able transfer less force than the front wheels, the car would have more oversteer. This are the main factors which influence how much force a wheel can transfer:
- Friction coefficient: this is about the same for all four wheels at a real car (expect for different tire wear or pressure). It can be made different artificially for front and rear wheels in the game, but I would consider this cheating.
- The static weight pushing down on the wheel. The higher the weight, the more force the wheel can transfer. This can be changed by moving the center of mass of the car more the the front. However, I think this will not have a huge effect.
- The dynamic weight which builds up in certain driving scenarios. For instance if you brake, the weight on the front wheels is higher, because the car nods down in the front. Or the movement of the chassis that puts weight on the outer wheels of the corner. The weight transfer works really well with the new vehicle model and can be used by skilled drivers to initiate drifting, e.g. by shortly slowing down or braking before turning into a corner. Maybe changing the suspension settings can make the weight transfer more extreme.

Front wheel driven cars have a tendency to understeer. In this configuration the front wheels have to transfer the engine force plus the side forces keeping the car driving in the intended direction. As there is the engine force, the forces towards the side are more limited than in a rear wheel car. That is why they understeer and slip over the front axis.

I will try to explore different options to change the intended behavior. I added one more archive that should bring small improvements, e.g. the weight transfer between left and right wheels.

With version 5 of your src folder it became less and cars now just behave like a stick would. The cars do not bounce back any more but they swivel away from the trees like a stick would. In the old engine they would just be abruptly stopped and the excess energy wasn't converted as much into a spinning motion. Grass doesn't have much effect but bushes now also cause the cars to quickly get out of control instead of just mostly being slowed down. This is however probably a good thing since it is most likely more realistic. But in the case of trees the fast spinning motion doesn't feel as realistic. I will try to record a short video when I am using a stronger system since my old laptop can just about perform well enough to play the game but not to also record a video without crashing.

I think I got your point now. I reduced the spinning in the latest archive by 50%. So I think there is no need for a video any more.

[marsch84]

I made an interesting observation. I drove the game with my force feedback steering wheel and I noticed, that even on highest sensitivity (1080° setting), it only needs very little steering to master the corners. This means, that the car is steered way to much when driven with a keyboard or gamepad which basically switches between full steering an no steering. Image driving a real car in which you only steer by having the wheel at 100% left or right.

This also explains why there is so much understeer from a driving physics perspective. Understeer occurs if front wheels cannot handle the force towards the side. This happens for instance, if you turn in too much when entering a corner. One main way get car out of understeering in reality is to open steering until the front wheels get grip again and then to steer in again to get the corner. This also explains why the cars get so much slower when turning. On slippery maps like Frozen there is understeer from the first millisecond the steering happens (understeering will also restrict how much forward force from the engine the wheel can put on the ground).

So I think the problem is not so much the vehicle settings, but the way the keyboard control is mapped to the steering of the vehicle. In commercial games, that are supposed to be driven with the keyboard among other options, there is usually never a direct mapping. One simple solution is not turn in instantly, but to steer gradually the longer the left or right keys are pressed. Trigger Rally already has a feature like this, but I on the web I found some more advanced suggestions how to handle. I will look into these options and come back.

[Onsemeliot]

This all-or-nothing steering sounds very much what I tried to explain with previous src versions in Jumpy. But for me it seems to be fine now. Maybe I'm just used to it because it has been handled like this all the time in Trigger Rally in the past and I just tab the arrow keys quickly and very gently if I don't want to steer a lot.
When I had a similar issue in Jumpy I needed to press the arrow keys very hard and long to get any steering reaction at all but when it reacted it was as you describe just an all-or-nothing approach. For me it now seems to work generally as before using the bullet engine.

But if I steer in Frozen it isn't as before at all. It has surprisingly good grip with steering as long as I am not to fast to get around a corner but if I have to slow down to get around a tight curve the car will only slip forward as if I wouldn't steer at all while I am using the breaks. The hand break is no different. (It is as if the back wheels would still push forward and the front wheels wouldn't make a difference because the breaks only work on the front wheels and therefore they can't get the car to actually steer in the intended direction despite them being turned to the maximum available degree.) It then feels like sitting in rails with no chance to alter the trajectory. Only if I manage to slow down enough I can (very slowly) steer enough to get around the corner. The car will never slip sideways. Therefore it is the opposite from what it was in the past. Before bullet drifting on the ice was an almost constant thing I needed to do in order to stay on the track. This was fun and felt natural. But it might not have been realistic at all.

[marsch84]

But if I steer in Frozen it isn't as before at all. It has surprisingly good grip with steering as long as I am not to fast to get around a corner but if I have to slow down to get around a tight curve the car will only slip forward as if I wouldn't steer at all while I am using the breaks. The hand break is no different. (It is as if the back wheels would still push forward and the front wheels wouldn't make a difference because the breaks only work on the front wheels and therefore they can't get the car to actually steer in the intended direction despite them being turned to the maximum available degree.) It then feels like sitting in rails with no chance to alter the trajectory. Only if I manage to slow down enough I can (very slowly) steer enough to get around the corner. The car will never slip sideways. Therefore it is the opposite from what it was in the past. Before bullet drifting on the ice was an almost constant thing I needed to do in order to stay on the track. This was fun and felt natural. But it might not have been realistic at all.

Yes, the main question is how we want the cars in the game to behave. The behavior you describe on Frozen is quite realistic as I explained in my previous comments, but that is maybe not the intention of the game.

I verified the the behavior with a front wheel car on the ice track of Project Cars 2. In this game the cars are also understeering a lot on that track. In Project Cars keyboard steering results in a little slower wheel steering movement that in Trigger Rally, but the principle is the same. They seem not have implemented any other tweaks for keyboard steering. We could slow the steering down a little in Trigger Rally, but it will not change the world.

I tried out the measures I explained in my previous comment, but none of them really transferred an understeering vehicle to a drift champion on Frozen. The only change which has an impact is lowering the friction coefficient for the rear wheels compared to the front wheels. Even though this is not what you want in a real vehicle (ideally all tires should have the same grip), I think it serves the purpose. I attached another archive with this implementation. The coefficient is just slightly lower on the rear axle (1.7 compared to 1.8, see code below). You can play with these parameters if you like (code is in vehicle.cpp around line 1533).

if (vehicle->getWheelInfo(i).m_bIsFrontWheel)
      vehicle->getWheelInfo(i).m_frictionSlip = 1.8f * mf_coef * (1.0f - 0.5f * damage);
else
      vehicle->getWheelInfo(i).m_frictionSlip = 1.7f * mf_coef * (1.0f - 0.5f * damage);

I think the coefficients are stills quite close to each other. This is like having your bad pair of tires on the rear axle on purpose. This is actually what many drifters do to support the intended vehicle behavior.

I agree, that the hand brake should have more impact. I think you can optimize that by increasing the "brake2" parameter in vehicle file.

[Onsemeliot]

I would like to stay as true to real live as sensibly possible. Therefore I tried to use 1.0 an 0.97 as friction values and I changed the hand break effect from 1000 to 1500 on the Cordo kit car. I also increased the break strength on the back wheels from 100 to 300. But the friction values are probably to low. Maybe the friction values of the soil materials should be adapted too.
But I learned that more effect on the back wheel breaks is rather vital for getting some chance for proper drifting.

[marsch84]

Your are making a point. The vehicles must be brought a state as close as possible to real life to tune the driving behavior. So I also changed the friction coefficient back to 1.0 and 0.97 as you suggested. Then I found out, that the values in the vehicle files are not necessarily real, so I changed that. I started with the Coro Kit-Car. For that I looked up specs from a sample Kit-Car:
http://tech-racingcars.wikidot.com/skoda-octavia-i-kit-car

The first parameter is the weight. The car in the game is actually too light. This is important for grip. The more force is pushing on the wheel from above, the more force it can transfer to the ground. The minimum weight of the real Kit-Car car is 1000kg plus the weight for two drivers (150kg), so I changed the parameter in the vehicle file to 1150kg.

Of course this has to match the engine power. The Kit-Car specs mention 270hp. From the formula in the engine code, I understand the "powerscale" parameter should be in Watts. So I entered 201339 Watts.

The last parameter are the brakes. I assume, that the parameter of the brakes (brake1) is a force in Newton. From some googling I found out, that 4000N is a good choice for front wheels and 2000N for the rear. Here I want to mention, that having more brake force on the back is not what cars have in reality, because they want to prevent the behavior that we want to provoke. The cars would fly off the road when braking heavily, because the rear will get unstable. You can easily see this when looking at the wheels of parked cars. The rear brake is always smaller than the front (some small cars even still have drum brakes at the rear).

This is the summary of the changed parameters for the Cordo Kit-Car:
mass="1150.0"
powerscale="201339"
brake1 = 4000 (for front wheels)
brake1 = 2000 (for rear wheels)

The great thing about these parameters is, that I could remove some magic constants from my code, so you have to change these two lines setting engine force and brake in vehicle.cpp to this:

vehicle->applyEngineForce(btScalar(drivetorque * typewheel.drive / typewheel.radius), i);
vehicle->setBrake(btScalar(desiredchange * delta), i);

The result is, that the cars are more likely to drift now, so I even set the friction value for both axes back to 1.0. There is one small problems though. Due to the increased weight, the bottom of the chassis is hitting the ground from time to time, but I think this can be solved by tuning the suspension. This are the parameters from the vehicle.cpp responsible for this:

  float suspensionStiffness = 60.0f;
  float dampingRelaxation = 0.4f * 2.0f * sqrt(60.0f);
  float sampingCompression = 0.3f * 2.0f * sqrt(60.0f);

I had a look at the friction coefficients from the game and I think they are rather too high than too low compared to the data at the link below (see Rubber section). So lowering them will rather worsen the understeering:
https://www.engineeringtoolbox.com/friction-coefficients-d_778.html

This are the coefficients from the game:

///
///   Name              RgbColor                Friction    Resistance      DirtInfo
///
#define TERRAINMAP_MATERIALS                                                                        \
    X(RacingTarmac,     RGB( 80,  60, 100),     1.50,       0.00,           DI(0.00, 0.10,  6.0))   \
    X(CountryRoad,      RGB(140,  80, 180),     1.20,       0.00,           DI(0.00, 0.20,  6.0))   \
    X(SlipperyRoad,     RGB(200, 140, 255),     0.50,       0.00,           DI(0.00, 0.30,  6.0))   \
    X(Ice,              RGB(180, 220, 255),     0.20,       0.00,           DI(0.00, 0.10,  6.0))   \
    X(DeepSnow,         RGB(255, 255, 255),     0.30,       0.50,           DI(0.00, 0.80,  1.0))   \
    X(FirmSand,         RGB(255, 220,   0),     1.00,       0.05,           DI(0.50, 2.60,  1.5))   \
    X(LooseSand,        RGB(255, 255, 140),     0.75,       0.55,           DI(0.50, 3.00,  1.5))   \
    X(PressedEarth,     RGB(255, 200, 200),     0.90,       0.05,           DI(0.00, 0.35,  3.0))   \
    X(LooseEarth,       RGB(255, 140, 140),     0.70,       0.25,           DI(0.00, 1.00,  2.0))   \
    X(MoistEarth,       RGB(255,   0,   0),     1.10,       0.15,           DI(0.00, 0.75,  7.5))   \
    X(Mud,              RGB(160,   0,   0),     0.60,       0.40,           DI(0.00, 0.55,  6.0))   \
    X(FineGravel,       RGB(140, 140, 140),     0.90,       0.10,           DI(0.00, 1.25,  3.0))   \
    X(RoughGravel,      RGB(  0,   0,   0),     0.60,       0.20,           DI(0.00, 0.40,  5.0))   \
    X(Grass,            RGB(  0, 180,   0),     0.40,       0.10,           DI(0.00, 0.30,  6.5))   \
    X(Shrubbery,        RGB(  0,  90,   0),     0.40,       0.70,           DI(0.00, 0.50,  6.0))   \
    X(DeepWater,        RGB(  0,   0, 255),     0.20,       0.60,           DI(0.00, 0.50,  6.0))

In general the Cordo Kit-Car is still understeering a lot on slippery surfaces (like in Frozen) even after my modifications above. I do not think, that this can be turned off entirely, because that is the natural reaction of a car in such conditions combined with the very quick steering through keyboard control. Nevertheless, I will continue to look for some small improvements.

[Onsemeliot]

I tried to apply the same values you mentioned but it seems I have messed something up. Do you understand what I need to change for the game to properly build again?

Should I define "desiredchange" somewhere?:

$ make

current values of user-set variables:
    DESTDIR      ?= 
    prefix       ?= /usr/local
    exec_prefix  ?= /usr/local
    OPTIMS       ?= -march=native -mtune=native -Og
    WARNINGS     ?= -Wall -Wextra -pedantic

resulting values of build variables:
    CXXFLAGS     += -std=c++11 -Wall -Wextra -pedantic -march=native -mtune=native -Og  -g
    CPPFLAGS     += -DNDEBUG -DUNIX -DPACKAGE_VERSION="0.6.7" -I'./include' -I/usr/include/bullet
    LDFLAGS      += -lSDL2main -lGL -lGLU -lGLEW -lSDL2 -lSDL2_image -lphysfs -lopenal -lalut -lpthread -ltinyxml2 -lBulletSoftBody -lBulletDynamics -lBulletCollision -lLinearMath

g++ PEngine/app.cpp -> PEngine/app.o
g++ PEngine/audio.cpp -> PEngine/audio.o
g++ PEngine/config.cpp -> PEngine/config.o
g++ PEngine/fxman.cpp -> PEngine/fxman.o
g++ PEngine/model.cpp -> PEngine/model.o
g++ PEngine/physfs_rw.cpp -> PEngine/physfs_rw.o
g++ PEngine/render.cpp -> PEngine/render.o
g++ PEngine/rigidity.cpp -> PEngine/rigidity.o
g++ PEngine/terrain.cpp -> PEngine/terrain.o
g++ PEngine/texture.cpp -> PEngine/texture.o
g++ PEngine/util.cpp -> PEngine/util.o
g++ PEngine/vbuffer.cpp -> PEngine/vbuffer.o
g++ PEngine/vmath.cpp -> PEngine/vmath.o
g++ PSim/bulletdebugdraw.cpp -> PSim/bulletdebugdraw.o
In file included from /usr/include/bullet/btBulletCollisionCommon.h:28,
                 from /usr/include/bullet/btBulletDynamicsCommon.h:20,
                 from ./include/bulletdebugdraw.h:9,
                 from PSim/bulletdebugdraw.cpp:6:
/usr/include/bullet/BulletCollision/CollisionShapes/btCapsuleShape.h: In member function ‘virtual void btCapsuleShape::setMargin(btScalar)’:
/usr/include/bullet/BulletCollision/CollisionShapes/btCapsuleShape.h:49:34: warning: unused parameter ‘collisionMargin’ [-Wunused-parameter]
  virtual void setMargin(btScalar collisionMargin)
                         ~~~~~~~~~^~~~~~~~~~~~~~~
In file included from /usr/include/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.h:33,
                 from /usr/include/bullet/btBulletDynamicsCommon.h:22,
                 from ./include/bulletdebugdraw.h:9,
                 from PSim/bulletdebugdraw.cpp:6:
/usr/include/bullet/LinearMath/btThreads.h: In function ‘void btMutexLock(btSpinMutex*)’:
/usr/include/bullet/LinearMath/btThreads.h:71:50: warning: unused parameter ‘mutex’ [-Wunused-parameter]
 SIMD_FORCE_INLINE void btMutexLock( btSpinMutex* mutex )
                                     ~~~~~~~~~~~~~^~~~~
/usr/include/bullet/LinearMath/btThreads.h: In function ‘void btMutexUnlock(btSpinMutex*)’:
/usr/include/bullet/LinearMath/btThreads.h:78:52: warning: unused parameter ‘mutex’ [-Wunused-parameter]
 SIMD_FORCE_INLINE void btMutexUnlock( btSpinMutex* mutex )
                                       ~~~~~~~~~~~~~^~~~~
/usr/include/bullet/LinearMath/btThreads.h: In function ‘bool btMutexTryLock(btSpinMutex*)’:
/usr/include/bullet/LinearMath/btThreads.h:85:53: warning: unused parameter ‘mutex’ [-Wunused-parameter]
 SIMD_FORCE_INLINE bool btMutexTryLock( btSpinMutex* mutex )
                                        ~~~~~~~~~~~~~^~~~~
PSim/bulletdebugdraw.cpp: In member function ‘virtual void BulletDebugDraw::drawContactPoint(const btVector3&, const btVector3&, btScalar, int, const btVector3&)’:
PSim/bulletdebugdraw.cpp:110:57: warning: unused parameter ‘PointOnB’ [-Wunused-parameter]
 void BulletDebugDraw::drawContactPoint(const btVector3 &PointOnB,
                                        ~~~~~~~~~~~~~~~~~^~~~~~~~
PSim/bulletdebugdraw.cpp:111:24: warning: unused parameter ‘normalOnB’ [-Wunused-parameter]
       const btVector3 &normalOnB, btScalar distance, int lifeTime,
       ~~~~~~~~~~~~~~~~~^~~~~~~~~
PSim/bulletdebugdraw.cpp:111:44: warning: unused parameter ‘distance’ [-Wunused-parameter]
       const btVector3 &normalOnB, btScalar distance, int lifeTime,
                                   ~~~~~~~~~^~~~~~~~
PSim/bulletdebugdraw.cpp:111:58: warning: unused parameter ‘lifeTime’ [-Wunused-parameter]
       const btVector3 &normalOnB, btScalar distance, int lifeTime,
                                                      ~~~~^~~~~~~~
PSim/bulletdebugdraw.cpp:112:24: warning: unused parameter ‘color’ [-Wunused-parameter]
       const btVector3 &color ) {
       ~~~~~~~~~~~~~~~~~^~~~~
PSim/bulletdebugdraw.cpp: In member function ‘virtual void BulletDebugDraw::draw3dText(const btVector3&, const char*)’:
PSim/bulletdebugdraw.cpp:114:52: warning: unused parameter ‘location’ [-Wunused-parameter]
 void BulletDebugDraw::draw3dText( const btVector3 &location,
                                   ~~~~~~~~~~~~~~~~~^~~~~~~~
PSim/bulletdebugdraw.cpp:115:19: warning: unused parameter ‘textString’ [-Wunused-parameter]
       const char *textString) {
       ~~~~~~~~~~~~^~~~~~~~~~
g++ PSim/collision.cpp -> PSim/collision.o
g++ PSim/damage.cpp -> PSim/damage.o
g++ PSim/engine.cpp -> PSim/engine.o
g++ PSim/raycaster.cpp -> PSim/raycaster.o
PSim/raycaster.cpp: In member function ‘virtual void* PRaycaster::castRay(const btVector3&, const btVector3&, btVehicleRaycaster::btVehicleRaycasterResult&)’:
PSim/raycaster.cpp:3:44: warning: unused parameter ‘from’ [-Wunused-parameter]
 void *PRaycaster::castRay(const btVector3 &from, const btVector3 &to, btVehicleRaycasterResult &result)
                           ~~~~~~~~~~~~~~~~~^~~~
PSim/raycaster.cpp:3:67: warning: unused parameter ‘to’ [-Wunused-parameter]
 void *PRaycaster::castRay(const btVector3 &from, const btVector3 &to, btVehicleRaycasterResult &result)
                                                  ~~~~~~~~~~~~~~~~~^~
PSim/raycaster.cpp:3:97: warning: unused parameter ‘result’ [-Wunused-parameter]
 y(const btVector3 &from, const btVector3 &to, btVehicleRaycasterResult &result)
                                               ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~

g++ PSim/sim.cpp -> PSim/sim.o
In file included from /usr/include/bullet/btBulletCollisionCommon.h:28,
                 from /usr/include/bullet/btBulletDynamicsCommon.h:20,
                 from ./include/bulletdebugdraw.h:9,
                 from PSim/sim.cpp:12:
/usr/include/bullet/BulletCollision/CollisionShapes/btCapsuleShape.h: In member function ‘virtual void btCapsuleShape::setMargin(btScalar)’:
/usr/include/bullet/BulletCollision/CollisionShapes/btCapsuleShape.h:49:34: warning: unused parameter ‘collisionMargin’ [-Wunused-parameter]
  virtual void setMargin(btScalar collisionMargin)
                         ~~~~~~~~~^~~~~~~~~~~~~~~
In file included from /usr/include/bullet/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.h:33,
                 from /usr/include/bullet/btBulletDynamicsCommon.h:22,
                 from ./include/bulletdebugdraw.h:9,
                 from PSim/sim.cpp:12:
/usr/include/bullet/LinearMath/btThreads.h: In function ‘void btMutexLock(btSpinMutex*)’:
/usr/include/bullet/LinearMath/btThreads.h:71:50: warning: unused parameter ‘mutex’ [-Wunused-parameter]
 SIMD_FORCE_INLINE void btMutexLock( btSpinMutex* mutex )
                                     ~~~~~~~~~~~~~^~~~~
/usr/include/bullet/LinearMath/btThreads.h: In function ‘void btMutexUnlock(btSpinMutex*)’:
/usr/include/bullet/LinearMath/btThreads.h:78:52: warning: unused parameter ‘mutex’ [-Wunused-parameter]
 SIMD_FORCE_INLINE void btMutexUnlock( btSpinMutex* mutex )
                                       ~~~~~~~~~~~~~^~~~~
/usr/include/bullet/LinearMath/btThreads.h: In function ‘bool btMutexTryLock(btSpinMutex*)’:
/usr/include/bullet/LinearMath/btThreads.h:85:53: warning: unused parameter ‘mutex’ [-Wunused-parameter]
 SIMD_FORCE_INLINE bool btMutexTryLock( btSpinMutex* mutex )
                                        ~~~~~~~~~~~~~^~~~~
g++ PSim/vehicle.cpp -> PSim/vehicle.o
PSim/vehicle.cpp: In member function ‘void PVehicle::tick(float)’:
PSim/vehicle.cpp:1548:34: error: ‘desiredchange’ was not declared in this scope
       vehicle->setBrake(btScalar(desiredchange * delta), i);
                                  ^~~~~~~~~~~~~
make: *** [GNUmakefile:166: PSim/vehicle.o] Error 1

[marsch84]

It looks like you accidently deleted a line of code. I attached the another archive with the latest version of the source code. You just have to adapt the vehicle file now.

The good thing about this version is, that the vehicle acceleration and speed seem to feel natural and they are based on real vehicle specifications, so that any magic coefficients could be removed from the code.

However, after some testing I have to say, that I am not happy with the general driving behavior. I assume this is mainly related to changing the friction coefficient from 1.8 to 1.0. Keeping the vehicle under control became more difficult. Now you will get more oversteer, as I mentioned before. However, it usually happens at high speed and then it is impossible to counteract (though this is realistic I assume :-)). I think we usually want it when entering a corner.

I also understand why the car understeers so much from the perspective of driving physics, but it feels very extreme. It even happens, if I turn in my wheel just by a few degrees. Having a friction coefficient of 0.5 like on Frozen is comparable to very wet asphalt in reality and I do not fly off the road at 100km/h with this kind of minimal steering. However, all the physical values and formulas seem to be correctly calculated, so I can no find issues from a theoretical perspective.

[marsch84]

After some driving on frozen, I thought, that I might really be too fast in the corners to get through them. After all the car is driving on some kind of ice and they are faster now due to the new engine power setting. So intended to use the brakes a little more and I got the feeling the settings I suggested above are too weak (4000N on front and 2000N on rear axle). According too my calculations a total brake force on all four wheels (30,000N) should be realistic. Unfortunately, I did not find any good data for rally cars on the web. I set brake1 to 9000 for the front and 6000 for the rear wheels. According to the standard setups of commercial racing games anything around 60:40 seems to be a quite a common setup for brake force distribution. With the new setup you can even lock the wheels while braking which I think is normal in every race car, as there is no ABS. By slowing down in the corners a little more, I am able to get quite decent lap times on Frozen once more.

I found a way, that easily helps to see which wheel is losing traction by deactivating the drawing of the vehicle mode. This way you have a very good view at each wheel. Once the wheel starts throwing dirt, it starts losing grip.

For this you have to comment line 1946 in Trigger/render.cpp:

//drawModel(*typepart.model, alpha);

[Onsemeliot]

I discovered that the weight distribution seems to be one of the most important values to be tweaked. When the engine sits in the front it seems reasonable that there is more weight on the front wheels. And if I adapt the values to reflect that than the physics behaviour is suddenly better. But despite testing and tweaking all day I couldn't come up with a set of values yet I feel more comfortable with than with the physics behaviour of the old engine. So far it is mainly different with other undesirable effects but not actually better. I'm tired now. Maybe sleeping over it will help.

[marsch84]

Yes, this is correct. All cars should have more weight on the front wheels, because the engine is in the front. I checked all three Kit-Cars and the only car that has more weight on the front by default is the Cordo. This should support the steering and enable more drifting. Nevertheless, the Cordo is still not optimal.

The force that rest on each wheel can be read from the variable below:

vehicle->getWheelInfo(i).m_wheelsSuspensionForce

The values below are read after changing the mass of each Kit-Car to 1150 kg. If you add the forces up (2 * front + 2* back) and divide the sum by the gravitational acceleration (9.81 m/s²) you get exactly 1150kg. So that part seems to be correct.

The values show, that the front wheels of the Cordo Kit-Car can transfer the most force and should have the least amount of understeering. At Frozen with a friction coefficient of 0.5 each front wheel should be able to handle 1679.07 N of side forces, if there are no or almost no additional forces in front direction due to acceleration or braking. Of course the dynamic load transfer might increase or decrease this value. When slowing down through coasting or braking, the forces that the front wheels can transfer are increased, because the chassis of the car nods down in the front. So that helps as well.

Cordo:
Front: 3358.14 N
Back: 2282.61 N

Evo:
Front: 2446.43 N
Back: 3194.35 N

Fox:
Front: 2498.32 N
Back: 3142.42 N

[Onsemeliot]

In my file the Cordo kit car originally didn't have a different weight distribution (aka force) between front and back. And unfortunately I am confused about the values in the vehicle file because the body has force and dampening values too.
The values you listed above should be the force values on the wheels?
Isn't it also strange when all three kit cars have the same weight? I suspect there should be rather different values since their weight distribution breaks and engine power would vary quite a lot in reality. But I am uncertain what such values could sensibly be since I don't really understand all the available values and how the needed calculations with them work.

[marsch84]

In my file the Cordo kit car originally didn't have a different weight distribution (aka force) between front and back. And unfortunately I am confused about the values in the vehicle file because the body has force and dampening values too.
The values you listed above should be the force values on the wheels?

I think I have to explain the current parameters of the wheels, because some do not have an effect at all right now. The force values I shared above are not part of the configuration. They are calculated from the mass of the vehicle and the weight distribution which is influenced by the Y-axis position of the wheels.

These are the settings I use for the Cordo Kit-Car right now:

        <wheel drive="1.0" steer="0.85" brake1="9000.0" pos="0.63, 1.07, -0.17" radius="0.3" force="45000.0" dampening="20000.0" friction="0.018"/>
        <wheel drive="1.0" steer="0.85" brake1="9000.0" pos="-0.63, 1.07, -0.17" radius="0.3" force="45000.0" dampening="20000.0" friction="0.018"/>
        <wheel drive="0.0" steer="0.0" brake1="6000.0" pos="0.63, -1.07, -0.17" radius="0.3" force="45000.0" dampening="20000.0" brake2="6000.0" friction="0.018"/>
        <wheel drive="0.0" steer="0.0" brake1="6000.0" pos="-0.63, -1.07, -0.17" radius="0.3" force="45000.0" dampening="20000.0" brake2="6000.0" friction="0.018"/>

Drive: determines whether this wheel is driven by the engine
Steer: maximum steering angle in radians
brake1: brake force in Newton
pos: position of wheels, you can use the Y-axis of this value to determine the weight distribution of the car, I balanced the car to have a 50:50 distribution. This will offset the wheels, so that the graphics will not look right anymore. However, this can be corrected in the code once we decide to use Bullet.
radius: radius of the wheel
force: not used, was used for suspension before, suspension parameters changed due to Bullet, will be replaced later if we decide to got to Bullet
dampening: not used, was used for suspension before suspension parameters changed due to Bullet, will be replaced later if we decide to got to Bullet
brake2: parking brake force in Newton
friction: not used, this is changed in the code for now, it is the friction coefficient you changed from 1.8 to 1.0.

The suspension can be tuned by modifying these lines of code in vehicle.cpp (line 710). I got these from a report published in the web. I played with them a little, but these values seem to work quite well.

  float suspensionStiffness = 45.0f;
  float dampingRelaxation = 0.5f * 2.0f * sqrt(suspensionStiffness);
  float dampingCompression = 0.3f * 2.0f * sqrt(suspensionStiffness);

Isn't ist also strage when all three kit cars have the same weight? I suspect there should be rather different values since their weight distribution breaks and engine power would vary quite a lot in reality. But I am uncertain what such values could sensibly be since I don't really understand all the available values and how the needed calculations with them work.

There is a nice website listing the data of various Kit-Cars (Groups N, A, B, 1995 - 1998):
http://tech-racingcars.wikidot.com/rally-cars

It looks like the minimum weight of the Kit-Cars was set to 1000 kg after the racing series already ended in 2000. However, before that the cars seemed have a little variance in the weight and the engine power. I think this can be reflected in the three Kit-Cars of the game. And do not forget to add the 150 kg as the minimum weight of the two drivers. I also assume brake force would have been slightly different on each car.

I assume the weight distribution should have been mostly around 50:50. I read through some car tuner forums on the web and it looks like having more weight in the front also comes with disadvantages. You will have more force pushing down in the front, but at the same time a higher force will push against the front wheels from the side, so that the effects basically cancel out each other. The Kit-Cars were real race cars, so even if their series version would have a non-even weight distribution, I assume the race teams would tune them to 50:50. That is why I changed the weight distribution of Cordo Kit-Car compared to the original settings.

[Onsemeliot]

If I understand you right the only values it would make sense to test in the vehicle file are the breaks. Everything else is at the moment either not sensible to alter, defined (or calculated) in code or not used with Bullet at all.

I was convinced altering the force values on the wheels made a big difference. But if you say otherwise I must be wrong. Maybe I felt victim to the same effect that causes people to feel different physics if the soil has a different texture even if the physics is actually the same.

The car gets quite damaged over a medium track like "Authenitc" even without hitting anything. The base smashing the ground also causes the car often getting pulled away like it would suddenly stick on probably a little bump that isn't even visible as an obstacle.

Originally I didn't know that you used different wheel coordinates. When using it the car really slips away when it is fast but if I use the old coordinates no steering and breaking can help to avoid hitting a tree that is a long way ahead and therefore should be easy to drive around. I tried the middle ground but that doesn't really help.

Now I get why you originally increased the friction to 1.8. (It didn't seem necessary before I used your wheel coordinates.) But the behaviour is still not satisfying even if I return to a friction value of 1.8.

I don't know what else we could do to create a satisfying driving experience with Bullet.

But if we can't get a decent physics simulation I fear we should stick with the old engine. At first I had the impression the difficulties would just be a matter of tweaking but now I get the feeling there is just no way to get an as convincing as fun simulation with bullet. (And I don't understand how it is even possible that a more advanced simulation can bring a inferior result. Are there relevant attributes we didn't think of yet?)

If we could find good enough values for the available attributes it would be great to expose the things that get typically tweaked for different conditions as options in a new car configuration menu. Things like winter and summer wheels and strength of the breaks. (I don't know much about cars but I can imagine that many people would love to play with such options.) If I remember correctly this was one of the big successes of Colin McRae Rally 2.0 that actually allowed to easily make such adjustments in very accessible menus.

[marsch84]

The car gets quite damaged over a medium track like "Authenitc" even without hitting anything. The base smashing the ground also causes the car often getting pulled away like it would suddenly stick on probably a little bump that isn't even visible as an obstacle.

The tracks are too bumpy for the small height of the chassis below the vehicles. In the latest code that I attached the physical model follows almost exactly the graphical representation. Before that, the physical vehicle was basically a box. This brings a little improvement, but does not fix fix the issue entirely. Of course, this can be tweaked further later.

Originally I didn't know that you used different wheel coordinates. When using it the car really slips away when it is fast but if I use the old coordinates no steering and breaking can help to avoid hitting a tree that is a long way ahead and therefore should be easy to drive around. I tried the middle ground but that doesn't really help.
Now I get why you originally increased the friction to 1.8. (It didn't seem necessary before I used your wheel coordinates.) But the behaviour is still not satisfying even if I return to a friction value of 1.8.

I implemented two little driving aids in the attached archive. One counter-steers automatically once the car gets into a drift. This way the player can keep the drift very easily. This is what professional drifters also do, but is basically impossible to achieve with a keyboard. The other limits the amount of steering when driving fast. This makes sense, because steering more makes the behavior worse, when the front wheels are already slipping. Many racing games implement the same mechanics, especially if they are targeted towards keyboard and gamepad players. I am interested to know, whether this brings some improvements in your point of view.

I don't know what else we could do to create a satisfying driving experience with Bullet.
But if we can't get a decent physics simulation I fear we should stick with the old engine. At first I had the impression the difficulties would just be a matter of tweaking but now I get the feeling there is just no way to get an as convincing as fun simulation with bullet. (And I don't understand how it is even possible that a more advanced simulation can bring a inferior result. Are there relevant attributes we didn't think of yet?)

I think the point is, that the old engine is no accurate simulation in all aspects. It uses a lot of tweaking. Of course we can also tweak the Bullet parameters with non-realistic values to get the expected result. I do not completely understand why the old engine actually allows this drift style driving. I think the reason is, that the car is basically two front wheels driven by the engine which pull the two other wheels which are not turning at all or turning much slower after them. I think this is also the reason why the engine fails with rear wheel driven cars.

By now I performed a few hours of driving with the Bullet implementation and I can see a lot of similarities to commercial racing simulations in the car handling, especially when driving with the steering wheel or gamepad. I also think, that the tracks with high or medium friction roads (tarmac or gravel) are fun to drive. I think we will also find good vehicle parameters for this kind of tracks.

However, there is only one exception which does not satisfy me at all. And this are low friction maps like Frozen. The sliding over the front axis is just too bad. I think it should not be that bad for a friction coefficient of 0.5. I will look deeper into the friction simulation of the Bullet vehicle model. Mabe I can discover something. However, so far the Bullet code and the physical values generated by it seem to be correct.

If we could find good enough values for the available attributes it would be great to expose the things that get typically tweaked for different conditions as options in a new car configuration menu. Things like winter and summer wheels and strength of the breaks. (I don't know much about cars but I can imagine that many people would love to play with such options.) If I remember correctly this was one of the big successes of Colin McRae Rally 2.0 that actually allowed to easily make such adjustments in very accessible menus.

That is a good feature, but I think it only makes sense, if the vehicles on the game on proper physics. Otherwise, it is not very motivating to implement it.

[Onsemeliot]

Indeed, this version works much better for me. It never fails to amaze me how you can knock out seemingly effortless and rather quickly such alterations in the surely sophisticated physical calculations. (But you are right that Frozen isn't very drivable yet.)

I think it only makes sense, if the vehicles on the game on proper physics.

Of course.