CODEWITHSUNDEEP
javaandroidgarbage-collectionphysics
IvanArellano
IvanArellano

Reputation: 45

How to avoid undesired additional velocity from time step change with Verlet integrator

I know the title is an eyebrow raiser but it's mostly a side effect problem. I'm writing an Android app that I can use with the math I've been learning in my physics class. It's a 2D bouncing ball app. I'm using the time corrected Verlet integrator with an impulse on the floor which is the bottom of the screen. I'm adding friction and bounciness so that the ball eventually reaches 0 velocity.

The problem shows up when the ball is resting on the floor and a "significant" time step change happens. The integrator adjusts the velocities flawlessly and ends up firing the impulse on the floor. The impulse fires when the velocity's abs value is greater than 2.5. Android's GC usually causes a time adjusted -18 velocity.

Any help is appreciated. I realize the code structure could be better but I'm just trying to visualize and apply physics for fun. Thank you.

// The loop
public void run() {
    if(mRenderables != null) {
        final long time = SystemClock.uptimeMillis();
       final long timeDelta = time - mLastTime;

        if(mLastTime != 0) {
            final float timeDeltaSeconds = timeDelta / 1000.0f; 

            if(mLastTimeDeltaSec != 0) {                    
                for(short i = 0; i < mRendLength; i++) {
                    Ball b1 = mRenderables[i];

                    // Acceleration is gauged by screen's tilt angle
                    final float gravityX = -mSV.mSensorX * b1.MASS;
                    final float gravityY = -mSV.mSensorY * b1.MASS;

                    computeVerletMethod(b1, gravityX, gravityY, timeDeltaSeconds, mLastTimeDeltaSec);
                }
            }

            mLastTimeDeltaSec = timeDeltaSeconds;
        }

        mLastTime = time;
    }
}

/*
* Time-Corrected Verlet Integration
* xi+1 = xi + (xi - xi-1) * (dti / dti-1) + a * dti * dti
*/  
public void computeVerletMethod(Renderable obj, float gravityX, float gravityY, float dt, float lDT) {
    mTmp.x = obj.pos.x;
    mTmp.y = obj.pos.y;

    obj.vel.x = obj.pos.x - obj.oldPos.x;
    obj.vel.y = obj.pos.y - obj.oldPos.y;
    // Log "1." here        

    resolveScreenCollision(obj);

    obj.pos.x += obj.FRICTION * (dt / lDT) * obj.vel.x + gravityX * (dt * dt);
    obj.pos.y += obj.FRICTION * (dt / lDT) * obj.vel.y + gravityY * (dt * dt);

    obj.oldPos.x = mTmp.x;
    obj.oldPos.y = mTmp.y;
    // Log "2." here
}

// Screen edge detection and resolver
public void resolveScreenCollision(Renderable obj) {
   final short xmax = (short) (mSV.mViewWidth - obj.width);
   final short ymax = (short) (mSV.mViewHeight - obj.height);
   final float x = obj.pos.x;
   final float y = obj.pos.y;

   // Only testing bottom of screen for now     
   if (y > ymax) {
    // ...
    } else if (y < 0.5f) {
        if(Math.abs(obj.vel.y) > 2.5f) {
            float imp = (obj.MASS * (obj.vel.y * obj.vel.y) / 2) * obj.RESTITUTION / obj.MASS;
            obj.vel.y += imp;
           // Log "bounce" here
        } else {
            obj.vel.y = obj.pos.y = obj.oldPos.y = mTmp.y = 0.0f;
        }
    }
}

Output while ball is resting on the floor and sudden impulse happens (see code for "log" comments)

1.  vel.y: -0.48258796
2.  pos.y: -0.42748278 /oldpos.y: 0.0 /dt: 0.016 /ldt: 0.017

1.  vel.y: -0.42748278
dalvikvm  GC_FOR_MALLOC freed 8536 objects / 585272 byte s in 74ms
2.  pos.y: -0.48258796 /oldpos.y: 0.0 /dt: 0.017 /ldt: 0.016

1.  vel.y: -0.48258796
2.  pos.y: -18.061148 /oldpos.y: 0.0 /dt: 0.104 /ldt: 0.017

1.  vel.y: -18.061148
bounce  imp: 124.35645
2.  pos.y: 13.805508 /oldpos.y: -18.061148 /dt: 0.015 /ldt: 0.104

Upvotes: 2

Views: 1276

Answers (2)

Stas Jaro
Stas Jaro

Reputation: 4885

you shouldn't use a timestep based on how much time occured from the previous calculation because that can cause problems such as this and errors in collision detection, if you don't have that yet. Instead for every update, you should set a "time chunk" or a max amount of time for each update. For example: say you want 30fps and the which is in nanotime about 33333333. so 33333333 = 1 timechunk. so then you could do a while loop

long difftime = System.nanoTime() - lastTime;
static long fpstn = 1000000000 / 30;
static int maxtimes = 10;// This is used to prevent what is commonly known as the spiral of death: the calcutaions are longer that the time you give them. in this case you have to increase the value of a base timechunk in your calculations
for (int i = 0; i < maxtimes; i++) {
    if (difftime >= fpstn) {
        world.updateVerlet(1);
    } else {
        world.updateVerlet((float)diffTime / (float)fpstn);
    }
    difftime -= fpstn;
    if (difftime <= 0)
        break;
}

Upvotes: 1

Beta
Beta

Reputation: 99134

It's hard to be sure, but it looks as if the problem isn't the increase in the time step, it's the large time step. You do Verlet integration and bouncing as separate processes, so if the ball start from a resting position on the floor with a large time step, it falls far into the floor, picking up speed, before being reflected into the air. Keep the time step small and you won't have this problem... much.

Upvotes: 0

Related Questions