Как избежать нежелательной дополнительной скорости от изменения временного шага с помощью интегратора Verlet - PullRequest
2 голосов
/ 06 февраля 2011

Я знаю, что это название для бровей, но это в основном проблема с побочными эффектами.Я пишу приложение для Android, которое я могу использовать с математикой, которую я изучал на уроке физики.Это 2D приложение для прыгающего мяча.Я использую интегрированный по времени интегратор Verlet с импульсом на полу, который находится внизу экрана.Я добавляю трение и упругость, чтобы мяч в конце концов достиг скорости 0.

Проблема проявляется, когда мяч лежит на полу и происходит «значительное» изменение шага по времени.Интегратор безупречно регулирует скорости и в конечном итоге запускает импульс на полу.Импульс срабатывает, когда значение абс скорости больше 2,5.Android GC обычно вызывает скорректированную по времени скорость -18.

Любая помощь приветствуется.Я понимаю, что структура кода могла бы быть лучше, но я просто пытаюсь визуализировать и применять физику для развлечения.Спасибо.

// 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;
        }
    }
}

Вывод, когда мяч лежит на полу и возникает внезапный импульс (см. Код для комментариев в журнале)

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

Ответы [ 2 ]

1 голос
/ 11 июня 2011

вы не должны использовать временной шаг, основанный на том, сколько времени прошло с предыдущего расчета, потому что это может вызвать такие проблемы и ошибки при обнаружении столкновений, если у вас их еще нет. Вместо этого для каждого обновления вы должны установить «временной чанк» или максимальное количество времени для каждого обновления. Например: скажем, вы хотите 30 кадров в секунду, а в nanotime около 33333333. таким образом, 33333333 = 1 временной чанк. так что тогда вы можете сделать цикл while

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;
}
0 голосов
/ 06 февраля 2011

Трудно быть уверенным, но похоже, что проблема не в увеличении во временном шаге, а в большом временном шаге.Вы интегрируете и отскакиваете Verlet как отдельные процессы, поэтому, если мяч начинается с положения покоя на полу с большим временным шагом, он падает далеко в пол, набирает скорость, а затем отражается в воздухе.Держите временной шаг маленьким, и у вас не будет этой проблемы ... много.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...