Do you know Stormbaan Coureur? It already has a fantastic physics engine and seems to be written in C++ too. So it might be compatible with Trigger Rally. Combined with what we built already this could be amazing.
This way we could get rid of Trigger Rallys old "moon gravity" problem at once. And I suspect it should be possible to adapt the Stormbaan Coureur code to also use our different terrain physics values and to use different attribute values like weight and dimensions for different vehicles. Heck, it might even be possible to use different wheel attributes to simulate more or less grip on different terrain like rainy tarmac, mud etc. or wheel types. Since it has real shadows too we could even push the game to a point where it was possible to use lights and shadows (such as head and tail lights).
I feel Trigger Rally already has a much better physics engine than most other free racing games such as Stunt Rally or even Torcs. But a constant pain is the problem of losing control at higher speeds. Unfortunately this still doesn't feel very realistic or fun. (Even if it has gotten much better trough recent code improvements.) With Stormbaan Coureur's physics engine it could incorporate the best available in free games so far and further improve on design and options for variation in maps.
Stormbaan Coureur also already includes the possibility to interact with other rigid bodies. This could come in handy for things like fences and walls or even obstacles like barrels that aren't fully static. I see great potential and it seems very odd to me that the obviously very well done physics engine from Stormbaan Coureur has been laying dormant for so long while other games are struggling to get a decent physics calculation for car racing done.
I do not have any clue how difficult it would be to integrate one solution into the other. Maybe it would be easier to do it the other way around and to add the Trigger Rally features to a fork of Stormbaan Coureur. Or maybe they aren't sensibly combinable at all.
In my view one of the best car racing games in the proprietary world in recent years has been Next Car Game and Trigger Rally in combination with Stormbaan Coureur could gain many of the most fun features of that. Maybe even without requiring to much processing power since Stormbaan Coureur is rather old now too and therefore it shouldn't demand to much from the players system.
Last edit: Onsemeliot 2021-02-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The game Stormbaan Coureur uses the Open Dynamics Engine to simulate physics. This engine seems quite suitable to simulate a car. There are some examples available that show how it can be done (link below). It sound quite interesting to replace the existing engine with a more sophisticated alternative. I will check how big a task it will be to replace the heart of the game. :-)
Great idea!
IMO it would be interesting having option to choose one of this engines in the "* .level" script in order to preserve old style feeling for some enthusiast.
Cordial greetings,
Janusz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally had the chance to have a closer look into this topic. The Open Dynamics Engine (ODE) performs rigid body simulation which is basically what Trigger Rally is already doing. So I thought it would be cool to add a second more sophisticated rigid body simulator to the game as Janusz suggested. I even started refactoring the Trigger Rally simulation code to have a cleaner interface. Behind that I planned to hide the ODE implementation.
During the process I realized, that replacing the rigid body simulation will most likely not solve the main problems with the game's car behaviour (e.g. moon like gravity). This discussion from a while ago basically comes to the same conclusion: https://sourceforge.net/p/trigger-rally/bugs/7/
The background is, that the vehicle simulation consist of two layers. The lower layer is the already mentioned rigid body simulation (mainly located in rigidbody.cpp, psim.h and sim.cpp). The higher level part is the simulation of the vehicle which consist of a body and four wheels which are all rigid bodies (mainly implemented in vehicle.cpp). I think the rigid body simulation performs as expected and that the issues are more located on the vehicle level (suspension, differential, tyre model, friction model, etc).
I am sure ODE can be used to construct a vehicle that behaves more realistic (that must not necessarily mean the game will be more fun). The point really is, that vehicle must be constructed with the basic objects provided by the framework. The are some examples in the web how to do that, but none of the examples actually felt fun to drive.
A while ago I researched how SuprtTuxKart implements the driving physics and I found out, that the use a higher level vehicle model from the Bullet framework (https://pybullet.org/wordpress/). Please do not be confused, the library is still built in C++ even though the page focuses on Python. I think it is better for our purpose to use a complete vehicle model instead of building an own with ODE. I am afraid, that we will run into the same issues when putting together the vehicle model as we do right now.
So my favourite solution would be to go on the vehicle model provided by Bullet. However, I assume this will be a very complex task. I am thinking of a step by step approach in which I first replace the rigid body simulation of Trigger Rally with the one from Bullet. That needs to be done anyway. If that turns to be too much of work, I am afraid I will stop the whole topic. Nevertheless, there is a lot to learn. :-)
I will anyway upload the refactored code of the existing Trigger Rally simulation to SVN. It removes some unnecessary dependencies between classes and makes their interface more clear and strict.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so very much for taking all the time to look into this.
If the problem really is the vehicle model then of course it would be sensible to concentrate on fixing that instead of just replacing the rigid body simulation.
I am thinking of a step by step approach in which I first replace the rigid body simulation of Trigger Rally with the one from Bullet. That needs to be done anyway.
I don't want to object but why do you think this is necessary anyway? Just to even have the option to make progress in direction of a more satisfactory physics engine behaviour?
I think it is better for our purpose to use a complete vehicle model instead of building an own with ODE.
SuperTuxKart is fun but the physics simulation does feel much less adequate for Trigger Rally than the one we already have. Maybe this is only related to how it is configured but I just wanted to make clear that in my view Trigger Rally's physical behaviour is certainly not optimal but still preferable over what I have experienced in any other free racing game, including projects like Torcs and Stunt Rally.
I will anyway upload the refactored code of the existing Trigger Rally simulation to SVN. It removes some unnecessary dependencies between classes and makes their interface more clear and strict.
Do I understand properly that you optimised the existing code (while you were exploring the options) without changing its function and what you uploaded should only be different if I look at the code but not from what I get when using it?
I am very glad that you are interested and want to learn more about this by doing your best to improve Trigger Rally since it is a project I am rather fond of ... even many years after discovering it as the only rally game my old laptop could sensibly run. And I still love that it allows to drift. I don't know any other free game that does allow drifting in an even close as satisfactory manner.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you so very much for taking all the time to look into this.
If the problem really is the vehicle model then of course it would be sensible to concentrate on fixing that instead of just replacing the rigid body simulation.
Believe me, I tried fixing the vehicle model. I spent days in that, but it led nowhere. :-)
The point is, that some calculations are based on magic formulas instead of physics. They work in most scenarios, but have certain limitations (e.g. gravity or rear wheel drive). I replaced huge parts of the code of vehicle.cpp with proper physical formulas, but the results were always worse than before. I even assume, that these magic formulas are key to the fun driving behaviour of the game that we all like. Maybe something more realistic is just not as fun. In a real car drifting is very, very difficult. You can also notice that, when driving some of the realistic commercial driving simulators (e.g. Assetto Corsa).
I don't want to object but why do you think this is necessary anyway? Just to even have the option to make progress in direction of a more satisfactory physics engine behaviour?
My idea to implement the rigid body model of ODE or Bullet is more of a study. And you are correct, replacing the rigid body implementation would be a first step to go to a physics engine like ODE or Bullet. I will spent a few hours on this approach. I think I will very quickly realize whether this is doable with a reasonable amount of work or not.
Do I understand properly that you optimised the existing code (while you were exploring the options) without changing its function and what you uploaded should only be different if I look at the code but not from what I get when using it?
Yes, that is exactly what refactoring is about. You change the code to make it follow certain coding or design rules but the goal is, that the code behaves exactly the same as before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Believe me, I tried fixing the vehicle model. I spent days in that, but it led nowhere. :-)
Oh, the I misunderstood what you wrote.
some calculations are based on magic formulas instead of physics.
In my experience something only seems like magic if we aren't aware of all relevant aspects. (Still, unfortunately I myself know this impression all to well.) But I don't write this in order to push you to dig deeper into this. I don't want you to do things you aren't happy to do.
Maybe something more realistic is just not as fun.
Indeed, that might be the case.
I will spent a few hours on this approach. I think I will very quickly realize whether this is doable with a reasonable amount of work or not.
This sounds like a very good plan.
the code behaves exactly the same as before.
Great. I will test it today. (I'm working on a new event again anyway.)
Did you ever check if the speed is calculated properly on the OSD? To me it feels the cars gain speed much to fast without the visuals fitting such high speeds. But I may be wrong about this because the roads in the game are usually much wider than in reality.
My newer maps mostly use narrower roads and they feel very difficult but in comparison to reality it is still wider.
Maybe this is the real reason why the cars are so hard to handle at high speeds. In reality it most likely wouldn't be possible to drive cars on such uneven terrain with such high speeds. Could it be that the cars are just overpowered and that we should have much trickier maps to make racing with much lower powered cars more interesting?
Last edit: Onsemeliot 2021-04-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found that after refactoring re-setting the car with "q" at the last checkpoint or with "r" in place doesn't work any longer. Did you possibly remove code that was necessary for that functionality?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want give an intermediate report of my progress with integrating a new physics engine into the game. I was finally able to somewhat achieve the goal is set for myself in the beginning of the week. I replaced the rigid body implementation with the the one of the Bullet library. The change was done in one or two evening sessions. After that, I had to spent hours and hours for debugging, but more of that later. First I have to say, that my respect for the original creators of the game grew even more. They implemented a complete rigid body simulation in a minimum number of code lines. The simulation does almost exactly the same as Bullet with only a fraction of the code. However as I mentioned, I discovered one exception, that made my head almost explode. :-)
Depending on how the vehicle was turned on the map, it started sinking into the track. For instance, if I was driving North, everything worked as with the old rigid body simulation. Once I turned South, the vehicle started sinking into the ground and was kind of swimming on the ground like in water. After hours of analysis I was able to identify the root cause. As I said Bullet's and Trigger Rally's rigid body code works almost the same. However the way the angular velocity is integrated into a rotation quaternion in the 3 dimensional space is different. I went back and forth through Wikipedia and I came to the conclusion, that the one from Bullet is definitely correct. I tried to follow the calculation from the Trigger Rally code. It uses the function "fromThreeAxisAngle" from the Trigger Rally maths library, but I was not able to find an explanation for the calculation. It looks like the function works perfectly for the purpose of Trigger Rally, but it fails when following the school book way of rigid body implementations.
I developed a work-around for that issue. I put my source code directory of the game into the attached ZIP file, so that you can try it. Please note, that some aspects of the vehicle physics are disabled, e.g. air drag, collisions or the handling when the car is flipped. However, the wheels are simulated and basic driving is possible. You have to install the development package of Bullet to compile the game now (e.g. the package "libbullet-dev" for distributions based on Debian).
The next step is to move the terrain implementation to Bullet. Then there will be two rigid bodies in the world of the game, the vehicle and the ground. This would be the precondition to use the vehicle model of Bullet and other features like collision detection. I am not sure how difficult this will be, so maybe I will not be able to finish this task. However, there will be even more to learn and that is my main motivation right now. :-)
The simulation does almost exactly the same as Bullet with only a fraction of the code.
I don't want to dminish the achievement of Jareiko (and her team) but don't you think Bullet might be more versatile and therefore need more code for that reason? I suspect it has seen quite some development while Trigger Rally's engine just stayed the same over the years.
After hours of analysis I was able to identify the root cause.
I know this kind of experience very well. I often spend hours to only find a missing comma or a mis-spelled variable name in the PHP or Javascript.
I put my source code directory of the game into the attached ZIP file, so that you can try it.
Thanks. I will test it as soon as possible.
The next step is to move the terrain implementation to Bullet.
Dare I ask if you are aware of a more versatile way to generate the terrain? The limiting factor so far has been that the road gets very bumpy if I try to create something with big height variations. The later added blur filter tag helped in that regard but it is still rather limited. Together with higher resolution height maps I was able to get steeper terrain while being able to maintain a somewhat drivable road. But this has a price: at least on my dated hardware I can't go above a visible tile size of 64 without getting my system to make a slide show instead of a smooth animation. This also has been frustrating when I wanted to create a road along a steep slope or along some water body where the bank on the other side is quickly outside the visible tile. The only way to hide how strange it looks has been to use rather thick fog. So, using higher resolution images (and smaller horizontal scaling factors) effectively limits how far the terrain can be rendered. I fear there is no good solution for this but maybe I am just not aware of it. So I wanted to mention it ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to add the terrain to the Bullet physics simulation, so that the cars can drive around on it. Then I found out, that Farrer has actually already achieved the same goal about 4 year ago (links below for reference). He ported Trigger Rally to work with the Bullet engine. First, I have to say, that his work is really impressive and he came much further then I did so far.
I mainly ran into the same problem, that he describes in the discussion. The current Trigger Rally implementation only simulates the top four edges of the vehicle plus the four wheels. So the bottom side of the car body never comes into conflict with the terrain. However, a proper physics engine simulates the vehicle body has a whole (including the bottom face of the cuboid). So the bottom side comes into contact with the terrain from time to time (which quite is bumpy as you noticed) and the vehicle is stuck as a result.
I am not sure, if there is a solution for this topic (maybe SuperTuxKart has one). I will continue to give it some thoughts. However, I will not proceed with the porting to Bullet unless I see a chance to solve that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dare I ask if you are aware of a more versatile way to generate the terrain? The limiting factor so far has been that the road gets very bumpy if I try to create something with big height variations. The later added blur filter tag helped in that regard but it is still rather limited. Together with higher resolution height maps I was able to get steeper terrain while being able to maintain a somewhat drivable road. But this has a price: at least on my dated hardware I can't go above a visible tile size of 64 without getting my system to make a slide show instead of a smooth animation. This also has been frustrating when I wanted to create a road along a steep slope or along some water body where the bank on the other side is quickly outside the visible tile. The only way to hide how strange it looks has been to use rather thick fog. So, using higher resolution images (and smaller horizontal scaling factors) effectively limits how far the terrain can be rendered. I fear there is no good solution for this but maybe I am just not aware of it. So I wanted to mention it ...
Can you share an example of a track with leads to the performance issues (the worst example you have :-)) and a track that has the issue with strange look of the other side of a deep valley? Then I will try to understand the issue and search for possible solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Farrer has actually already achieved the same goal about 4 year ago
Sorry, I wasn't aware of that. Probably back then I didn't even know what "Bullet" was.
the bottom side comes into contact with the terrain from time to time ... and the vehicle is stuck as a result.
Wouldn't the obvious solution for that be that the terrain doesn't get generated with such bumpy variation? I suspect the bumps were mainly introduced to counter the strange smoothness of the terrain if the height map had a rather low resolution. And in the early twothousands low resolution height maps probably were a necessity because of the comparably weak graphics performance of systems at the time.
Of course removing random height variation would mean to re-calibrate all maps. And this would be a huge task since all height maps would need to be re-drawn. But it might be worth it. If the physics engine does work as expected the terrain touching the bottom in rare extreme cases should help the realism of the simulation.
Maybe the dampers can't be so soft either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to find a solution for the problem in which the bottom of the vehicle hits the ground thanks to Farrer's code which enables to view the physical world as a wireframe inside the game graphics. You can enable it by defining RENDER_DEBUG_BULLET right over the #if at the bottom of sim.cpp. It is quite slow when playing larger tracks, but it is helpful to understand where the physical objects are placed in the world. Now the cars have a decent height and they only hit the ground where they should.
I continued a little bit and I found a vehicle tuning which is quite fun to play. I added the "src" directory as a ZIP file. The code only works with the Cordo Kit-Car, because it contains some hardcoded parameters. You can test the current state. I am quite interested in your feedback. I can work in some further improvements based on your feedback. I think we are at the point at which we have to decide, whether it makes sense to go ahead with the Bullet physics or not. I think Bullet will make it easier to extend the game with even more features and we will have driving physics work for different vehicle setups like rear wheel drive cars.
This is a list of features which work and do not work in the attached ZIP file.
What works:
- Basic driving with Cordo Kit-Car
- Ground coefficient effects vehicle behavior
- Dirt throw works, but might need some improvement
- Engine and skid sounds
What does not work:
- All other cars but the Cordo Kit-Car
- Resetting the car
- Collision with road objects (will be ported to Bullet, if we decide to stick with it)
- Car damage
- Ghosts behave weirdly
Thank you. Unfortunately my make command fails. Do I need to include bullet beforehand somewhere somehow?:
$ 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 -lLinearMath -lBulletCollision -lBulletDynamics
g++ PEngine/app.cpp -> PEngine/app.o
In file included from ./include/app.h:22,
from PEngine/app.cpp:8:
./include/vmath.h:9:10: fatal error: LinearMath/btMatrix3x3.h: No such file or directory
#include <LinearMath/btMatrix3x3.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [GNUmakefile:166: PEngine/app.o] Error 1
Can you share an example of a track with leads to the performance issues
On my old ThinkPad T400s practically every map does have this performance problem if I set the tile size to anything greater than 64.
The problem with a cut off water surface ending as a straight line above the ground is always visible when the water area is greater than the tile size. To avoid this I try to keep the water areas small enough to not get that effect. But on maps with bigger water surfaces you can easily see it. In the single race map "Holiday Expedition" you can see the problem right from the start.
Last edit: Onsemeliot 2021-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed the tilesize from 64 to 128 in a couple of maps and it works perfectly on my machine. I am not sure, whether just increasing the tilesize of an existing map is the correct approach. The only point I notice is, that the frame rate does not constantly stay at 60 fps as in the smaller maps. My notebook is from 2016, so I assume it is a different league as the T400. :-)
I tried the track "Holiday Expedition" map and I think I get what you mean. The issue is, that there is a limited viewing distance, that can especially be noticed in very flat maps. I never felt this as an issue. Basically you can notice, that terrain tiles are loaded and unloaded while driving in most of the maps. I fear this can only be improved on the cost of performance. I also fear, that my machine is too new and fast to notice performance issues and to help fix them. Maybe I can try to downclock my machine to experience them. ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't mind the viewing distance issue! It isn't a big problem. I only wanted to mention it because there might have been an easy fix. Usually I try to keep the games' footprint low so that even people with slow/old systems can keep using it.
Sorry, I overlooked that I need to install bullet. I have done it now. And – as usual – it instantly worked.
Interesting: The car feels very heavy because the steering doesn't react as easily. (I use the keyboards arrow buttons to steer.) In "Banana Island" the steering only allows me to change direction when I press very hard and long to turn. And then it will only change direction suddenly and extremely. Therefore, I cant even move ahead along the road. This seems to be different on dusty dirt roads like "Authentic". It works much better on "Blunt" too. But I have clipping issues with steeper terrain and the wheels move very oddly. Maybe this is mainly because I can see the inside of the wheels instead of the outside. And the car obviously doesn't roll automatically on its wheels any more if it lands on its side. I suspect this is more realistic.
Over all steering seems to work only somehow reasonable at higher speeds but at the same time the way the car lies on the ground feels more natural. I am having difficulties to get to high enough speeds to test if drifting in curves would even be possible.
The dirt animation often starts well above the car and sometimes looks as if someone would throw a smoke bomb in an arch away from the car.
In its present state the bullet engine would be clearly worse than the old since I am hardly able to keep the car on the road and I see display issues but at the same time over all the simulation of gravity feels more convincing than with the old engine.
If it is possible to solve the described issues it might be worth keeping bullet. And it is amazing that you managed to swap the physics engine so quickly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In its present state the bullet engine would be clearly worse than the old since I am hardly able to keep the car on the road and I see display issues but at the same time over all the simulation of gravity feels more convincing than with the old engine.
If it is possible to solve the described issues it might be worth keeping bullet. And it is amazing that you managed to swap the physics engine so quickly.
I will definitely continue to fix the issues you observe. I attached a later version of the code (src3.tar.gz). This version brings some improvements of the dirt throw feature (I noticed the same behavior as you) and collisions objects and damage are working again (except damage when crashing with the terrain itself).
Interesting: The car feels very heavy because the steering doesn't react as easily. (I use the keyboards arrow buttons to steer.) In "Banana Island" the steering only allows me to change direction when I press very hard and long to turn. And then it will only change direction suddenly and extremely. Therefore, I cant even move ahead along the road. This seems to be different on dusty dirt roads like "Authentic". It works much better on "Blunt" too.
Over all steering seems to work only somehow reasonable at higher speeds but at the same time the way the car lies on the ground feels more natural. I am having difficulties to get to high enough speeds to test if drifting in curves would even be possible.
You can tune the acceleration and friction behavior of the car in the file "src/PSim/vehicle.cpp" by modifying the lines 1523 and 1525.
The friction slip parameter is basically the coefficient of friction (see link below). I tuned it to 1.8 times the friction coefficient of the terrain. The rest of the formula only comes into picture, if the car is damaged. In reality even for ideal conditions, like rubber tire on dry asphalt, the coefficient is only around 0.8. I assume 1.8 cannot even be achieved by F1 vehicles with their wings. This basically confirms what I always expected. The driving behavior of Trigger Rally is anything but realistic (even thought it is fun :-)). You can try to change the coefficient to 0.8 and you will notice, that turning becomes even more difficult. This is realistic vehicle behavior, because a tire can only deliver forces to the road up to a certain level. This level corresponds in a linear way to the coefficient (see second link below). When I tried to change the Trigger Rally code to physical formulas before porting to Bullet, I received exactly the same behavior.
I think it is OK to change the value to an unrealistic range, because Trigger Rally is not a driving simulator. The current engine gives you a better turning behavior through some kind of fake drifting which works well for front wheel driven cars, but fails with rear wheel driven cars. I saw, that Farrer also tried to implement some kind of fake drifting and that some people in the Bullet community discussed the same topic. If you like, I can try to implement such a feature. I just want to emphasize, that the drifting that the current game engine allows is completely fake. Real drifting works completely different is very difficult to control (especially if you drive with a keyboard :-)).
This line controls the engine force. The constant 15.0 is just a best guess. You can change it a s you wish to see how it influences driving.
But I have clipping issues with steeper terrain and the wheels move very oddly. Maybe this is mainly because I can see the inside of the wheels instead of the outside. And the car obviously doesn't roll automatically on its wheels any more if it lands on its side. I suspect this is more realistic.
That one freaks me out completely. I had the same issue with the wheels being turned inside-out when I developed the current code. I thought I found a solution for it, but it looks like the behavior is still different on your system even though the current code seems to work for me. Maybe Google has an explanation for this :-).
Do you have an example for a map or a location (screenshots are also welcome) for a clipping issue with steeper terrain?
The dirt animation often starts well above the car and sometimes looks as if someone would throw a smoke bomb in an arch away from the car.
This should be improved in the updated code. Please let me know, if you still see issues.
Regarding the rendering problem with the wheel, do the wheels look correctly, if you remove the minus from line 1957 in the file "src/Trigger/render.cpp"?
I think it is OK to change the value to an unrealistic range, because Trigger Rally is not a driving simulator.
I don't oppose that thought but I fear altering such physics behaviour might make things more difficult in the long run since it probably makes the behaviour unpredictable. Since real world physics do actually cause the behaviour we want to get I suspect it would be less chaotic and more satisfying to fine-tune the properties of the vehicle instead of the physics simulation itself.
If there is an understandable reason for why physics in the real world lead to different outcomes then it might be worth to consider introducing those factors instead of faking something that has unintended side effects.
Taking away the minus in line 1957 of render.cpp indeed solves the problem of the inside out wheels for me.
The new version feels much better. The car sits very well on the ground and it really doesn't feel any longer like the often complained about moon gravity. So far I don't actually miss the drifting experience much either because the physics simulation feels so much more satisfying. Especially jumps feel very convincing compared to the old engine.
I didn't have the time yet to alter the parameters you pointed out but things I noticed are:
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.
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.
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.)
Driving on ice and snow has surprisingly little effect on the physics.
I will do some more testing soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I developed another version over the weekend that should improve the driving behaviour even further. So please do not spend too much time testing the previous version. The new version has different suspension settings that were also used by Farrer based on the work of another author using the Bullet vehicle implementation. The suspension settings are still hard-coded, but work quite well for all vehicles. The new version also works with all three Kit-Cars.
It furthermore includes ghosts and damage after crashes with the terrain. However, the old ghost files have to be deleted, because I had to change the logic, so that the code becomes more clear (old ghosts will still behave weird). It should also fix the wheel display problems. This version should support all features as before, even though they still might need to be fine-tuned.
I will try to upload the version today night. If that is not possible, I will upload it tomorrow evening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you know Stormbaan Coureur? It already has a fantastic physics engine and seems to be written in C++ too. So it might be compatible with Trigger Rally. Combined with what we built already this could be amazing.
This way we could get rid of Trigger Rallys old "moon gravity" problem at once. And I suspect it should be possible to adapt the Stormbaan Coureur code to also use our different terrain physics values and to use different attribute values like weight and dimensions for different vehicles. Heck, it might even be possible to use different wheel attributes to simulate more or less grip on different terrain like rainy tarmac, mud etc. or wheel types. Since it has real shadows too we could even push the game to a point where it was possible to use lights and shadows (such as head and tail lights).
I feel Trigger Rally already has a much better physics engine than most other free racing games such as Stunt Rally or even Torcs. But a constant pain is the problem of losing control at higher speeds. Unfortunately this still doesn't feel very realistic or fun. (Even if it has gotten much better trough recent code improvements.) With Stormbaan Coureur's physics engine it could incorporate the best available in free games so far and further improve on design and options for variation in maps.
Stormbaan Coureur also already includes the possibility to interact with other rigid bodies. This could come in handy for things like fences and walls or even obstacles like barrels that aren't fully static. I see great potential and it seems very odd to me that the obviously very well done physics engine from Stormbaan Coureur has been laying dormant for so long while other games are struggling to get a decent physics calculation for car racing done.
I do not have any clue how difficult it would be to integrate one solution into the other. Maybe it would be easier to do it the other way around and to add the Trigger Rally features to a fork of Stormbaan Coureur. Or maybe they aren't sensibly combinable at all.
In my view one of the best car racing games in the proprietary world in recent years has been Next Car Game and Trigger Rally in combination with Stormbaan Coureur could gain many of the most fun features of that. Maybe even without requiring to much processing power since Stormbaan Coureur is rather old now too and therefore it shouldn't demand to much from the players system.
Last edit: Onsemeliot 2021-02-27
The game Stormbaan Coureur uses the Open Dynamics Engine to simulate physics. This engine seems quite suitable to simulate a car. There are some examples available that show how it can be done (link below). It sound quite interesting to replace the existing engine with a more sophisticated alternative. I will check how big a task it will be to replace the heart of the game. :-)
https://www.ode.org/
http://ode.org/wiki/index.php?title=HOWTO_build_a_4_wheel_vehicle
Cool, thank you very much for looking into that. let me know what you think!
Great idea!
IMO it would be interesting having option to choose one of this engines in the "* .level" script in order to preserve old style feeling for some enthusiast.
Cordial greetings,
Janusz
I finally had the chance to have a closer look into this topic. The Open Dynamics Engine (ODE) performs rigid body simulation which is basically what Trigger Rally is already doing. So I thought it would be cool to add a second more sophisticated rigid body simulator to the game as Janusz suggested. I even started refactoring the Trigger Rally simulation code to have a cleaner interface. Behind that I planned to hide the ODE implementation.
During the process I realized, that replacing the rigid body simulation will most likely not solve the main problems with the game's car behaviour (e.g. moon like gravity). This discussion from a while ago basically comes to the same conclusion:
https://sourceforge.net/p/trigger-rally/bugs/7/
The background is, that the vehicle simulation consist of two layers. The lower layer is the already mentioned rigid body simulation (mainly located in rigidbody.cpp, psim.h and sim.cpp). The higher level part is the simulation of the vehicle which consist of a body and four wheels which are all rigid bodies (mainly implemented in vehicle.cpp). I think the rigid body simulation performs as expected and that the issues are more located on the vehicle level (suspension, differential, tyre model, friction model, etc).
I am sure ODE can be used to construct a vehicle that behaves more realistic (that must not necessarily mean the game will be more fun). The point really is, that vehicle must be constructed with the basic objects provided by the framework. The are some examples in the web how to do that, but none of the examples actually felt fun to drive.
A while ago I researched how SuprtTuxKart implements the driving physics and I found out, that the use a higher level vehicle model from the Bullet framework (https://pybullet.org/wordpress/). Please do not be confused, the library is still built in C++ even though the page focuses on Python. I think it is better for our purpose to use a complete vehicle model instead of building an own with ODE. I am afraid, that we will run into the same issues when putting together the vehicle model as we do right now.
So my favourite solution would be to go on the vehicle model provided by Bullet. However, I assume this will be a very complex task. I am thinking of a step by step approach in which I first replace the rigid body simulation of Trigger Rally with the one from Bullet. That needs to be done anyway. If that turns to be too much of work, I am afraid I will stop the whole topic. Nevertheless, there is a lot to learn. :-)
I will anyway upload the refactored code of the existing Trigger Rally simulation to SVN. It removes some unnecessary dependencies between classes and makes their interface more clear and strict.
Thank you so very much for taking all the time to look into this.
If the problem really is the vehicle model then of course it would be sensible to concentrate on fixing that instead of just replacing the rigid body simulation.
I don't want to object but why do you think this is necessary anyway? Just to even have the option to make progress in direction of a more satisfactory physics engine behaviour?
SuperTuxKart is fun but the physics simulation does feel much less adequate for Trigger Rally than the one we already have. Maybe this is only related to how it is configured but I just wanted to make clear that in my view Trigger Rally's physical behaviour is certainly not optimal but still preferable over what I have experienced in any other free racing game, including projects like Torcs and Stunt Rally.
Do I understand properly that you optimised the existing code (while you were exploring the options) without changing its function and what you uploaded should only be different if I look at the code but not from what I get when using it?
I am very glad that you are interested and want to learn more about this by doing your best to improve Trigger Rally since it is a project I am rather fond of ... even many years after discovering it as the only rally game my old laptop could sensibly run. And I still love that it allows to drift. I don't know any other free game that does allow drifting in an even close as satisfactory manner.
Believe me, I tried fixing the vehicle model. I spent days in that, but it led nowhere. :-)
The point is, that some calculations are based on magic formulas instead of physics. They work in most scenarios, but have certain limitations (e.g. gravity or rear wheel drive). I replaced huge parts of the code of vehicle.cpp with proper physical formulas, but the results were always worse than before. I even assume, that these magic formulas are key to the fun driving behaviour of the game that we all like. Maybe something more realistic is just not as fun. In a real car drifting is very, very difficult. You can also notice that, when driving some of the realistic commercial driving simulators (e.g. Assetto Corsa).
My idea to implement the rigid body model of ODE or Bullet is more of a study. And you are correct, replacing the rigid body implementation would be a first step to go to a physics engine like ODE or Bullet. I will spent a few hours on this approach. I think I will very quickly realize whether this is doable with a reasonable amount of work or not.
Yes, that is exactly what refactoring is about. You change the code to make it follow certain coding or design rules but the goal is, that the code behaves exactly the same as before.
Oh, the I misunderstood what you wrote.
In my experience something only seems like magic if we aren't aware of all relevant aspects. (Still, unfortunately I myself know this impression all to well.) But I don't write this in order to push you to dig deeper into this. I don't want you to do things you aren't happy to do.
Indeed, that might be the case.
This sounds like a very good plan.
Great. I will test it today. (I'm working on a new event again anyway.)
Did you ever check if the speed is calculated properly on the OSD? To me it feels the cars gain speed much to fast without the visuals fitting such high speeds. But I may be wrong about this because the roads in the game are usually much wider than in reality.
My newer maps mostly use narrower roads and they feel very difficult but in comparison to reality it is still wider.
Maybe this is the real reason why the cars are so hard to handle at high speeds. In reality it most likely wouldn't be possible to drive cars on such uneven terrain with such high speeds. Could it be that the cars are just overpowered and that we should have much trickier maps to make racing with much lower powered cars more interesting?
Last edit: Onsemeliot 2021-04-26
I found that after refactoring re-setting the car with "q" at the last checkpoint or with "r" in place doesn't work any longer. Did you possibly remove code that was necessary for that functionality?
Very good testing from your side. I was able to locate the root cause and commit a fix for that issue.
This was a really good example why pre-processor programming should be avoided as much as possible. :-)
Fantastic that you could fix it so quickly. :)
I want give an intermediate report of my progress with integrating a new physics engine into the game. I was finally able to somewhat achieve the goal is set for myself in the beginning of the week. I replaced the rigid body implementation with the the one of the Bullet library. The change was done in one or two evening sessions. After that, I had to spent hours and hours for debugging, but more of that later. First I have to say, that my respect for the original creators of the game grew even more. They implemented a complete rigid body simulation in a minimum number of code lines. The simulation does almost exactly the same as Bullet with only a fraction of the code. However as I mentioned, I discovered one exception, that made my head almost explode. :-)
Depending on how the vehicle was turned on the map, it started sinking into the track. For instance, if I was driving North, everything worked as with the old rigid body simulation. Once I turned South, the vehicle started sinking into the ground and was kind of swimming on the ground like in water. After hours of analysis I was able to identify the root cause. As I said Bullet's and Trigger Rally's rigid body code works almost the same. However the way the angular velocity is integrated into a rotation quaternion in the 3 dimensional space is different. I went back and forth through Wikipedia and I came to the conclusion, that the one from Bullet is definitely correct. I tried to follow the calculation from the Trigger Rally code. It uses the function "fromThreeAxisAngle" from the Trigger Rally maths library, but I was not able to find an explanation for the calculation. It looks like the function works perfectly for the purpose of Trigger Rally, but it fails when following the school book way of rigid body implementations.
I developed a work-around for that issue. I put my source code directory of the game into the attached ZIP file, so that you can try it. Please note, that some aspects of the vehicle physics are disabled, e.g. air drag, collisions or the handling when the car is flipped. However, the wheels are simulated and basic driving is possible. You have to install the development package of Bullet to compile the game now (e.g. the package "libbullet-dev" for distributions based on Debian).
The next step is to move the terrain implementation to Bullet. Then there will be two rigid bodies in the world of the game, the vehicle and the ground. This would be the precondition to use the vehicle model of Bullet and other features like collision detection. I am not sure how difficult this will be, so maybe I will not be able to finish this task. However, there will be even more to learn and that is my main motivation right now. :-)
Last edit: marsch84 2021-05-02
I don't want to dminish the achievement of Jareiko (and her team) but don't you think Bullet might be more versatile and therefore need more code for that reason? I suspect it has seen quite some development while Trigger Rally's engine just stayed the same over the years.
I know this kind of experience very well. I often spend hours to only find a missing comma or a mis-spelled variable name in the PHP or Javascript.
Thanks. I will test it as soon as possible.
Dare I ask if you are aware of a more versatile way to generate the terrain? The limiting factor so far has been that the road gets very bumpy if I try to create something with big height variations. The later added blur filter tag helped in that regard but it is still rather limited. Together with higher resolution height maps I was able to get steeper terrain while being able to maintain a somewhat drivable road. But this has a price: at least on my dated hardware I can't go above a visible tile size of 64 without getting my system to make a slide show instead of a smooth animation. This also has been frustrating when I wanted to create a road along a steep slope or along some water body where the bank on the other side is quickly outside the visible tile. The only way to hide how strange it looks has been to use rather thick fog. So, using higher resolution images (and smaller horizontal scaling factors) effectively limits how far the terrain can be rendered. I fear there is no good solution for this but maybe I am just not aware of it. So I wanted to mention it ...
I was able to add the terrain to the Bullet physics simulation, so that the cars can drive around on it. Then I found out, that Farrer has actually already achieved the same goal about 4 year ago (links below for reference). He ported Trigger Rally to work with the Bullet engine. First, I have to say, that his work is really impressive and he came much further then I did so far.
https://sourceforge.net/p/trigger-rally/patches/9/
https://github.com/farrer/trigger-rally-bullet
I mainly ran into the same problem, that he describes in the discussion. The current Trigger Rally implementation only simulates the top four edges of the vehicle plus the four wheels. So the bottom side of the car body never comes into conflict with the terrain. However, a proper physics engine simulates the vehicle body has a whole (including the bottom face of the cuboid). So the bottom side comes into contact with the terrain from time to time (which quite is bumpy as you noticed) and the vehicle is stuck as a result.
I am not sure, if there is a solution for this topic (maybe SuperTuxKart has one). I will continue to give it some thoughts. However, I will not proceed with the porting to Bullet unless I see a chance to solve that.
Can you share an example of a track with leads to the performance issues (the worst example you have :-)) and a track that has the issue with strange look of the other side of a deep valley? Then I will try to understand the issue and search for possible solution.
Sorry, I wasn't aware of that. Probably back then I didn't even know what "Bullet" was.
Wouldn't the obvious solution for that be that the terrain doesn't get generated with such bumpy variation? I suspect the bumps were mainly introduced to counter the strange smoothness of the terrain if the height map had a rather low resolution. And in the early twothousands low resolution height maps probably were a necessity because of the comparably weak graphics performance of systems at the time.
Of course removing random height variation would mean to re-calibrate all maps. And this would be a huge task since all height maps would need to be re-drawn. But it might be worth it. If the physics engine does work as expected the terrain touching the bottom in rare extreme cases should help the realism of the simulation.
Maybe the dampers can't be so soft either.
I was able to find a solution for the problem in which the bottom of the vehicle hits the ground thanks to Farrer's code which enables to view the physical world as a wireframe inside the game graphics. You can enable it by defining RENDER_DEBUG_BULLET right over the #if at the bottom of sim.cpp. It is quite slow when playing larger tracks, but it is helpful to understand where the physical objects are placed in the world. Now the cars have a decent height and they only hit the ground where they should.
I continued a little bit and I found a vehicle tuning which is quite fun to play. I added the "src" directory as a ZIP file. The code only works with the Cordo Kit-Car, because it contains some hardcoded parameters. You can test the current state. I am quite interested in your feedback. I can work in some further improvements based on your feedback. I think we are at the point at which we have to decide, whether it makes sense to go ahead with the Bullet physics or not. I think Bullet will make it easier to extend the game with even more features and we will have driving physics work for different vehicle setups like rear wheel drive cars.
This is a list of features which work and do not work in the attached ZIP file.
What works:
- Basic driving with Cordo Kit-Car
- Ground coefficient effects vehicle behavior
- Dirt throw works, but might need some improvement
- Engine and skid sounds
What does not work:
- All other cars but the Cordo Kit-Car
- Resetting the car
- Collision with road objects (will be ported to Bullet, if we decide to stick with it)
- Car damage
- Ghosts behave weirdly
Thank you. Unfortunately my make command fails. Do I need to include bullet beforehand somewhere somehow?:
$ 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 -lLinearMath -lBulletCollision -lBulletDynamics g++ PEngine/app.cpp -> PEngine/app.o In file included from ./include/app.h:22, from PEngine/app.cpp:8: ./include/vmath.h:9:10: fatal error: LinearMath/btMatrix3x3.h: No such file or directory #include <LinearMath/btMatrix3x3.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make: *** [GNUmakefile:166: PEngine/app.o] Error 1On my old ThinkPad T400s practically every map does have this performance problem if I set the tile size to anything greater than 64.
The problem with a cut off water surface ending as a straight line above the ground is always visible when the water area is greater than the tile size. To avoid this I try to keep the water areas small enough to not get that effect. But on maps with bigger water surfaces you can easily see it. In the single race map "Holiday Expedition" you can see the problem right from the start.
Last edit: Onsemeliot 2021-05-27
Did you install the Bullet development package of your distribution as I described in my comment above?
I changed the tilesize from 64 to 128 in a couple of maps and it works perfectly on my machine. I am not sure, whether just increasing the tilesize of an existing map is the correct approach. The only point I notice is, that the frame rate does not constantly stay at 60 fps as in the smaller maps. My notebook is from 2016, so I assume it is a different league as the T400. :-)
I tried the track "Holiday Expedition" map and I think I get what you mean. The issue is, that there is a limited viewing distance, that can especially be noticed in very flat maps. I never felt this as an issue. Basically you can notice, that terrain tiles are loaded and unloaded while driving in most of the maps. I fear this can only be improved on the cost of performance. I also fear, that my machine is too new and fast to notice performance issues and to help fix them. Maybe I can try to downclock my machine to experience them. ;-)
Don't mind the viewing distance issue! It isn't a big problem. I only wanted to mention it because there might have been an easy fix. Usually I try to keep the games' footprint low so that even people with slow/old systems can keep using it.
Sorry, I overlooked that I need to install bullet. I have done it now. And – as usual – it instantly worked.
Interesting: The car feels very heavy because the steering doesn't react as easily. (I use the keyboards arrow buttons to steer.) In "Banana Island" the steering only allows me to change direction when I press very hard and long to turn. And then it will only change direction suddenly and extremely. Therefore, I cant even move ahead along the road. This seems to be different on dusty dirt roads like "Authentic". It works much better on "Blunt" too. But I have clipping issues with steeper terrain and the wheels move very oddly. Maybe this is mainly because I can see the inside of the wheels instead of the outside. And the car obviously doesn't roll automatically on its wheels any more if it lands on its side. I suspect this is more realistic.
Over all steering seems to work only somehow reasonable at higher speeds but at the same time the way the car lies on the ground feels more natural. I am having difficulties to get to high enough speeds to test if drifting in curves would even be possible.
The dirt animation often starts well above the car and sometimes looks as if someone would throw a smoke bomb in an arch away from the car.
In its present state the bullet engine would be clearly worse than the old since I am hardly able to keep the car on the road and I see display issues but at the same time over all the simulation of gravity feels more convincing than with the old engine.
If it is possible to solve the described issues it might be worth keeping bullet. And it is amazing that you managed to swap the physics engine so quickly.
I will definitely continue to fix the issues you observe. I attached a later version of the code (src3.tar.gz). This version brings some improvements of the dirt throw feature (I noticed the same behavior as you) and collisions objects and damage are working again (except damage when crashing with the terrain itself).
You can tune the acceleration and friction behavior of the car in the file "src/PSim/vehicle.cpp" by modifying the lines 1523 and 1525.
The friction slip parameter is basically the coefficient of friction (see link below). I tuned it to 1.8 times the friction coefficient of the terrain. The rest of the formula only comes into picture, if the car is damaged. In reality even for ideal conditions, like rubber tire on dry asphalt, the coefficient is only around 0.8. I assume 1.8 cannot even be achieved by F1 vehicles with their wings. This basically confirms what I always expected. The driving behavior of Trigger Rally is anything but realistic (even thought it is fun :-)). You can try to change the coefficient to 0.8 and you will notice, that turning becomes even more difficult. This is realistic vehicle behavior, because a tire can only deliver forces to the road up to a certain level. This level corresponds in a linear way to the coefficient (see second link below). When I tried to change the Trigger Rally code to physical formulas before porting to Bullet, I received exactly the same behavior.
https://en.wikipedia.org/wiki/Friction#Coefficient_of_friction
https://en.wikipedia.org/wiki/Circle_of_forces
I think it is OK to change the value to an unrealistic range, because Trigger Rally is not a driving simulator. The current engine gives you a better turning behavior through some kind of fake drifting which works well for front wheel driven cars, but fails with rear wheel driven cars. I saw, that Farrer also tried to implement some kind of fake drifting and that some people in the Bullet community discussed the same topic. If you like, I can try to implement such a feature. I just want to emphasize, that the drifting that the current game engine allows is completely fake. Real drifting works completely different is very difficult to control (especially if you drive with a keyboard :-)).
This line controls the engine force. The constant 15.0 is just a best guess. You can change it a s you wish to see how it influences driving.
That one freaks me out completely. I had the same issue with the wheels being turned inside-out when I developed the current code. I thought I found a solution for it, but it looks like the behavior is still different on your system even though the current code seems to work for me. Maybe Google has an explanation for this :-).
Do you have an example for a map or a location (screenshots are also welcome) for a clipping issue with steeper terrain?
This should be improved in the updated code. Please let me know, if you still see issues.
Last edit: marsch84 2021-06-05
Regarding the rendering problem with the wheel, do the wheels look correctly, if you remove the minus from line 1957 in the file "src/Trigger/render.cpp"?
Original line:
Modified line:
In that case the logic seems to lead to a reversed graphic output on my machine and yours.
I don't oppose that thought but I fear altering such physics behaviour might make things more difficult in the long run since it probably makes the behaviour unpredictable. Since real world physics do actually cause the behaviour we want to get I suspect it would be less chaotic and more satisfying to fine-tune the properties of the vehicle instead of the physics simulation itself.
If there is an understandable reason for why physics in the real world lead to different outcomes then it might be worth to consider introducing those factors instead of faking something that has unintended side effects.
Taking away the minus in line 1957 of render.cpp indeed solves the problem of the inside out wheels for me.
The new version feels much better. The car sits very well on the ground and it really doesn't feel any longer like the often complained about moon gravity. So far I don't actually miss the drifting experience much either because the physics simulation feels so much more satisfying. Especially jumps feel very convincing compared to the old engine.
I didn't have the time yet to alter the parameters you pointed out but things I noticed are:
I will do some more testing soon.
I developed another version over the weekend that should improve the driving behaviour even further. So please do not spend too much time testing the previous version. The new version has different suspension settings that were also used by Farrer based on the work of another author using the Bullet vehicle implementation. The suspension settings are still hard-coded, but work quite well for all vehicles. The new version also works with all three Kit-Cars.
It furthermore includes ghosts and damage after crashes with the terrain. However, the old ghost files have to be deleted, because I had to change the logic, so that the code becomes more clear (old ghosts will still behave weird). It should also fix the wheel display problems. This version should support all features as before, even though they still might need to be fine-tuned.
I will try to upload the version today night. If that is not possible, I will upload it tomorrow evening.