Impulse of objects in a physics simulator

Click For Summary

Discussion Overview

The discussion revolves around the calculation of momentum transfer during collisions in a physics simulator. Participants explore concepts related to impulse, elastic and inelastic collisions, and the implications of these concepts for programming a physics engine. The conversation also touches on programming languages and paradigms relevant to the development of such simulations.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant seeks to understand how to calculate the momentum transfer between colliding objects, noting that their current implementation transfers all momentum instantaneously, which seems unrealistic.
  • Another participant suggests looking into elastic collisions and provides a link to a Wikipedia article, implying it may help with the calculations.
  • There is a debate regarding the choice of programming language, with differing opinions on the efficiency and effectiveness of Java versus C.
  • One participant argues that elastic collisions can be modeled using conservation laws, but acknowledges that real-world collisions are inelastic and involve energy loss.
  • Several participants express strong opinions about object-oriented programming (OOP) paradigms, particularly regarding inheritance and its implications for software design.
  • One participant critiques inheritance in OOP, suggesting that possessive OOP may be a more effective approach to handle exceptions in categorization.

Areas of Agreement / Disagreement

Participants express differing views on programming languages and OOP paradigms, with no consensus reached on the superiority of one approach over another. The discussion on momentum transfer and collision modeling remains unresolved, with multiple perspectives presented but no definitive solution agreed upon.

Contextual Notes

Participants reference concepts such as elastic and inelastic collisions without fully resolving the implications of these models for the physics simulator. The discussion also highlights the complexities of implementing OOP principles in programming, particularly in relation to inheritance and its alternatives.

_Nate_
Messages
19
Reaction score
0
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.
 
Physics 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 possesses 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.
 

Similar threads

  • · Replies 60 ·
3
Replies
60
Views
7K
  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 35 ·
2
Replies
35
Views
5K
  • · Replies 9 ·
Replies
9
Views
3K
  • · Replies 25 ·
Replies
25
Views
4K
  • · Replies 3 ·
Replies
3
Views
3K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 10 ·
Replies
10
Views
3K
  • · Replies 4 ·
Replies
4
Views
3K