# Impulse of objects in a physics simulator

## Main Question or Discussion Point

I am making a physics simulator for a computer.

All objects have their translational and rotational momentums stored, and each frame, objects are moved according to these values.

Upon collisions, momentum is transferred from one object to the next.

However, I do not know how to find how much momentum is transferred from one object to the next.

For example, say object A hits object B straight on. Currently, all of A's momentum would be transferred to B instantaneously. However, if this is how the system acts, then consider the situation when a battlecruiser in space hits a golf ball: the cruiser would stop completely, and the golf ball would end up with astronomical momentum.

This is obviously not accurate: the momentum of the battlecruiser would only partially be transferred to the golf ball.

How do I calculate the amount of momentum transfer between colliding objects? I think that it has something to do with Impulse, but I don't know how to find that either.

Related Other Physics Topics News on Phys.org
first of all, what program are you using. If you are using Flash, you might just as well quit it now, you won't get far with it's brute-force game programming. It would be bset to use Java for this imho.

Secondly,
http://en.wikipedia.org/wiki/Elastic_collision

Java?! Java is a slow, inefficient, poorly implemented Juggernaut. I'm making an engine in C with a Python front end. Are my problems all solved by using elastic collisions?

I'm not a fan of Java, I think that it teaches bad programming paradigms. However, I think that inheritance should not be a part of OOP and is inherently broken (thus the 'no multiple inheritance' and 'interface' workarounds) and that functional programming / possessive OOP relationships are superior.

BUT, how do those two wikipedia articles solve my problems? How do I calculate collisions with respect to these articles?

Well, with elastic collisions you can calculate what momentum each object has after collision. It's given by two formula's: the conservation of kinetic energy and conservation of linear momentum. However, elastic collisions never happen in reality since in every collision there is loss of kinetic energy (heat, sound,...). Still I think it's accurate enough for a computer program.
I strongly disagree that Java is a bad programming language. I can imagine that they say it is slow, although that's not true either because a lot of progress has been made since the first version and now it's not considerably slower than for example C or C++ (maybe 1% - but who cares about that?). Inheritance not being part of OOP is not a good thing because OO is meant to be able to think at a higher level of abstraction, i.e to think in terms of objects and relationships between them. It is a fact that humans do tend to think in is-a relationships (a dog is a mammal, a mammal is an animal, etc...). So inheritance is a natural way to design software.

Thanks for the help.

As far as java as a programming language goes, I would say that Java is almost as bad a language as C++. It is slower, and it is less efficient, and I do not agree with many of the paradigms it teaches.

For example, Java does not support first class functions. Java's threading implementation is (in my opinion) clunky, Java's syntax is burdensome, and Java's implementation of OOP is flawed.

As far as object orientation goes, Inheritance may be intuitive, but it is not very intelligent, and using it causes more problems than it fixes.

To use your example: while it is easy to make an overarching 'mammal' class, this should not be implemented in code. In inheritance style OOP, we would make a 'mammal' class with, say, 'fur' and 'give birth'. However, for every attribute that you add to the 'mammal' class, I can find an exception: for example, a duck billed platypus. When implementing a duck billed platypus, how do you deal with the fact that it lays eggs? Either you hide functionality of the mammal, which degrades the usefulness of mammal (any method that tried to use the givebirth() function of mammal would be broken) or you degrade the usefulness of mammal by excluding the birth function. While we make categories for things, all categories have exceptions, and inheritance OOP can not deal with this.

A better way to do this would be possessive OOP: if a bunch of objects are going to be 'mammals', you don't make an overarching 'mammal' container, you identify what you think classifies 'mammals'. You make a 'givebirth()' function and a 'fur' object, and then objects can possess those data. This way, exceptions to your categories do not break your code.

In fact, all inheritance relationships can be restructured as possessive relationships, which are much more dynamic and far easier to understand, and which do not give rise to issues such as multiple inheritance issues and so on.