Preview of Rigs of Rods, an offroad truck simulator
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Preview of Rigs of Rods, an offroad truck simulator
Hi all,
Here is my first game: it is an offroad truck simulator. I used Ogre 1.0 for the graphics, Audiere for sounds and I developped the physics engine.
The physics engine is not a rigid-body type, but a soft-body based on particles network.
Trucks are made of interconnected beams. Loads are computed on each beams, which deforms according to the load. The result is a deformable chassis and deformable tires (which are also made of beams) and lots of fun to drive. (making deformable meshes in Ogre is a little less funny , not to mention shadows that are still missing)
This is still a work in progress, but it is downloadable as is at: http://rigsofrods.blogspot.com/
BEWARE: the physics engine is very CPU intensive and the game won't run without at least a 3GHz processor!!! Progress has still to be made to improve the engine efficiency (it still runs on a basic Euler integrator)... Runge Kutta here I am !
Screenshots are here: http://www.flickr.com/photos/68762199@N00/
Cheers, and a big thanks to the Ogre team for their marvelous work!
Pierre-Michel
Here is my first game: it is an offroad truck simulator. I used Ogre 1.0 for the graphics, Audiere for sounds and I developped the physics engine.
The physics engine is not a rigid-body type, but a soft-body based on particles network.
Trucks are made of interconnected beams. Loads are computed on each beams, which deforms according to the load. The result is a deformable chassis and deformable tires (which are also made of beams) and lots of fun to drive. (making deformable meshes in Ogre is a little less funny , not to mention shadows that are still missing)
This is still a work in progress, but it is downloadable as is at: http://rigsofrods.blogspot.com/
BEWARE: the physics engine is very CPU intensive and the game won't run without at least a 3GHz processor!!! Progress has still to be made to improve the engine efficiency (it still runs on a basic Euler integrator)... Runge Kutta here I am !
Screenshots are here: http://www.flickr.com/photos/68762199@N00/
Cheers, and a big thanks to the Ogre team for their marvelous work!
Pierre-Michel
Rigs of Rods: http://rigsofrods.blogspot.com/
- jacmoe
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
- Contact:
Holy /&%¤(&# !!
This is really, really interesting: videos and cherry-picked inline screenies, pretty please!
Refreshing to see a different take on physics!
This is really, really interesting: videos and cherry-picked inline screenies, pretty please!
Refreshing to see a different take on physics!
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- DWORD
- OGRE Retired Moderator
- Posts: 1365
- Joined: Tue Sep 07, 2004 12:43 pm
- Location: Aalborg, Denmark
- Contact:
Holy crap! It's amazing to see how so many cool Ogre projects just pop out of nothing all the time these days.
Didn't try your demo yet; I'll do that tomorrow. But the screenshots look really promising. Does this kind of physics work well for vehicles? Isn't it very difficult to find good parameters for the springs, if that's what they are?
Didn't try your demo yet; I'll do that tomorrow. But the screenshots look really promising. Does this kind of physics work well for vehicles? Isn't it very difficult to find good parameters for the springs, if that's what they are?
- skullfire
- Gremlin
- Posts: 150
- Joined: Sat Mar 19, 2005 7:51 pm
- Location: San Jose, Costa Rica
- Contact:
- BlasterN
- Gnome
- Posts: 378
- Joined: Thu Mar 24, 2005 1:07 am
- Location: Spain
- Contact:
Good screens & vehicle models.
I will try the demo.
I will try the demo.
Works:
MapToMesh | Bengine B9 @ www.sourceforge.net/projects/maptoogremesh/
3DWorldStudio exporter@ www.blastern.info
MapToMesh | Bengine B9 @ www.sourceforge.net/projects/maptoogremesh/
3DWorldStudio exporter@ www.blastern.info
- Olex
- Hobgoblin
- Posts: 593
- Joined: Fri Apr 08, 2005 6:08 pm
- Location: WA, USA
- Jens_K
- Kobold
- Posts: 37
- Joined: Sat Apr 23, 2005 3:44 pm
- Location: Berlin, Germany
- Contact:
Very interesting project!
The view showing the ammount of force working on the single beams is very impressive. ---> giving it a scientific look
Is it for something like vehicle engineering research, or do you have a game-attempt behind this techdemo?
ahhh... Performance, it's a real problem with extended physics like seen in your project. We're having problems with it too, though our game is using rather mainstream methods (novodex ).
Your attempt on deforming wheels is really cool!
I like your selection of vehicles. They're rarely seen in 3D apps.
cool work.
The view showing the ammount of force working on the single beams is very impressive. ---> giving it a scientific look
Is it for something like vehicle engineering research, or do you have a game-attempt behind this techdemo?
ahhh... Performance, it's a real problem with extended physics like seen in your project. We're having problems with it too, though our game is using rather mainstream methods (novodex ).
Your attempt on deforming wheels is really cool!
I like your selection of vehicles. They're rarely seen in 3D apps.
cool work.
- eugen
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
- Contact:
- walaber
- OGRE Expert User
- Posts: 829
- Joined: Sat Oct 02, 2004 2:20 pm
- Location: California, USA
- Contact:
very exciting and interesting project! I like your physics idea, it's new, and seems to work well, especially for the wheels.
I tried the demo on my less than 3GHz system, and it ran fine (albeit really slow), so I'm looking forward to an optimized version!!
either way this project is looking fantastic
I tried the demo on my less than 3GHz system, and it ran fine (albeit really slow), so I'm looking forward to an optimized version!!
either way this project is looking fantastic
- monster
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
- Contact:
Wow! That's really cool. The trucks have a really good feel to them. Your new approach to the physics is very interesting.
I can see this working perfectly in a "Rock Crawling" simulator. With buggies like these;
https://www.spydercustoms.com/index2.ht ... _sally.htm
https://www.spydercustoms.com/index2.ht ... imited.htm
https://www.spydercustoms.com/index2.ht ... livery.htm
I can see this working perfectly in a "Rock Crawling" simulator. With buggies like these;
https://www.spydercustoms.com/index2.ht ... _sally.htm
https://www.spydercustoms.com/index2.ht ... imited.htm
https://www.spydercustoms.com/index2.ht ... livery.htm
You seemed to have managed it very well! Do you deform the meshes 'manually' or are they rigged up to the beams via skeletal animation?making deformable meshes in Ogre is a little less funny
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Thanks for the encouragements!
Yes, a spring array is a good way to model a vehicle, but the springs must be very, very strong so the integrator must run on very small time steps to avoid instabilities. This version uses a simple Euler integrator, with 100 integration steps per frame, and a capping at 20fps (below 20fps, the simulation is not realtime), so the integration steps are never below 1/2000th second (with several hundred nodes to compute)!!! And even with that, the chassis is not as rigid as I would want.
I hope that with a Runge Kutta intergrator it will require less steps per second.
The good news is that the model is extremely simple : I simulate monodimensional beams connected by ball-joint. The consequence is that I do not have to compute anything that has to do with angles (rotational speeds and moments, ...). I just compute nodes movements, and nodes are dimension-less objects. Also I do not compute anything central (center of inertia) and in fact if you split the truck in two, the two parts move independentely and realistically (I have seen impressive wheels run-offs)...
Yet the simulation is realistic : all the rigid body "laws" emerge from the interaction of nodes. You observe that the truck has a center of inertia, moments of intertia, you name it, but it is never explicitely computed.
Since everything is ball-joint, you must triangulate everything, and you can always obtain other joints by contruction (many extra triangulation beams are masked in trucks).
The Beam engine is not opensource, the main reason are that it is a horrible programming mess, and it does not uses a good integrator yet.
It is not vehicule engineering research : it would be too resource consuming to really simulate chassis parts. I intend to add some game logic someday.
I chosed trucks because everybody does cars The initial objective was to do a "truck trial" game :
http://www.europatruck-trial.com/Site-N ... rie_l1.php
with an extremely precise terrain map (~10cm resolution) that deforms under the wheels! But I am afraid the polygon count would be tremendeous...
Meshes are deformed manually. Skeletal would be better since it would allow more complex meshes, but it has the wrong topology for a truck (tree vs mesh).
Yes, a spring array is a good way to model a vehicle, but the springs must be very, very strong so the integrator must run on very small time steps to avoid instabilities. This version uses a simple Euler integrator, with 100 integration steps per frame, and a capping at 20fps (below 20fps, the simulation is not realtime), so the integration steps are never below 1/2000th second (with several hundred nodes to compute)!!! And even with that, the chassis is not as rigid as I would want.
I hope that with a Runge Kutta intergrator it will require less steps per second.
The good news is that the model is extremely simple : I simulate monodimensional beams connected by ball-joint. The consequence is that I do not have to compute anything that has to do with angles (rotational speeds and moments, ...). I just compute nodes movements, and nodes are dimension-less objects. Also I do not compute anything central (center of inertia) and in fact if you split the truck in two, the two parts move independentely and realistically (I have seen impressive wheels run-offs)...
Yet the simulation is realistic : all the rigid body "laws" emerge from the interaction of nodes. You observe that the truck has a center of inertia, moments of intertia, you name it, but it is never explicitely computed.
Since everything is ball-joint, you must triangulate everything, and you can always obtain other joints by contruction (many extra triangulation beams are masked in trucks).
The Beam engine is not opensource, the main reason are that it is a horrible programming mess, and it does not uses a good integrator yet.
It is not vehicule engineering research : it would be too resource consuming to really simulate chassis parts. I intend to add some game logic someday.
I chosed trucks because everybody does cars The initial objective was to do a "truck trial" game :
http://www.europatruck-trial.com/Site-N ... rie_l1.php
with an extremely precise terrain map (~10cm resolution) that deforms under the wheels! But I am afraid the polygon count would be tremendeous...
Meshes are deformed manually. Skeletal would be better since it would allow more complex meshes, but it has the wrong topology for a truck (tree vs mesh).
Rigs of Rods: http://rigsofrods.blogspot.com/
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Re: Preview of Rigs of Rods, an offroad truck simulator
Interesting game concept Fun.
I'm afraid Runge-Kutta won't help you to get your integration faster (just much more stable, but slower). I think it's better to consider Leapfrog or Verlet instead. At least that's my experience.pricorde wrote: (it still runs on a basic Euler integrator)... Runge Kutta here I am !
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Re: Preview of Rigs of Rods, an offroad truck simulator
That's interesting. I supposed that since Runge-Kutta is more stable, I would be able to reduce the number of steps per frame.:wumpus: wrote:Interesting game concept Fun.I'm afraid Runge-Kutta won't help you to get your integration faster (just much more stable, but slower). I think it's better to consider Leapfrog or Verlet instead. At least that's my experience.pricorde wrote: (it still runs on a basic Euler integrator)... Runge Kutta here I am !
For example if RK allows me to go from 100 steps/frame (dt=1/2000) to 10 steps/frame (dt=1/200), that's a ten-fold reduction of the number of steps. So even is a RK step is a little slower (e.g. 5 times) there is still a 2x gain.
What do you think? I do not have a lot of experience in integrator performances.
I will check Leapfrog Verlet (which seems also easiest to implement than RK)...
Rigs of Rods: http://rigsofrods.blogspot.com/
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Re: Preview of Rigs of Rods, an offroad truck simulator
I think that's a mistake a lot of people make; I did it once too. Although R-K is fabulously more stable than Euler, it doesn't allow for much larger timesteps for getting the same resolution. Depending on the forces you might be able to increase the timestep somewhat, but almost certainly not enough to beat Euler in performance.pricorde wrote: That's interesting. I supposed that since Runge-Kutta is more stable, I would be able to reduce the number of steps per frame.
For example if RK allows me to go from 100 steps/frame (dt=1/2000) to 10 steps/frame (dt=1/200), that's a ten-fold reduction of the number of steps. So even is a RK step is a little slower (e.g. 5 times) there is still a 2x gain.
What do you think? I do not have a lot of experience in integrator performances.
Good idea.I will check Leapfrog Verlet (which seems also easiest to implement than RK)...
-
- Google Summer of Code Mentor
- Posts: 295
- Joined: Fri Aug 06, 2004 10:25 pm
Yes, RK2 or a midpoint integrator is by far more stable that the euler, but even when you can do larger time steps because the result approximation is better, you have to do more calculations per time step, calculating the derivative multiple times per step
In Runge-Kutta2, first an Euler integration is done with the half of the time step, then the derivatives ar calculated, at the midpoint, and these are used to complete the time step
So better stability, yes, but if you are looking for improving the performance of your integrator, as :wumpus: pointed, there are other alternatives
what is interesting is this Semi-Implicit Euler, i have to try it sometime on some project, it claims to have better stability than euler
read about it here http://www.cs.unc.edu/~coombe/comp259/hw1/
Lioric
In Runge-Kutta2, first an Euler integration is done with the half of the time step, then the derivatives ar calculated, at the midpoint, and these are used to complete the time step
So better stability, yes, but if you are looking for improving the performance of your integrator, as :wumpus: pointed, there are other alternatives
what is interesting is this Semi-Implicit Euler, i have to try it sometime on some project, it claims to have better stability than euler
read about it here http://www.cs.unc.edu/~coombe/comp259/hw1/
Lioric
- BlasterN
- Gnome
- Posts: 378
- Joined: Thu Mar 24, 2005 1:07 am
- Location: Spain
- Contact:
I test the game now.
I have to say one thing I don't like the gameplay in some vehicles like the connected bus, I see when I try to "climp" a mountain if the bus can reach the top slide and the collisions goes crazy, 4 fps with 3200 amd64...
When the vehicle upset i can't use reinitialize. you must put a key that put the car over the terrain.
It's really good concept but need to be optimized (everybody knows that).
BTW: Really impresing models.
BTW2: Why when I trun on the stadistisc say "Not real time" ??
I have to say one thing I don't like the gameplay in some vehicles like the connected bus, I see when I try to "climp" a mountain if the bus can reach the top slide and the collisions goes crazy, 4 fps with 3200 amd64...
When the vehicle upset i can't use reinitialize. you must put a key that put the car over the terrain.
It's really good concept but need to be optimized (everybody knows that).
BTW: Really impresing models.
BTW2: Why when I trun on the stadistisc say "Not real time" ??
Works:
MapToMesh | Bengine B9 @ www.sourceforge.net/projects/maptoogremesh/
3DWorldStudio exporter@ www.blastern.info
MapToMesh | Bengine B9 @ www.sourceforge.net/projects/maptoogremesh/
3DWorldStudio exporter@ www.blastern.info
- Game_Ender
- Ogre Magi
- Posts: 1269
- Joined: Wed May 25, 2005 2:31 am
- Location: Rockville, MD, USA
Very cool game/tech demo. I did manage to break the segmented bus, I don't know if that is a feature or a bug. I was trying to climb the mountain and bus started sliding, then slowly it folded into itself. The It kind of did a full twist and I heard a snap. After that Some of the beams were flying randomly around.
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Errm, it look like you breaked somethingGame_Ender wrote:Very cool game/tech demo. I did manage to break the segmented bus, I don't know if that is a feature or a bug. I was trying to climb the mountain and bus started sliding, then slowly it folded into itself. The It kind of did a full twist and I heard a snap. After that Some of the beams were flying randomly around.
Indeed, it's a feature. If you overload a beam, it snaps...
Rigs of Rods: http://rigsofrods.blogspot.com/
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Uh, it looks like the physics engine lost tracks. Maybe the AMDs are slower to run this code...BlasterN wrote: I have to say one thing I don't like the gameplay in some vehicles like the connected bus, I see when I try to "climp" a mountain if the bus can reach the top slide and the collisions goes crazy, 4 fps with 3200 amd64...
You have the 'I' key to reinitialize (sometimes it does not works if the simulation explodes). Plus you have on the blue Daf hydros to put the truck upright (F1, F2, F3, F4 keys). You can also use the crane on the yellow truck.BlasterN wrote: When the vehicle upset i can't use reinitialize. you must put a key that put the car over the terrain.
That means that the sim does not run above 20fps, so the time is slowed to enforce the 1/2000 integration step per seconds.BlasterN wrote:
BTW: Really impresing models.
BTW2: Why when I trun on the stadistisc say "Not real time" ??
In short that means that your CPU is too slow to run correctly the sim (and btw I'm scared to see this on a 3200 amd64 )
[/quote]
Rigs of Rods: http://rigsofrods.blogspot.com/
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Re: Preview of Rigs of Rods, an offroad truck simulator
Guess what...:wumpus: wrote:Good idea.I will check Leapfrog Verlet (which seems also easiest to implement than RK)...
I was already on a kind of leapfrog Verlet. The same kind as the "Semi-Implicit Euler" Lioric told about.
I gooffed the Euler equations (integrated v+1 instead of v to compute p) and was on a leapfrog, that is indeed more stable.
The bad news is that I think I already use the fastest integrator in town...
Rigs of Rods: http://rigsofrods.blogspot.com/
- pricorde
- Greenskin
- Posts: 114
- Joined: Thu Aug 11, 2005 9:28 pm
- Location: France
- Contact:
Update: a new version (0.12) is on the web site.
The main new features are:
-Collisions with some buildings (it was easiest than I thought, the soft-body engine makes collisions easy: if a node is inside collision box, nullify normal velocity, move node to the nearest point out of the box, and that's it! The rest of the chassis frame absorbs the shock!)
-Texture shadows. They look a little blocky, and there are some artefacts, but this is better than nothing. I have some difficulties to get stencil shadows right for my soft bodies. I will post to the Help forum about that.
The main new features are:
-Collisions with some buildings (it was easiest than I thought, the soft-body engine makes collisions easy: if a node is inside collision box, nullify normal velocity, move node to the nearest point out of the box, and that's it! The rest of the chassis frame absorbs the shock!)
-Texture shadows. They look a little blocky, and there are some artefacts, but this is better than nothing. I have some difficulties to get stencil shadows right for my soft bodies. I will post to the Help forum about that.
Rigs of Rods: http://rigsofrods.blogspot.com/
- :wumpus:
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Another interesting thing to persue might be adaptive timestep integration with the so-called "Courant condition". When forces and velocities are low for a body or group of bodies, a high timestep is good enough. As soon as things start to be active you have to switch to lower steps for them.Lioric wrote: what is interesting is this Semi-Implicit Euler, i have to try it sometime on some project, it claims to have better stability than euler
Complex to implement, and even harder to get stable though. I'd exhaust other possibilities first like finding simpler/more stable force expressions.