Hows this for Dead Reckoning

Discussion about everything. New games, 3d math, development tips...
Post Reply
JPulham
Posts: 320
Joined: Sat Nov 19, 2005 12:06 pm

Hows this for Dead Reckoning

Post by JPulham »

To those who care or know what they're talking about:
I have made a Dead reckoning scene node animator (simple). How does this check out:

Code: Select all

void CSceneNodeAnimatorDeadReckoning::animateNode(ISceneNode* node, u32 timeMs)
{
    core::vector3df oldPos;
    core::vector3df nodePos;
    core::vector3df newPos;
    f32 timeDiff = timeMs - LastTime;
    
    
    //update actual pos with our actual vel...
    oldPos = targetPos;
    targetPos = targetPos + ((targetVel / 1000) * timeDiff);
    nodePos = node->getPosition();
    
    //... if the node has not converged on the target
    if(oldPos != nodePos)
    {
        //...then interpolate between the node and the target at the speed 'SnapVel' ...
        newPos = nodePos.getInterpolated(targetPos,SnapVel * timeDiff);
    else
    {
        // ... otherwise just update position to target position.
        newPos = targetPos;
    }
    
    node->setPosition(newPos);
    
    
    //finaly update LastTime
    LastTime = timeMs;
}

I'll probably post the full code in code snippets once I know it works.

EDIT : targetPos and targetVel are user settable through a setter function
pushpork
bitplane
Admin
Posts: 3204
Joined: Mon Mar 28, 2005 3:45 am
Location: England
Contact:

Post by bitplane »

i typed a mammoth post on this subject before sourceforge's web went down, and lost my copy buffer while reporting the problem.. so i guess i'll type it all over again :(

1) you need a fixed time-step, or you'll need lots of calculus to work out the current position when things like rotation, thrust, velocity and air resistance are brought into the equation. in an ideal world, you're only passing changes like button states back to the clients.

2) using your method, rounding errors accumulate over time. say a frame takes 1.49ms (i'm not sure which way it rounds) on one machine, but another frame takes 5ms. you need to calculate the new position from on the last known real position (said by server), or the position at the last time-step.

3) the server may be sending events for things which happened in the past, so you need to smoothly blend between your old estimated position and your new best guess. this is bound to play havoc with your collision detection (i havent thought much about this)

erm i think that was everything, but i might have missed something.
edit: I do care, but I still might not know what I'm talking about having never actually put this into practice :lol:
Submit bugs/patches to the tracker!
Need help right now? Visit the chat room
Post Reply