ideas to simulate car
Author
I''d like to know how car racing games calculate cars'' movements. I''v tried two different ways.
1: Exactly move the car along circle''s arc. the circle is calculated by steering angle. This makes the car move exactly ideal line. This seems to make sense for arcade games.
2: I have realistic physic parameters for the car. Then I only apply impulses for different events. gravity down, tyres up, tyres forwards and backwards (accel/brake), tyressideways (to prevent sliding). This makes sense for simulations games.
If anyone has worked with this problem it''d be nice to hear about your solutions. Of course the solution is always unique and combination of compromises (atleast for me, I''m not physicist).
I like the second solution, there is just one problem. The car is very restles. Car has alway a little noise when not moving. Also bumpy polygoned ground makes a problem, when traction changes gradually.
I do all calculations in static time steps. What is commonly used frequency. 100 times per second?
here''s a cool tutorial series called Physics of Racing
http://www.miata.net/sport/Physics/
there''s a $100 book named "Motor Vehicle Dynamics : Modeling and Simulation", which I''ve never been able to find a review of, but sounds very interesting. a couple others I ran across while searching are "Theory of Ground Vehicles", "Fundamentals of Vehicle Dynamics", and "Race Car Vehicle Dynamics". I''d love to read some of these, but it''s not practical to plunk $100 a pop on books I may never use. good luck
http://www.miata.net/sport/Physics/
there''s a $100 book named "Motor Vehicle Dynamics : Modeling and Simulation", which I''ve never been able to find a review of, but sounds very interesting. a couple others I ran across while searching are "Theory of Ground Vehicles", "Fundamentals of Vehicle Dynamics", and "Race Car Vehicle Dynamics". I''d love to read some of these, but it''s not practical to plunk $100 a pop on books I may never use. good luck
Automobile simulation is very tricky. Bobtree''s book and website suggestions are good references. Look in libraries first so you don''t shell out $100!
In your experiments with method #2, you have what sounds like a really good start, but you''ve discovered some of the tricks of numerical physics. You will need to add numerical damping into the system to get rid of the restlessness/noise (or "jitter"). The damping would be something like a viscous damping force, which is a force that is a function of velocity and applied in the opposite direction of motion. You may have viscous damping for each tire and for the breaks---with a different damping force computed in each direction of motion for the tires. The damping would be adjusted so it just gets rid of the undesirable effects. Do a web search and you should find some discussion of viscous damping.
As for bumpy terrain, why not have a separate, smoother version of the terrain with fewer polygons that you use especially for the driving simulation? The car may not conform exactly to your visualization terrain, but it may be good enough, depending on the camera angle (e.g., if you''re not looking at the car at ground level, you might not be able to see that the car is slightly above the displayed terrain).
The issue of time steps is also a complicated one. I would suggest that for now you just pick a time step that is close to your average frame rate. You may want to use something different for debugging.
Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.
In your experiments with method #2, you have what sounds like a really good start, but you''ve discovered some of the tricks of numerical physics. You will need to add numerical damping into the system to get rid of the restlessness/noise (or "jitter"). The damping would be something like a viscous damping force, which is a force that is a function of velocity and applied in the opposite direction of motion. You may have viscous damping for each tire and for the breaks---with a different damping force computed in each direction of motion for the tires. The damping would be adjusted so it just gets rid of the undesirable effects. Do a web search and you should find some discussion of viscous damping.
As for bumpy terrain, why not have a separate, smoother version of the terrain with fewer polygons that you use especially for the driving simulation? The car may not conform exactly to your visualization terrain, but it may be good enough, depending on the camera angle (e.g., if you''re not looking at the car at ground level, you might not be able to see that the car is slightly above the displayed terrain).
The issue of time steps is also a complicated one. I would suggest that for now you just pick a time step that is close to your average frame rate. You may want to use something different for debugging.
Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.
> As for bumpy terrain, why not have a separate, smoother
> version of the terrain with fewer polygons that you use
> especially for the driving simulation?
This makes sense but I think it''s the wrong way round: if anything the world is more undulating than most graphics engines/harware can render it. I.e. it''s worth looking at maintaing seperate data for the rendering and driving surface, but for an at all accurate simulation the latter may well be the more detailed.
> The issue of time steps is also a complicated one. I would
> suggest that for now you just pick a time step that is close
> to your average frame rate. You may want to use something
> different for debugging.
Better is a completely variable timebase. If you implement this from the start you will not fall into the trap of making your code dependant on a fixed timebase, which can be very difficult to debug and fix later. E.g subtle differences between playability between PAL and NTSC systems.
If during testing you vary it over a very wide range, you will quickly spot any problems introduced by a dependence on a fixed frame rate. Then to decide on the best fixed frame rate you can try running the simulation with various timebases choosing the lowest one that gives you a stable simulation.
> version of the terrain with fewer polygons that you use
> especially for the driving simulation?
This makes sense but I think it''s the wrong way round: if anything the world is more undulating than most graphics engines/harware can render it. I.e. it''s worth looking at maintaing seperate data for the rendering and driving surface, but for an at all accurate simulation the latter may well be the more detailed.
> The issue of time steps is also a complicated one. I would
> suggest that for now you just pick a time step that is close
> to your average frame rate. You may want to use something
> different for debugging.
Better is a completely variable timebase. If you implement this from the start you will not fall into the trap of making your code dependant on a fixed timebase, which can be very difficult to debug and fix later. E.g subtle differences between playability between PAL and NTSC systems.
If during testing you vary it over a very wide range, you will quickly spot any problems introduced by a dependence on a fixed frame rate. Then to decide on the best fixed frame rate you can try running the simulation with various timebases choosing the lowest one that gives you a stable simulation.
Author
By the way, where is car''s centre of gravity. I have it currently set in the middle of car (all tyres are same distance from CG). The car seems to be understeering. Is the CG normally more in front side of the car?
Net Racing Demo:
http://www.geocities.com/stefankjb/download.html
Net Racing Demo:
http://www.geocities.com/stefankjb/download.html
quote:Original post by johnb
> As for bumpy terrain, why not have a separate, smoother
> version of the terrain with fewer polygons that you use
> especially for the driving simulation?
This makes sense but I think it''s the wrong way round: if anything the world is more undulating than most graphics engines/harware can render it. I.e. it''s worth looking at maintaing seperate data for the rendering and driving surface, but for an at all accurate simulation the latter may well be the more detailed.
We maintain separate locomotion terrains for our game, and they are quite a bit less detailed than the display terrains. The benefit of having less detail is that queries can be done damned fast. The game is a third person game with the characters mainly walking. Not the same as a rolling vehicle, and for this game our locomotion terrains actually works very well. In fact our characters do separate from the display terrain somewhat, but it is not enough to notice usually. We have some very strange terrain, with overhangs and things, and it is not straightforward to simplify the display terrain. Probably the best solution will be different for every game.
quote:Original post by johnb
> The issue of time steps is also a complicated one. I would
> suggest that for now you just pick a time step that is close
> to your average frame rate. You may want to use something
> different for debugging.
Better is a completely variable timebase. If you implement this from the start you will not fall into the trap of making your code dependant on a fixed timebase, which can be very difficult to debug and fix later. E.g subtle differences between playability between PAL and NTSC systems.
Yes, you''re absolutely correct in saying the code should support a variable timebase. At least for moving between systems. Its not necessarily good to vary the simulation time step from frame to frame on a given system, since some games may require that simulations be repeatable, and repeatability suggests the use of fixed time steps, at least on a specific hardware platform.
quote:Original post by johnb
If during testing you vary it over a very wide range, you will quickly spot any problems introduced by a dependence on a fixed frame rate. Then to decide on the best fixed frame rate you can try running the simulation with various timebases choosing the lowest one that gives you a stable simulation.
I agree with this approach. While only one of many, it is a straightforward way to develop a simulation that will work on different systems.
Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement