Hi all.

The background of my story is that many years ago I was about to write a game based on the same idea as "Bad Piggies". I was coding in my spare time, thus development was slow and finally guys from Rovio overtook me. I'm not sure about the future of my game now, but if it is going to be abdandoned, then maybe it is a good idea to share some of my work.

Core component I was focused on was a physics engine. At the time I started to develop I was not happy with physics engines I had tested and I decided to write my own one. To my surprise literature was somewhat evasive (or maybe I searched not good enough) on aspects of dynamics I was interested in. For example I was not able to find how to deal with collisions of multuple bodies at multiple collision points or how to assure conservation of energy in the system after collision. I decided to derive formulas on my own. It was fun and I ended up with a bit of theory on which my engine could stand. A piece about collision handling was put into LaTeX and the resulting pdf is what I would like to share in this post. The rest depends on your feedback; I hope that your reaction will help me make further decisions.

Note: Project is hosted on sourceforge, but the code there is pretty old. Major update is waiting on my local drive, but I would like to hear opinions before moving on. I don't know if project makes any sense to anyone.

[attachment=14778:GPX_collisionHandling.pdf]

Paper was reviewed by my dog, so sorry for any kind of typos, bugs or bad grammar ;)

Physics is hard.

There are many groups that focus on it, such as SIGACT and SIGHPC, but they are generally focused on researchers and graduate students.

Your paper (and physics texts generally) live in the realm of mathematics and theory. That is a world where everything is continuous, where precision is infinite, and computational time is unbounded.

The world of video games is very different. Everything is discrete rather than continuous, although you can help it look continuous by searching for specific times like the instant that contact occurs. You get about six decimal digits of precision rather than infinite. And you only get about 0.001 clock seconds to complete your calculations.

Physics engines for games have come a long way. They are great at making things look good. It is more important for a game engine to provide "perceptually correct" results rather than "scientifically correct" results.

Game engines are great at making ragdolls and tumbling blocks and chains and draped cloth. The results are perceptually correct and generally look good. But these game physics engines are not scientifically sound. For example, Havok can be used for water simulators, but note that they are not used by scientists for global oceanographic studies. Havok can model stuff blowing up, but DARPA uses supercomputers and custom software to run explosion simulations. It can be used to model rocket launches into space, but space agencies don't use game physics engines to simulate launch and flight plans.

Making game physics is all about making something that is perceptually correct. You can use real-world physics equations to guide your systems. Doing much more than that is an exercise in insanity.

Well, actually I have a working code that utilizes those equations... It still needs some polishing, but whole thing seems to work... I know how unrespectful numerics is :). I hope I will be able to do a major update of my project on sourceforge and maybe prepare some binaries for the public.

Thanks for the reply!

Physics is hard. [...] Your paper (and physics texts generally) live in the realm of mathematics and theory. That is a world where everything is continuous, where precision is infinite, and computational time is unbounded. [...] The world of video games is very different. [...] It is more important for a game engine to provide "perceptually correct" results rather than "scientifically correct" results. [...] You can use real-world physics equations to guide your systems. Doing much more than that is an exercise in insanity.

There is nothing complicated in his paper. It's even a simplification of the more general case of three-dimensional rigid bodies colliding. At any rate, in both cases, the equations you get from a direct application of Newton's laws allow you to compute the linear and angular momentums at time t+dt given their previous values at time t and the forces applied to the rigid body, just by computing a few matrix products, norms, dot products and cross products. No need for infinite precision, no need for infinitesimal time steps and certainly no need for a supercomputer.

I think you just set the bar too high.

Well, any lower than that would restrict the generality of the algorithms derived from this study. It IS possible to compute good-looking, accurate physics that is not CPU-intensive without resorting to whatever doesn't look too bad, like adding a velocity proportional to penetration depth and whatnot.

@gdoc

You may want to have a look at rigid body dynamics in general as some of the formalism used in your paper could be simplified or given broader applicability. For instance, you use the determinant of two vectors for what is actually better conceived as the norm of their cross product (it's the same thing, but conceptually, I think it's better to look at it that way). Also, you regard inertia as a real number I which is good for 2D but laerning about the inertia tensor may be a good investment for the future if you ever intend to make a physics engine for 3D objects. I'd advise that you define A and B as functions of (r, n) and (r, n, p) respectively, just for the sake of clarity. We don't want people to believe they are intrinsic to the object at hand, now do we?

That being said, thanks a lot for your contribution. The formulae are sure to prove useful to anyone trying to tackle 2D rigid body dynamics.

Thanks for advices.

I must honestly say that I am a little bit drunk while writing this post, so please forgive me errors and everything.

Madhogo! He/You have touched very interesting topic (btw it is not me who downoveted post).

Determinant was put there deliberately and with full consciousness! Once I had to write a program that draws multidimensionl cubes (I have attached screenshot to give you better picture of what I am talking about). When I faced this problem I realize that rotation is actually performed on a plane, not around axis. Rotation around axis is an artificial being, which works only in 3 dimensions. Things are much more consistent and general if you use determinants. If you take a look at cross product you will find that out it consists of 3 determinants, one for each plane. You can describe rotations in 3 dimensions using determinants and this is IMO more natural, consistent and general than using cross product. In 2d you have one plane, in 3d you have 3 planes (although 2 are sufficient to rotate point to any position - I exploited this to limit number of sliders in my old Cube ?D program), in 4d you will have 6 planes (but again 3 are sufficent) and so on.

Moment of inertia on the other hand can be described by principal moments. So for 3 dimensional space it can be a 3-vector (x, y, z). If I will be able to expand my engine to 3d (or maybe even experiment with more dimensions...?) I will rather follow this path, because things seems to be much simplier. So this is why I am using determinant and real number, not because I limited myself to 2d, but paradoxically opposite, as from my earlier experiences it seems.

[attachment=15649:cube5d.png]

PS. A and B are not limited to (r, n), (r, n, p) nor (r, n, p, L). They are ultimately numbers. In fact I was already exprimenting with soft bodies, but this is another chapter (leads to cool reminiscence of Mach's principle).

I have uploaded updated files to the github. If someone wants to visit the grave -> https://github.com/michpolicht/gpx

Please don't necro threads.