"backwards" physics engine

0
votes

I need to apply game physics in a way that's "backwards".

Even a clarification in terminology would be helpful.

Problem

Given a body's mass, maximum velocity, maximum force, and a set motion path (2d for now), I want to determine the forces needed to make the body follow the path while minimizing time.

To put it another way, an object's pathfinding is complete, now I want to apply inertia.

Ideas

both require sampling

  1. Use a physics engine to control a dynamic body's motion, applying impulses to move along the path. Any time the body strays too far from the path, back up and begin slowing the body.

  2. Use a physics engine to control a kinematic body attached via spring to a dynamic body. The kinematic body moves steadily along the path, until the dynamic body stretches the spring too far... again: back up and slow down.

Am I missing some common approach that I just haven't discovered? This is a little bit like inverse kinematics, but solving for different variables.

1
physicsgame-physics
Thanks for a very good question! As I understand it this is really in the core of what is the root meaning of "rocket science", formally known as "control theory". I studied it long time ago and I vaguely remember sub-problems such as "reachability" - can the path be reached at all; "controlability", could we reach it with sensors and forces available; and of course also the question of optimal control, how to use as litte enegery as possible to obtain the goal. I guess anyone inside this field should be able to answer your question. - Mats Lind
Is the path defined as a sequence of points, or a continuously defined curve? - Beta
@Beta, it's either. The path starts life as a sequence of points but I fit it to a continuous sequence of cubic bezier curves. I have a function that gives me position at %path, but y is not a function of x. - Greg M.

1 Answers

1
votes

I know this as "motion planning", and it's not trivial.

I'd probably try one (or both) of these approaches:

Evolutionary. I'd start with a trajectory (x(t), y(t)) in which the body comes to a full stop at each point in the sequence, or at each juncture of cubic curves; that's easy to calculate. Then I'd allow small random variations in thrust, selecting on adherence to the flight math and minimal total time, evolving until the total time leveled off.

Piecewise. For each cubic curve, calculate the range of starting velocities the body can have, and still stay close enough to the curve. Then let neighboring segments cinch up constraints on the handoff velocities, each segment seeking to minimise its own time.