Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


Member Since 03 Jan 2000
Offline Last Active May 01 2014 12:59 AM

Topics I've Started

Racing AI (with complications)

13 October 2005 - 10:03 AM

Having read through some of the other racing AI threads on these forums, I've noticed that most of them involve creating an AI that follows a developer-specified optimal racing line. But my tracks are hideously loopy: My Journal, for Screenshots. I really would rather not have to manually create a racing line for each track. Mostly because I don't even know that I could FIND an ideal sort of racing line. Heck, I'm not even sure that, as bad as I actually am at racing games (don't let the fact that I'm writing one fool you), I could even DRIVE a fairly optimal line. And another wrinkle: In addition to the steering and the accelerator (which includes the brakes), there's also a "slide" button, which turns off the motion dampening in the car's sideways movement (i.e. holding "slide" allows the car to continue moving in the direction it's going, even if the car turns). I'd like the AI to be able to use that feature, though I won't be terribly heartbroken if it can't. Is there any other sort of way to generate a near-optimal racing line? Or to make an AI that can use other attributes of the track to drive such a track? Suggestions? I'm new to this whole AI business, so it could be (And is even likely) that I'm missing something horrendously obvious. Please feel free to point it out. Thanks much, Josh

Help creating arcade racing simulator

28 February 2005 - 07:55 AM

Okay, so despite my best efforts, I seem completely incapable of coding a simple driving simulation. It doesn't have to be super physically accurate, but it has to feel correct. I've read the Physics of Racing articles (which are, sadly, slightly over my head...way too detailed for what I want). The trick is, the track has loops and whatnot. The cars stick to the track (magnetics or whatever). Though I could probably extend a simulation to be able to handle that, if I could only get a flat-ground driving simulation running that doesn't blow. All I want is: 1. High-speed turn skidding to work mostly correctly 2. Ability to modify the friction of the road. 3. Wheels need to animate correctly (i.e. if the tires are slipping, they should animate slipping...if they're not, they should turn along with the road. 4. Slipping due to high acceleration (especially on ice and the like)...and brake locking. This may not sound hard to some of you, but I apparently really suck at physics programming. Can anyone give me some pointers?

Three-wheeled Vehicle Physics

24 January 2005 - 04:34 AM

I'm having trouble with my vehicle physics, and I'm having an insanely hard time finding any resources that have proven useful (For instance, the "Physics of Racing" series is almost too in-depth, and try as I might I've been unable to take the ideas in those papers and figure out how to apply them to my simulation). Here's what I'm trying to create: 1. Vehicles have three wheels, arranged as vertices on an isosceles triangle, one wheel in front, two in back. 2. The wheels are spheres (a stylistic choice, but it helps the collision detection as well) 3. The wheels need to spin at the correct speed. i.e. they match the speed of the ground when rolling, or they can lock up when braking or spin out when accelerating. 4. Front wheel is the drive wheel and steering wheel. There are brakes on all three wheels. 5. Friction between the wheels and the ground needs to be at least visually correct (i.e. not necessarily mathematically correct, but a good approximation that looks correct - I'm making an arcade-style racing game, not a hardcore simulation). I do plan on having different surface types (though not different "tire" types). 6. Tracks will be anything but perfectly flat. There will be many hills, banks, etc to navigate around. Okay, so I've tried quite a few methods to get this to work, and none of them have panned out (just so you know that I've actually TRIED things before asking this question on the forums): 1. First up, I tried to integrate ODE into my engine. Due to friction-related difficulties, this didn't work as well as I'd hoped. I decided I wanted more control over the code, which brings me to... 2. I implemented the ideas in Using Verlet Integration and Constraints in a Six Degree of Freedom Rigid Body Physics Simulation. This was unstable for some reason (without a large number of iterations, like 50-70), and due to the nature of solving one set of constraints before the others, the car would pull to the right (or to the left, depending on the order in which the back wheels were solved). I don't really want my cars to act like my old '88 Chevy, so I scrapped this. 3. I coded a different set of constraints, where I wrote an axis constraint and then used distance constraints. This worked better, but it was still very much unstable (regardless of the integration method that I used, and I tried a couple). 4. Decided not to treat the wheels as seperate objects and to then treat the car as one rigid body (mostly). I've been trying to do the calculations to determine what amounts of force are necessary to keep the wheels on the road. The problem is, each of these values relies on the values for the other two wheels, so if one wheel maxes out due to friction constraints and starts to slide, the other wheels' values change. This can be solved iteratively, but it's a pain, and I haven't finished solving the sets of equations anyway, and I'm SURE there's a better way. So what I'm asking, basically, is if anyone can please point me in the right direction with respect to how to get these three-wheeled vehicles to drive in a way that looks and feels correct. Any suggestions? Thank you, Josh

Friction vs. Torque

24 December 2004 - 05:43 PM

So I have a program where, ideally, I can roll a ball around by applying a torque around the axis. So I have two functions: EDIT: It should be noted that "^" is my cross-product operator.
void AddForce(const CEVector3 &f, const CEVector3 &point)
  m_forces += f;
  m_torques += (point - m_center) ^ f;
void AddTorque(const CEVector3 &axis, float amount)
  m_torques += axis * amount;
Adding torque about the axis (Through the center of mass, always) doesn't affect the linear force (consider it two forces on opposite ends of the sphere, pointing in opposite directions orthogonal to the axis of rotation) I currently assume an infinite coefficient of static friction (no slip. Ever.) So to get the amount of friction to apply, I need to know how much force is being applied tangentially to the surface:
CEVector3 GetForceAtPoint(const CEVector3 &pt)
  CEVector3 dir = pt-m_center;
  return m_forces + (m_torques ^ dir) / dir.LengthSquared();
So this gets the force at a given point on the ball (I'm doing points instead of radius because I'm going to generalize this for non-ball objects eventually). I can't remember the logic behind how I came to that little equation, but it seems to do the trick. So the friction pushes back on the ball in the opposite direction at that point. However, if I simply call:
AddForce(-GetForceAtPoint(pt), pt)
the ball moves the correct direction at the correct speed, but the addition of the force cancels out the rotation. Now, if I only apply the force to the linear force (it doesn't affect the torque, or it's not added to m_torques), then it works correctly. Either I have a concept wrong, or this friction really shouldn't affect the torque. Can anyone explain this to me? I'm immensely confused. [Edited by - Drilian on December 25, 2004 12:13:34 AM]

Trouble Designing A Bezier Terrain Editor's Interface

09 December 2004 - 07:17 PM

So I'm trying to make terrain out of cubic bezier patches, but I'm having trouble coming up with an easy-to-use interface for the editor (though the engine works just fine). So far, what I have basically allows me to select a patch and move individual control points around. Also, it can add patches on to the edges of an existing patch (via extrusion), and will maintain either C0, G1, or C1 continuity, depending on the selected option. But it's not enough. It's very unwieldy for the large types of terrain that I'm editing (read: that I would LIKE to be editing, were it not so difficult). Does anyone have any suggestions (maybe even from experience) as to what kinds of functionality I can implement to make the editing easier? Thanks much! Josh