Game Physics Coding Question...

remiremi remedy [blu.knight] Join Date: 2003-11-18 Member: 23112Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester
edited September 2009 in Off-Topic
After recently realizing that this forum's demographic includes a lot of programmers, I thought I would post a question I have...

I am trying to figure out how to simulate friction in a frame-rate independent way, and also in a way that it can be predicted so I can do dead-reckoning / convergence using the predicted position.

Right now, I just do...
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Velocity *= FRICTION_FORCE;<!--c2--></div><!--ec2-->
...except that's not frame rate independent.

My current solution is to use a specific frame rate for my physics (so it is guaranteed to run once for every 0.1 seconds), and then for the prediction I do...
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->float N = (1 / Player.PHYSICS_RATE);
float APY = (float)Math.Pow(1.0f + Player.FRICTION / N, N) - 1.0f;
LookAheadPoint = packet.Position + APY * (packet.Velocity + packet.Acceleration * LOOK_AHEAD_TIME) * LOOK_AHEAD_TIME;<!--c2--></div><!--ec2-->
...using the Annual Percentage Yield formula to try to predict it...


So does anyone know a better way to simulate friction in a frame rate independent way? This way feels like a hack. :P

Comments

  • ScytheScythe Join Date: 2002-01-25 Member: 46NS1 Playtester, Forum Moderators, Constellation, Reinforced - Silver
    That's not actually that bad a way of doing things, but I'd adjust my friction coefficients so they're pre-adjusted for my physics frame rate. Initialising floats every frame isn't great for your memory performance.

    --Scythe--
  • PaladinDudePaladinDude Join Date: 2006-12-04 Member: 58881Members, Constellation
    <!--quoteo(post=1729542:date=Sep 29 2009, 07:25 AM:name=Scythe)--><div class='quotetop'>QUOTE (Scythe @ Sep 29 2009, 07:25 AM) <a href="index.php?act=findpost&pid=1729542"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->That's not actually that bad a way of doing things, but I'd adjust my friction coefficients so they're pre-adjusted for my physics frame rate. Initialising floats every frame isn't great for your memory performance.

    --Scythe--<!--QuoteEnd--></div><!--QuoteEEnd-->
    Better still, pack your floats into long ints and divide by whatever precision you want at the end to get the number you need. VERY fast (although you do lose some precision) but if speed is everything then this works very well.
  • ScytheScythe Join Date: 2002-01-25 Member: 46NS1 Playtester, Forum Moderators, Constellation, Reinforced - Silver
    <!--quoteo(post=1729555:date=Sep 29 2009, 08:09 PM:name=PaladinDude)--><div class='quotetop'>QUOTE (PaladinDude @ Sep 29 2009, 08:09 PM) <a href="index.php?act=findpost&pid=1729555"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Better still, pack your floats into long ints and divide by whatever precision you want at the end to get the number you need. VERY fast (although you do lose some precision) but if speed is everything then this works very well.<!--QuoteEnd--></div><!--QuoteEEnd-->

    Rounding errors in collision code are very bad. Generally causes stuff to clip together, or fall through things.

    --Scythe--
  • RobRob Unknown Enemy Join Date: 2002-01-24 Member: 25Members, NS1 Playtester
    <!--quoteo(post=1729559:date=Sep 29 2009, 06:36 AM:name=Scythe)--><div class='quotetop'>QUOTE (Scythe @ Sep 29 2009, 06:36 AM) <a href="index.php?act=findpost&pid=1729559"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Rounding errors in collision code are very bad. Generally causes stuff to clip together, or fall through things.

    --Scythe--<!--QuoteEnd--></div><!--QuoteEEnd-->

    What you really need to watch out for is making approximations of approximations, that usually causes things to spiral out of control pretty quickly. Always keep a "ground truth" set of numbers somewhere. Like an objects position is always a translation, rotation, and scaling from the origin, never one of those operations from it's previous position.

    What some do with physics these days is make it as time based as possible with a global timer and a physics time step like you have already. Given initial conditions and a time delta, it's possible to calculate the position and velocity of an object. Out side of some dead reckoning like you want to do, you might miss a collision between time steps, though.

    It seems like you're treating friction like an acceleration which probably isn't a bad abstraction. What you might be able to do is take the number and raise it to the power of the number of seconds between the last time you checked to get the current velocity due to friction. Say you start with 10 m/s at t = 0 with 0.5 m/s^2 of friction. At time t = 3, you can multiply 10 * (0.5^3) to get 1.25 m/s at that time.
Sign In or Register to comment.