Kinematics and Linear Momentum

[anonymous23323124]

For my supercharged asteroids/space invaders game I have written basic physics:
-> kinematics with position, velocity and (constant[ish]) acceleration
-> perfectly elastic linear momentum collisions

I have written a post on my blog about the way I implemented it, but I'm not sure if I've phrased things very well. Therefore I was wondering if anyone on here had 5 minutes to take a look at it... :)

http://sfmlcoder.wordpress.com/2011/06/24/space-fight-physics/

In particular, do you think it could do with explanatory diagrams for some of the vector arguments?

[helios]

A physics object in the game doesn’t keep track of it’s own position or facing for technical reasons (they is part of the graphics object, which gets them from sf::Sprite).

What? So the flow of information is graphics -> physics? What kind of backwards design is this?

The vector part is incoherent.
x=x-x <=> x=0
Some subscripts would help.

[anonymous23323124]

Yes, it's a horrible design. But the problem is that SFML puts that information inside sf::Drawable, from which sf::Sprite inherits. Clearly the sprite must be part of the graphics objects. It seems to me that it would be an even worse idea to duplicate the position of every object, in the physics and graphics object and then have to copy the values from one to the other each frame.
If you can suggest a means by which so the physics objects can keep track of its own position, without duplication, I would be really graetful.

Some subscripts would help.

There were supposed to be subscripts... just an omission. I am still getting used to LaTex, and I was having some difficulty making the subscripts parse correctly so I temporarily had deleted them, and then forgot to fix it. Corrected now - thanks for pointing it out.

[helios]

It seems to me that it would be an even worse idea to duplicate the position of every object, in the physics and graphics object and then have to copy the values from one to the other each frame.

I disagree.
It's not duplication because the two are different data that, at this time, happen to have the same value. One is the object's physical position and the other is where it'll be displayed on the screen. In reality, there's a clear difference between an object's physical position and its position on the observer's perception. By merging them, you're ignoring this difference.

[anonymous23323124]

Okay then. When you put it like that, the change might even make things simpler. Physics objects' locations could be relative to the player (thus saving me having to add the player's location to theirs' when they are spawned).

It could then be left to the graphics object to transform those local coordinates to global coordinates. Come to think of it, it might even solve one or two other little niggles...

Thanks for your very helpful feedback. Much appreciated :)

PS: I shan't edit the post now as it's late over here, but I shall do it tomorrow.

[tition]

Hehe I think as usual wikipedia is great on the topic :)
http://en.wikipedia.org/wiki/Elastic_collision

[anonymous23323124]

@tition All the formulae and theory I used was from Wikipedia already :p
http://en.wikipedia.org/wiki/Linear_momentum#In_one_dimension
http://en.wikipedia.org/wiki/Linear_momentum#In_multiple_dimensions

[tition]

I was actually thinking how to implement if you allow objects to rotate around their centers of mass.

The formulas are not particularly easy however (in fact, I don't know how to do them). Imagine two smooth, but not necessarily circular object colliding. Say, one of the objects is an oval (ellipse) and the other - a disk.

Then if the orthogonal component of the impact does not pass through the center of mass of the oval, the oval will obtain two motions: translational, and also rotational around its center of mass. Fortunately, this never happens with disks, but if you want to use more fancy shapes, such as asteroids...

[Edit]: It *actually* can happen with disks too, provided that one of the disks had a spin (rotation around its center of mass). You are right it can't. Or wait a minute... wasn't there something like "perfect friction" - this is when you imagine that the surfaces touching interact like gear wheels?

Do you plan on including spin in your formulas?

[Edit]: Note that how to compute this is not explained in any of the posted wikipedia articles.

[anonymous23323124]

I've taken various mechanics courses during my maths degree, so I could probably work it out from some of my old notes. However, I'm not sure if it's worth it for this simple game. When I'm done with it I shall return to writing my SFML game engine, which will, of course, have much more extensive physics.

It *actually* can happen with disks too, provided that one of the disks had a spin (rotation around its center of mass).

Not if the discs are perfectly smooth ;)

My main reason for excluding angular motion is that I could no longer simply use bounding spheres for collisions, which would result in what is probably undue effort given the small scale of the project .