Jump to content

  • Log In with Google      Sign In   
  • Create Account


My approach to physics


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 gdoc   Members   -  Reputation: 123

Like
2Likes
Like

Posted 10 April 2013 - 04:08 PM

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.

 

Attached File  GPX_collisionHandling.pdf   308.25KB   377 downloads

 

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



Sponsor:

#2 Krohm   Crossbones+   -  Reputation: 3020

Like
0Likes
Like

Posted 12 April 2013 - 02:07 AM

I cannot read it in detail but I appreciate your effort a lot. I think you just set the bar too high.



#3 frob   Moderators   -  Reputation: 19861

Like
5Likes
Like

Posted 19 April 2013 - 02:15 PM

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.


Check out my personal indie blog at bryanwagstaff.com.

#4 gdoc   Members   -  Reputation: 123

Like
0Likes
Like

Posted 25 April 2013 - 04:23 AM

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!



#5 kunos   Crossbones+   -  Reputation: 2203

Like
0Likes
Like

Posted 25 April 2013 - 05:00 AM

very math intensive.. I think what's missing in the paper is the "previous work" section and, of course, a demo. It's important to make sure you are actually promoting a new approach and briefly reviewing the current approaches (pointing out where you think they are failing or where your approach would be preferable)... just to make sure you and your reader are not reinventing the wheel all over again.


Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#6 grhodes_at_work   Moderators   -  Reputation: 1361

Like
1Likes
Like

Posted 30 April 2013 - 11:13 AM

I am surprised that you were unable to find satisfactory discussions of handling multiple simultaneous collisions with multiple collision points. In my view, there is quite a lot of discussions and documentation freely available about how the constraint solvers in modern game physics engines work, and address exactly these problems. This has been continuously worked and improved in the games industry for more than a decade.

 

For example, here's an intermediate level presentation from an annual tutorial series on physics simulation, from the Game Developer's Conference in 2012, discussing the implementation of a multi-body, multi-contact rigid body contact/constraint solver. The first half focuses on a single contact, but the last half delves into multiple bodies and multiple contacts. There are many such presentations and technical documents out there. The GDC tutorials on math and physics for games have been going on for nearly a decade:

 

http://www.essentialmath.com/GDC2012/Richard_Tonge_solvingRigidBodyContacts.pdf

 

And here is one of Erwin Coumans' presentations on rigid body dynamics simulation. The last 25% of this talk discusses using the GPU to accelerate constraint solving. (He presented a new one this year at GDC, back in March, describing new advances in GPU-accelerated rigid body dynamics).

 

https://github.com/downloads/erwincoumans/experiments/Accelerating%20game%20physics%20for%20heterogeneous%20CPUGPUs.pdf

 

I bet there are some excellent presentations available at the following link. These are presentations from Erin Catto's physics tutorial at GDC back in March:

 

https://code.google.com/p/box2d/downloads/list

 

You would be wise to look at some of these materials, because there are a lot of lessons learned, and practical implementation experience (LOTS of this) in those presentations. Many of these folks have worked on real time physics simulation as their full time job, for years.

 

The conservation of energy problem is also discussed in the game physics literature, though from a games perspective (fast, stable with large time steps and over long simulation times and for very diverse scenarios, realistic-looking), and not a perfect math/engineering/simulation perspective. For practical problems, even the engineering solutions don't have perfect solutions that satisfy conservation of energy. (In simulating fluid dynamics, there is a class of theoretical problems that can be solved with "perfect shift," numerical solutions of wave-like equations that generate prefectly zero error...but these are only contrived theortical problems...not in practice.) As others have written, physics is hard. But, you knew that!


Graham


Graham Rhodes Moderator, Math & Physics forum @ gamedev.net

#7 madshogo   Members   -  Reputation: 126

Like
-1Likes
Like

Posted 01 May 2013 - 11:24 AM

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.



#8 gdoc   Members   -  Reputation: 123

Like
0Likes
Like

Posted 10 May 2013 - 12:45 PM

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 smile.png 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.

 

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).


Edited by gdoc, 10 May 2013 - 02:25 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS