• Content count

  • Joined

  • Last visited

Community Reputation

401 Neutral

About K_J_M

  • Rank
  1. Hi Acharis. I downloaded your game and gave it a whirl. And i really like this. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Everything ran smoothly and was really easy to pick up and play without instructions. The only thing i felt was lacking was the sound effects and possibly some music to help generate some more atmosphere. I contemplated writing something similar a while ago, more along the lines of the 'Ishar' games but instead decided against the step movement idea. But it works really well in your game. I can see this working really well on mobile devices. Might be worth considering porting it to mobiles when you've finished the PC version. The graphics have a real old school charm about them. Keep up the good work. KJM
  2. Car Simulation Headaches Part_#2

    Hi. For my Autocross Racing game i used lateral Pacejka coeficients similar to this curve. [img]http://www.trinosis.com/files/lateral_pacejka_curve.jpg[/img] This gives a very forgiving tire with a lot of grip at all slip angles. I noticed in your second video that your car reaches a maximum slip angle before it loses grip and spins around. This is classic of a Pacejka curve that peaks at a small slip angle. once past this peak, the tire has no grip and the car spins around. Altering your Pacejka curve so it looks similar to mine above should help prevent this and allow for drifting. You should be able to get variable car handling from using different curves. The Racer sim for instance uses different coefficients for front and rear tires. But specifically for my game, i just rotate the cars velocity vector by the lateral Pacejka force to give that arcade drifting feel. It's not physically accurate in any way and i did have to tune various attributes to get the correct feel i was after. In theory, a physically accurate sim should be able to produce a wide range of handling for a car from an arcade drift feel to a simulation mode, by altering such things as the Pacejka curves, engine power, gear ratio's ect. But in practice creating an accurate sim is going take a long time to do (particularly because theres very little information available on the subject), so it comes down to priorities. If your priorities are to get an arcade game written as quickly as possible then i see no reason in hacking together an arcade sim, which is exactly what i did for my game. If on the other hand you want to write a physically accurate sim and then use that as a basis for games, then it will take a long time to get right. You could use a third party car physics engine and i know some general purpose physics engines support wheel physics and suspension constraints (Newton physics engine for example) , so that may be an easier route for you.
  3. Car Simulation Headaches Part_#2

    " I would argue with that. In your post #6, the blue arrow IS the real velocity of the tyre, which is perpendicular to the vector from CG to wheel pos, but not to the wheel's heading. So it WILL generate both long/lat forces. If you do the same calculations for the remaining 3 wheels the sum of all Fx's will be zero if the CG is at the center of the car, so that's why there is no movement of the car body. " Thanks for the explanation Bmarci. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] I see there were flaws in my understanding. I was assuming that a stationary car spinning on the spot has zero linear velocities and as a result no slip angles could be generated. But in fact, you show that although the car chassis has no linear velocites, the wheels actually do and therefore the slip angles can be calculated whilst ignoring the angular velocity of the chassis. Sorry for any confusion pochypoch.
  4. Car Simulation Headaches Part_#2

    Thanks for the comments. Both Long and Lat Pacejka formulas need FZ (load) as one of the inputs. And a resulting force as output. The traction circle caps the forces to a maximum limit. I think the Racer sim reduces Longitude forces in favour of Lateral as a way to cap the forces. But there are several different methods that i've seen. Since the traction circle limits forces, and these are calculated from Pacejka which requires FZ (load) as an input, the traction circle caclulations are applied after the forces have been calculated.
  5. Car Simulation Headaches Part_#2

    Hi. The Pacejka formula's work in wheel local coordinates. Longtitude pointing in the direction the wheel rolls in and Lateral at 90 degrees to Longtitude direction. So,as i understand it, Case 1 Example is correct. Although i'm no expert, i always understood that a stationary car spinning on the spot with the steering centred produces no longtitude forces from the tires to move the car forwards or backwards. But only lateral forces to slow down the rate of spin. But, maybe someone with more detailed knowledge than me can give a more accurate explanation.
  6. Car Simulation Headaches Part_#2

    It seems to me you are looking at the issue with regards to world coordinates. If you look at the issue with regards to local car coordinates then each wheel has 0 longtitude velocity and (N) Lateral velocity if the car is spinning on the spot. Marco Monsters car physics tutorial performs the world to local coordinates transform by rotating the linear world velocities by the yaw angle of the car / wheel. s = Sin(yaw_angle) c = Cos(yaw_angle) local_lateral_velocity = (world_x_velocity * c) + (world_z_velocity * s) local_longitude_velocity = (world_x_velocity * -s) + (world_z_velocity * c) And to transform back from local to world coordinates. ( Note the sign for the sine command is reversed, which reverses the direction of rotation ) world_x_linear_velocity = (local_lateral_velocity * c) + (local_longitude_velocity * -s) world_z_linear_velocity = (local_lateral_velocity *s) + (local_longitude_velocity * c) But in regards to a stationary car spinning on it's axis the lateral wheel velocity is derived from the car angular velocity.
  7. Car Simulation Headaches Part_#2

    Hello PochyPoch. I havn't read all of your post but a quick glance brought me to question 4. To clarify Part 4. If the car is stationary and spining on it's axis, and the front wheels arn't turned to any steering angle (yaw) but pointing in the direction the chassis points, then each wheel generates +- 90 degrees slip angle. The wheels only have lateral movement. ie they are only sliding sideways as the car spins. The sign of the slip angle depends on whether the car is spinning clockwise or anti clockwise. My statement about not generating slip angles was because the car is stationary and no slip angles are generated from the code that uses linear velocities of the car chassis to determine the slip angles. My basic method was using 1 wheel (chassis) to determine the slip angles and Bmarci was using 4 wheels. Slip angles are generated by the difference between the longitude and lateral velocities of the tire. The confusion comes from the fact that i was using the car chassis to determine the slip angle and not for each tire. So when writing your sim, you need to take into consideration the angular velocity of the car and the slip angle that generates for each wheel and the linear velocities of the wheel (chassis , since the wheel is attached to the chassis). The car can be moving with no angular velocity (moving forwards or sliding sideways), stationary but spinning on it's axis or any combination of the two. And both situations need to be considered to determine your actual slip angle for each wheel. The steering angle of the front wheels also needs to be taken into consideration for the front wheels slip angle. Hope thats clearer. And best of luck with your game. I too have made a top down racer. [url="http://www.trinosis.com/"]http://www.trinosis.com/[/url]
  8. Vehicle simulation headache

    Hey, thats great. Congrats on getting it working. Glad i could help. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  9. Vehicle simulation headache

    Ok, from what you've written then, it seems the problem might lie with the forces acting against the wheels from the angular velocity of the car. If we assume your car is stationary and points at 12 o clock with the front wheels centred, but is spinning on it's axis (yaw) then the wheels generate 0 slip angle because there is no long or lat linear velocities of the car. But there will be friction against the wheels as the car spins, acting in the opposite direction to the movement of the wheel. I ended up just using a constant friction value applied to the angular velocity of the car at each update. I don't think the force acting against the wheels changes much if at all but i wasn't able to find a definitve answer to this question and so just ended up using a constant friction force. You could use Pacejka to return a force with a slip angle of 90 degrees ( 1/2 * Pi Radians ) for all wheels to slow down the angular velocity of the car or apply a constant as i do. Using Pacejka seperately for the front and rear wheels makes sense because if the front wheels are turned you can call Pacejka with a different slip angle. For the front wheels pointing straight ahead the slip angle would be 90 degrees as the car spins, and if turned 90 degrees the slip angle would be 0.
  10. Vehicle simulation headache

    I get slightly different slip angles in my demo. 12..3 -> slip 0 to -90 degrees 3..6 -> slip +90 to 0 6..9 -> slip 0 to -90 9..12 -> slip 90 to 0 The important thing is that your 12 - 3 and 9 - 12 slip angles have different signs for going forwards and 3 - 6 and 6 - 9 have different signs for going backwards. So, Lateral Pacejka will return the correct signed force for skidding left and right. I have different signs when the car spins past 90 degrees and starts going backwards. But i wouldnt worry about that until you get it working correctly going forwards. Just to state the obvious, you are working in Degrees and not Radians, and not getting them confused ? I would still reduce your code further to simulate what i do in my demo, with one wheel. Since your still having problems. Once thats working as it should, then implement 2 wheels and when that works go to 4. Also make the load and camber on the wheels constant, at this stage to simplyfy things as much as possible. Could you upload a demo, so i could get a look at what's actually happening. Or a short video perhaps. I don't understand these two lines Fx=slip_ratio*0.25*Fz Fy=slip_angle*0.1*Fz To cap the forces to a traction circle / elipse you just normalise each and then multiply by a maximum length, if they exceed a maximum force. You treat both as a 2d direction vector. Also remember that Fz is used in the Pacejka equations. So i don't know why you're using it in those two lines. Just remove those two lines from your code and see what happens. Pacejka expects slip angles from -90 to +90, load (Fz) and camber as inputs and outputs FY as force.
  11. Line To Catmull Rom Intersection

    Hi Catmull Dog. Yes, i totally agree with you. Theres nothing worse than having to re invent the wheel. I'm really suprised i havn't been able to find an already established algorithm for solving this problem. But if i find one, i'll definately share it with the community.
  12. Vehicle simulation headache

    Hi. "I plotted my pacejka curves and they seem to be good. I implemented Brian Bechman's version and compared to the Racer's source they produce very similar results." Yes, i've had a look at Brian Beckmans Physics Of Racing Series too. His alternate Pacejka curve formula produces similar curves to Pacejka, but they don't take into account load and camber if i remember correctly. Which are essential for a realistic sim, for load transfer when cornering for instance. As the loads on the tires change. That /400 seems to be an "ugly" hack Yes, i ddn't use real world values in the demo. Theres no calculations using Newtons for force ect. It's just a basic implementation to get the basic sim working. Your Torque theory sounds right to me. Here's a paragraph from my "Physics For Game Developers" book on Torque. "Force is what causes linear acceleration, while torque is that which causes rotational acceleration. Torque is force times distance. Specifically, to calculate the torque applied by a force acting on an object, you need to calculate the perpendicular distance from the axis of rotation to the line of action of the force and then multiply this distance by the magnitude of the force. This calculation gives the magnitude of the torque. "
  13. Vehicle simulation headache

    Hi. I'm affraid i don't have a solution for you, but since no one yet has replied to you, i thought i'd share my experiences. I recognise some of Marco Monsters formula's in your code. I remember implementing his tutorial some years ago and found that his algorithms produced a very unstable and jittery car, especially at low speeds. I would reccomend stripping back your code to treat the car body as one wheel and get that moving and turning correctly. Then add in your longitude and engine calculations. There is also the issue of the traction circle / elipse. Which constrains the longitude and lateral forces so they don't exceed their specified limits. I'm not sure if this is an issue for you or not. I have a simplified Lateral Pacejka demo i could upload for you to have a look at, including the source. This treats the car as 1 wheel and might help you to see where your problem lies. Windows Demo here. 1.5mb [url="http://www.trinosis.com/files/lateral_pacejka_car_physics_demo.zip"]http://www.trinosis.com/files/lateral_pacejka_car_physics_demo.zip[/url]
  14. Line To Catmull Rom Intersection

    For anyone thats interested i've created a small demo with source code demonstrating the intersection method described in my third post here. 655k. Windows only. [url="http://www.trinosis.com/files/line_to_catmul_rom_spline_intersection_demo.zip"]http://www.trinosis.com/files/line_to_catmul_rom_spline_intersection_demo.zip[/url]
  15. Line To Catmull Rom Intersection

    Heres what i have so far. The code might serve to help others. But it's not working correctly and the root returned isn't correct. The terms a0,a1,a2,a3, b0,b1,b2,b3 are what i've found from google searches, i think they are correct for a Catmull Rom spline, but i'm not sure. \\ Spline Control Points \\ p0x# \\ p0y# \\ p1x# \\ p1y# \\ p2x# \\ p2y# \\ p3x# \\ p3y# t# = 0.5 spline_x_pos# = 0.5 * ((2 * p1x#) + (p2x# - p0x#) * t# + (2 * p0x# - 5 * p1x# + 4 * p2x# - p3x#) * t# * t# + (3 * p1x# + p3x# - p0x# - 3 * p2x#) * t# * t# * t#) spline_y_pos# = 0.5 * ((2 * p1y#) + (p2y# - p0y#) * t# + (2 * p0y# - 5 * p1y# + 4 * p2y# - p3y#) * t# * t# + (3 * p1y# + p3y# - p0y# - 3 * p2y#) * t# * t# * t#) A# = (line_point_1_y# - line_point_2_y#) * spline_x_pos# B# = (line_point_2_x# - line_point_1_x#) * spline_y_pos# a0# = -0.5 * p0x# + 1.5 * p1x# - 1.5 * p2x# + 0.5 * p3x# a1# = p0x# - 2.5 * p1x# + 2 * p2x# - 0.5 * p3x# a2# = -0.5 * p0x# + 0.5 * p2x# a3# = p1x# b0# = -0.5 * p0y# + 1.5 * p1y# - 1.5 * p2y# + 0.5 * p3y# b1# = p0y# - 2.5 * p1y# + 2 * p2y# - 0.5 * p3y# b2# = -0.5 * p0y# + 0.5 * p2y# b3# = p1y# c0# = (A# * a0#) + (B# * b0#) c1# = (A# * a1#) + (B# * b1#) c2# = (A# * a2#) + (B# * b2#) c3# = (A# * a3#) + (B# * b3#) root# = ((c3# * t#) ^ 3) + ((c2# * t#) ^ 2) + (c1# * t#) + c0# And heres my previous code which does return a correct root. t# = 0.5 spline_x_pos# = 0.5 * ((2 * p1x#) + (p2x# - p0x#) * t# + (2 * p0x# - 5 * p1x# + 4 * p2x# - p3x#) * t# * t# + (3 * p1x# + p3x# - p0x# - 3 * p2x#) * t# * t# * t#) spline_y_pos# = 0.5 * ((2 * p1y#) + (p2y# - p0y#) * t# + (2 * p0y# - 5 * p1y# + 4 * p2y# - p3y#) * t# * t# + (3 * p1y# + p3y# - p0y# - 3 * p2y#) * t# * t# * t#) temp_1# = (line_point_1_y# - line_point_2_y#) * spline_x_pos# temp_2# = (line_point_2_x# - line_point_1_x#) * spline_y_pos# temp_3# = ((line_point_1_x# * line_point_2_y#) - (line_point_2_x# * line_point_1_y#)) root# = temp_1# + temp_2# + temp_3#