Re: Bouncing circles, simple
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 30 Sep 2005 13:09:37 +1000
"Mike Austin" <no@xxxxxxxx> wrote in message
news:rRW_e.92036$qY1.63316@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> cr88192 wrote:
>> "Mike Austin" <no@xxxxxxxx> wrote in message
>> news:Z8l_e.328012$5N3.67275@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>>>It's not very hard and I've done it before long ago, but I can't seem to
>>>get two circles to bounce off each other correctly. All I need is the
>>>incident angle, and the angle between it and the velocity vector,
>>>correct?
>>>
>>>I did some Googling, but everybody seems to write the math a little
>>>different so I can't get a good grasp on it. The code below adds
>>>relative velocity to simplify the math, I'll convert to absolute when I
>>>understand it better.
>>>
>>>Thanks,
>>>Mike
>>>
>>>
>>>// The relative position of two objects
>>>delta = obj_a.pos - obj_b.pos
>>>
>>>// The angle between two objects
>>>angle = atan2( delta y, delta x )
>>>
>>>// Calculate momentum transfered
>>>speed = obj_a.vel.length * dot( delta, obj_a.vel ).normalize
>>>
>>>// Transfer momentum from obj_a to obj_b
>>>obj_a.vel -= vector( angle.cos * speed, angle.sin * speed )
>>>obj_b.vel += vector( angle.cos * speed, angle.sin * speed )
>>>
>>>// Do the same for obj_b to obj_a
>>>[...]
>>
>>
>> hmm, it is curious what exactly is going on to allow the code to be
>> written like this (or, it is some form of psuedocode...).
>
> It's converted from Io to pseudo-c.
>
ok.
>> ok, you probably don't want to do this as 2 steps:
>> A->B then B->A, because in my experience (especially when working
>> directly with an object's velocity, vs an impulse or such) this can lead
>> to poor behavior.
>
> I would like to do it in two steps because I also need to calculate force
> between them (1 / d^2), and it simplifies the code.
>
ok.
though possible, one may need to be a little more careful I would guess.
<snip>
>
> I don't know why you're using e or what restitution is supposed to do.
> Here's my revised pseudo-code, but I'm not sure it conserves momentum -
> "object_a velocity length + object_b velocity length" should be equal
> before and after the collision, correct?
>
e is mostly just what I used before (originally I think it came from one of
the papers I read). however, the notion was not new to me, just, previously,
I had not bothered to come up with a good name for it anyways (it was stuck
in one of my general purpose 'f' or 'g' variables).
generally, it refers to how much of a "bounce force" to add. otherwise, if
all is working well, the objects should not bounce (inelastic collisions).
I am, however, not sure on whether or not the laws of conservation still
hold (whenever there is a collision, a little fudging is made to the
forces). reality works a little different on this front, and typically
physical realism was put at a lower priority than "visual realism".
> relative_position = object_a.position - object_b.position
> incident_angle = atan2( relative_position.y, relative_position.x )
> velocity_angle = atan2( object_a.velocity.y, object_a.velocity.x )
> magnitude := object_a.velocity length * cos( incident_angle -
> velocity_angle )
>
> object_a.velocity -= vector( cos( incident_angle ) * magnitude,
> sin( incident_angle ) * magnitude )
> object_b.velocity += vector( cos( incident_angle ) * magnitude,
> sin( incident_angle ) * magnitude )
>
> [calc object_b]
>
yeah, it might work.
if one does not need mass or other features, this could be ok.
still, worth noting:
though subtle, I still view "impulses" as an important feature.
instead of applying forces to velocity directly, they accumulate them and
add them at the end of the frame.
something like:
object_a.impulse -= vector( cos( incident_angle ) * magnitude,
sin( incident_angle ) * magnitude )
object_b.impulse += vector( cos( incident_angle ) * magnitude,
sin( incident_angle ) * magnitude )
and after all the physics are done:
object.velocity += object.impulse
object.impulse = vector(0, 0)
the effects of this are related to multiple contacts.
in the multiple contact case, often, one collision will prevent correctly
handling another, and so forth (a simple example of this would be, in the
case of multiple contacts, some contacts having little effect on an objects
movement, so during that time, eg, an object will head right through another
or other weird effects).
otherwise, it is not that expensive to add them.
.
- References:
- Bouncing circles, simple
- From: Mike Austin
- Re: Bouncing circles, simple
- From: cr88192
- Re: Bouncing circles, simple
- From: Mike Austin
- Bouncing circles, simple
- Prev by Date: Part-time contract position for DirectX developer
- Previous by thread: Re: Bouncing circles, simple
- Next by thread: Hook
- Index(es):
Relevant Pages
|
