Skip to main content
gamedev.net
🔒 Locked

baffled!

Started by fakemind 7 replies 850+ views
Original Post
fakemind
fakemind
im trying to impliment very realistic physics in my game but im having some trouble putting it all together. it seems whenever i get an idea to fix a problem, something else comes up. the most simplistic approach seems to be this: 1) try to move everything 2) anything collide? 3) if yes, then back up where they collided and apply forces 4) draw the only problem i have with this is that lets say one entity hits something, bounces off, and then hits something else during the same time slice. if we followed the above, this couldnt happen because it would stop at the first collision. through some research i found ways to make sure two entities dont pass through each other; to find exactly when they collide if they do. i also found it wise when two entities collide to not move them, only let them apply forces to each other and let the forces move them. (note: in the following paragraph, when i say "testing for collisions" what i mean is "see if there would be any collisions if we moved all entities the distance they need to move this time slice or the rest of the current time slice.") what i was planning on doing was testing for collisions in the world during the time slice; if there were none, then we''re ok and we''ll just move everything. if there was a collision, then move all entities whatever distance they would move until the first collision takes place. then calculate forces and apply forces and then check for any second collisions (during the same) time slice. if there isnt any more, then just move everything whatever distance they would each move for the remainder of this time slice, and we''re good to go. however, if there was another collision, then move all entities whatever distance they would move until the collision takes place. then do the collision stuph again and repeat until the time slice is over. this sounded good in my head, because it would realistically simulate any physics during the time slice, multiple collisions and all. but the only problem i see is if two entities are pushing against each other - wouldnt that mean they collide at every single instant during the time slice so the computer would lock up. perhaps im missing something, and theres probably a better way to go about having everything happen that should happen during the time slice, but i cant think of it. any ideas on how to fix this problem? or a better way to simulate the world this precise? - jeremiah http://fakemind.com
TANSTAAFL
TANSTAAFL
you might say, then, that collision detection is a hit or miss kind of prospect.

*rimshot*
Get off my lawn!
zealouselixir
zealouselixir
Let''s say each "timeslice" is a frame. Simply check each entity against the other entities in the area and sum any reaction forces, then apply the summed force before the next frame.

If two entities "push against" one another, you''ll still just have valid reaction forces...

Am I missing something?

Later,
ZE.
[twitter]warrenm[/twitter]
fakemind
fakemind
well, summing forces and then moving entities would work fine if only one collision would happen with an entity during the time slice. but consider the example i gave in my previous post: an entity collides with something, bounces off and collides with a second something during the same time slice. i wouldnt think summing forces would produce this effect.

originally i was going to do the following:

1) change velocity based on forces; then null forces out
2) move all entities based on velocity
3) if there was a collision, move entities to where they are touching (just collided) and calculate forces
4) draw
5) repeat

this seems to handle "pushing" and "bouncy" (inelastic and elastic?) collisions, but an entity could only collide once during a time slice, and thats not always the case.

- jeremiah
http://fakemind.com
miles vignol
miles vignol
The way I''m doing things is sorta similar.

I move all my objects, then test for collisions for the new positions. I use the amount of overlap to determine the amount of force to apply to each object that collided with another. I could at this point apply these forces and check for collisions again, but I''ve found that just adding those forces during the next update cycle is fine (I do limit my maximum time slice to 10ms to help things).

I suggest if you''re not gonna have the double collision case occur too often, just go ahead and skip it. If you see it coming up a lot, then try a smaller time slice first. An iterative system may work as well, but if you''ve already got variable time slices working, the smaller time slice approach is totally trivial.
fakemind
fakemind
yeah, now that i think of it, i think im trying to do too much in one pass. i guess if i wanted multiple collisions and more to happen in-between frames i could just call my "do_physics()" function more than one time during each frame.

the whole reason i tried to come up with a new idea is for fast-moving objects. like lets say a rubber ball is moving really fast across the screen, an inch a frame (pretty fast). when we''re doing our physics we notice that the rubber ball hits an object 1/10th of an inch in front of it, so in all actuallity it should hit, bounce away, and be moving away from the object it hit before its drawn next (lets say 9/10ths an inch away) -- but using the classic way it would be drawn next to the object it hit, and would only start to bounce away the next frame.

oh well, i guess we can only approximate and do the best we can.

- jeremiah
http://fakemind.com
miles vignol
miles vignol
No, you can do better than that.

I dunno how "accurate" it is, but what I do is figure the amount of overlap between two colliding objects then use this amount to estimate when the collision occured.

I add up two vectors for each colliding object. One is the force from the collision and the other a "nudge" vector that acts only once to immediately move the object. The nudge vector estimates where the object would have been if it collided and bounced and the force vector adds to the velocity to create a new velocity.

I don''t use these vectors till the next update cycle when I''m moving objects (so there''s no worrying about partially updated collision lists or anything). It works well for me.


a person
a person
the trick is that a time slice even with infinite collisions, is still over when the slice is over and you draw the frame. you always set some sort of bail out upper limit which says: "ok you had your fun, now let me go do something else and deal with you after i am done with the other stuff"

so you get:

maxInters=0;
while(elapsedtime{
do_physics();
maxInters++;
}

doinput();
drawframe();

repeat;

this enforces that your time slices are handled, but if you are taking to long, you will still do the other stuff. increaesin time slices never solves everything and is a really bad way to try and increase accuarcy (though it does not hurt too much if done conservivly). the main basic thing to remeber, NEVER let the state of objects get clobbered because you are drawing or doing something else. using fixed time steps really helps with this.
jermz
jermz
I was thinking about this problem too for a 2D game. What I eventually did was calculate all possible collisions, assuming no interference, for each moving entity (obvious use of spatial grouping for culling stuff). I then performed the collisions in order and when they affected the path/velocity/acceleration, I invalidated all future collisions involving that entity and recalulated the possible collisions for that particular entity.

This handles the case you mentioned where something is stopped or bounced by one collision and then collides again (or again (or again)). The detail performed by the algorithm each update scales with the number of moving entities obviously but also with the speed. So if something is moving EXTREMELY fast in a dense or bounded area, then theres some serious problems. But otherwise it works well for me.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.