Aufspringender Ball entspricht nicht dem Energieerhaltungssatz

Question

Ich bin derzeit damit beschäftigt, eine kleine Ballphysik-Engine für meinen Programmierkurs in Win32 API und C++ zu schreiben. Ich habe den GDI-Backbuffer-Renderer und die gesamte GUI fertiggestellt (ein paar Dinge müssen noch angepasst werden), aber ich bin der Fertigstellung sehr nahe. Die einzigen großen Hindernisse, die noch bestehen, sind die Kollisionen zwischen den Bällen (aber das kann ich selbst beheben), aber das größte Problem von allen ist das Springen der Bälle. Was passiert, ist, dass ich einen Ball werfe und er wirklich fällt, aber sobald er abprallt, springt er höher als der Punkt, an dem ich ihn losgelassen habe??? das Lustige daran ist, dass es nur passiert, wenn er unter einer bestimmten Höhe ist. Dieser Teil ist der Physik-Code: (Wenn ihr mehr Code oder Erklärungen braucht, fragt bitte, aber ich würde es sehr schätzen, wenn ihr euch meinen Code ansehen könntet).

#void RunPhysics(OPTIONS &o, vector<BALL*> &b)
{ 
    UINT simspeed = o.iSimSpeed;
    DOUBLE  DT; //Delta T
    BOOL bounce; //for playing sound

    DT= 1/o.REFRESH;

    for(UINT i=0; i<b.size(); i++)
    {
        for(UINT k=0; k<simspeed; k++)
        {           
            bounce=false;

            //handle the X bounce
            if( b.at(i)->rBall.left <= 0 && b.at(i)->dVelocityX < 0 ) //ball bounces against the left wall
            {
                b.at(i)->dVelocityX = b.at(i)->dVelocityX * -1 * b.at(i)->dBounceCof;
                bounce=true;
            }
            else if( b.at(i)->rBall.right >= SCREEN_WIDTH && b.at(i)->dVelocityX > 0) //ball bounces against the right wall
            {           
                b.at(i)->dVelocityX = b.at(i)->dVelocityX * -1 * b.at(i)->dBounceCof;
                bounce=true;
            }
            //handle the Y bounce
            if( b.at(i)->rBall.bottom >= SCREEN_HEIGHT && b.at(i)->dVelocityY > 0 ) //ball bounces against the left wall
            {
                //damping of the ball
                if(b.at(i)->dVelocityY < 2+o.dGravity/o.REFRESH)
                {
                    b.at(i)->dVelocityY = 0;
                }

                //decrease the Velocity of the ball according to the bouncecof
                b.at(i)->dVelocityY = b.at(i)->dVelocityY * -1*b.at(i)->dBounceCof;
                b.at(i)->dVelocityX = b.at(i)->dVelocityX * b.at(i)->dBounceCof;

                bounce=true;
            }

            //gravity
            b.at(i)->dVelocityY += (o.dGravity)/o.REFRESH;
            b.at(i)->pOrigin.y += b.at(i)->dVelocityY + (1/2)*o.dGravity/o.REFRESH*DT*METER; 
            //METER IS DEFINED GLOBALLY AS 100 which is the amount of pixels in a meter

            b.at(i)->pOrigin.x += b.at(i)->dVelocityX/o.REFRESH*METER; 

            b.at(i)->UpdateRect();
        }
    }
    return;
}

Answer 1

Ich glaube nicht, dass Ihre Gleichung für die Position richtig ist:

 b.at(i)->dVelocityY += (o.dGravity)/o.REFRESH;

Dies ist v=v0+gt - das scheint in Ordnung zu sein, obwohl ich schreiben würde dGravity*DT 代わりに dGravity/REFRESH_FREQ .

 b.at(i)->pOrigin.y += b.at(i)->dVelocityY + (1/2)*o.dGravity/o.REFRESH*DT*METER; 

Aber das scheint nicht zu stimmen: Es ist äquivalent zu p = p0+v + 1/2gt^2 .

• Sie sollten Geschwindigkeit * Zeit multiplizieren, um die richtigen Einheiten zu erhalten.
• Sie skalieren den Gravitationsterm nach Pixel/Meter, aber nicht den Geschwindigkeitsterm. Das sollte also auch mit METER multipliziert werden
• Sie haben die Wirkung der Schwerkraft bereits berücksichtigt, als Sie die Geschwindigkeit aktualisiert haben, so dass Sie den Schwerkraftterm nicht noch einmal hinzufügen müssen.

Answer 2

Danke für die schnellen Antworten!!! Sorry, ich hätte mich deutlicher ausdrücken sollen, die RunPhysics wird nach einer PeekMessage ausgeführt. Ich habe auch einen Frame-Limiter hinzugefügt, der dafür sorgt, dass nicht mehr Berechnungen pro Sekunde durchgeführt werden als die Bildwiederholrate des Monitors. Mein DT ist also 1 Sekunde geteilt durch die Bildwiederholrate. Vielleicht ist mein DT tatsächlich zu klein, um ihn zu berechnen, obwohl er ein doppelter Wert ist??? Mein Restitutionskoeffizient ist einstellbar, beginnt aber bei 0,9.

Answer 3

Sie müssen Ihre Position beim Aufprall neu berechnen, um sicherzustellen, dass Sie von der richtigen Stelle an der Wand aufprallen.

D.h. den genauen Zeitpunkt des Abprallens bestimmen und die neue Geschwindigkeit/Position auf der Grundlage dieser Richtungsänderung berechnen (teilweise in einem "Frame" der Berechnung), um sicherzustellen, dass sich der Ball nicht bei jedem Abprall mehr und mehr über die Wände hinaus bewegt.

In Bezug auf den Zeitschritt sollten Sie sich folgende Informationen ansehen meine Antwort hier .

Answer 4

Bei einer Starrkörpersimulation müssen Sie die Integration bis zum Zeitpunkt der Kollision durchführen, dann die Geschwindigkeiten anpassen, um ein Eindringen bei der Kollision zu vermeiden, und dann die Integration wieder aufnehmen. Es handelt sich um eine Art Momentaufnahme, um der Tatsache Rechnung zu tragen, dass Starrkörper nur eine Annäherung sind. (Ein echter Ball verformt sich bei einer Kollision. Das ist schwer zu modellieren und für die meisten Zwecke unnötig.)

Sie kombinieren diese beiden Schritte (Integration der Kräfte und Auflösung der Kollisionen). Für eine einfache Simulation wie die von Ihnen gezeigte reicht es wahrscheinlich aus, die Schwerkraft bei jeder Iteration zu überspringen, bei der Sie einen vertikalen Abprall behandelt haben.

In einer fortgeschrittenen Simulation würden Sie jedes Intervall (dt), das eine Kollision enthält, an der Stelle aufteilen, an der die Kollision tatsächlich auftritt. Integrieren Sie bis zur Kollision, lösen Sie dann die Kollision auf (durch Anpassung der Geschwindigkeit) und integrieren Sie dann für den Rest des Intervalls. Aber das scheint für Ihre Situation zu viel des Guten zu sein.