Object is 'twitching' on the ground in my physics simulator

AI Thread Summary
The discussion revolves around a physics engine experiencing a 'twitching' effect when objects come to rest, caused by gravity pulling them through the floor and collision detection pushing them back up. The simulation operates in a specific order: calculating acceleration due to gravity, checking prior collisions, updating position, and updating velocity. A key concern is that collision detection may be occurring before new positions are updated, leading to the twitching effect.Participants suggest that the velocity vector may not be updating correctly and that if the floor is angled, the object might be repositioned inconsistently, causing erratic movement. The code snippet provided updates the simulation 33 times per second, calculating position and velocity based on gravity and handling collisions by rolling back positions when objects intersect with the ground. Adjustments to the collision detection order have been attempted but have not fully resolved the issue. Additionally, it is noted that the acceleration calculation must ensure that objects at rest on a solid surface have zero acceleration to prevent further movement.
EricMiddleton
Messages
3
Reaction score
0
I am working on a simple physics engine right now and when the object eventually comes to a rest, it starts 'twitching' (moving up/down slightly very quickly) because gravity pulls it through the floor, and then the collision detection pops it back up. Here is the order in which my simulation operates:

Calculate Acceleration (Gravity)
Check prior collisions
Update Position
Update Velocity

The only thing I can think of is that the collisions are being tested before the new positions are updated. Thanks for any help you can provide.
 
Technology news on Phys.org
EricMiddleton said:
I am working on a simple physics engine right now and when the object eventually comes to a rest, it starts 'twitching' (moving up/down slightly very quickly) because gravity pulls it through the floor, and then the collision detection pops it back up. Here is the order in which my simulation operates:

Calculate Acceleration (Gravity)
Check prior collisions
Update Position
Update Velocity

The only thing I can think of is that the collisions are being tested before the new positions are updated. Thanks for any help you can provide.

Can you post a little more information about the actual code? I know its not feasible to dump every routine (even if you did want to), but it's hard to really know specifically is wrong.

I'm wondering if your velocity vector gets the right update. If the collision code is correct, then if gravity is ok and the floor of your map is on the x-y axis (I'm assuming z points up in this case), then the collision should always move the object to the same point (assuming the object is actually or is treated like a box).

But if the floor of your map is at an angle, what may happen is that due to the orientation of your vector and possibly your routine, you might be re-projecting your object at a different place each time and hence you see the weird movement.

Again this is all speculation, and I can't really give a solid comment without getting more information.
 
I'm currently writing the prototype in a game called Garry's Mod using an an extension called wiremod, for ease of debugging. The language is called Expression2, and its very easy to understand.

Code:
T = 1/33 #This code is updated every tick (33 times per second)
Acceleration = vec(0, 0, -gravity())

Position += Velocity*T + Acceleration/2*T^2

Velocity += Acceleration*T

holoPos(1, Position) #update the position (necessary to get proper bounding box translations)

for(Loop = 1, Count) #iterate through each object
{
    E = holoEntity(Loop)
    Box = E:toWorld(E:boxSize()) #Translate the object's bounding box
    if(Box:z() < 0) #if it's below the ground
    {
        Height = Box:z()
        Ang = 90 - Velocity:toAngle():pitch() #calculate angle
        Dist = -Box:z() / cos(Ang) #calculate how far it's gone
        Time = abs(Dist/Velocity:z()) #derive time from the distance
        Position -= Velocity * Time #roll back the position
        T += Time #speed time back up
        Velocity -= Velocity * Time
        Velocity *= vec(1, 1, -0.5) #inelastic collision
        HitLoop = Loop #for debugging
        Velocity -= vec(min(abs(Velocity:x()), Mu*Velocity:z()*Mass)*sign(Velocity:x()), min(abs(Velocity:y()), Mu*Velocity:z()*Mass)*sign(Velocity:y()), 0) * T #friction
    }
}
holoPos(1, Position) #update the position again
I also tried moving the collision detection down near the end of the code (as seen above) which seems to help a little, but not eliminate the issue entirely.
 
The accelerations calculation will have to determine that objects at rest on a solid surface end up with zero acceleration.
 
Dear Peeps I have posted a few questions about programing on this sectio of the PF forum. I want to ask you veterans how you folks learn program in assembly and about computer architecture for the x86 family. In addition to finish learning C, I am also reading the book From bits to Gates to C and Beyond. In the book, it uses the mini LC3 assembly language. I also have books on assembly programming and computer architecture. The few famous ones i have are Computer Organization and...
I had a Microsoft Technical interview this past Friday, the question I was asked was this : How do you find the middle value for a dataset that is too big to fit in RAM? I was not able to figure this out during the interview, but I have been look in this all weekend and I read something online that said it can be done at O(N) using something called the counting sort histogram algorithm ( I did not learn that in my advanced data structures and algorithms class). I have watched some youtube...
Back
Top