Academic background for physics engine?

[Archenox]

Hello everyone!

I am almost finishing a bachelors degree in computer science and I would like to have some insight on the possible academic backgrounds and career opportunities for someone who wants to be working with the creation and development of a physics engine.

Considering that there are perhaps three sciences involved in the creation of a physics engine I am considering making master's degrees in physics and pure mathematics(topology/geometry) due to the lack of knowledge and maybe after that go into something like scientific computation.

I am aware that games do not require extreme in depth physics but I do not want to be limited to the game industry. I would like to have the knowledge required for the creation of graphics that are inspired out of the mathematical and physical sciences, some examples are the Interstellar movie, Nvidia PhysX FleX, Matlab, Mathematica, etc...

I know I will be working with a group of people and is not like I will be creating a physics engine on my own but regardless of that I don't mind all the extra knowledge I can get if it contributes to my career goal, I also happen to enjoy all of these sciences on their own. I do not know what possible titles the job I am describing could have but I know that this is what I want and I also know I can achieve great things because this is were my heart is leading me to.

What might be some of the flaws of my educational plan? Is it a good decision to make two master's degrees? Is this all too dreamy? I am confident that I can do this but I want to be extra sure that this will lead me to what I want.
Thanks in advance.
CS undergraduate degree:
http://www.uprb.edu/es/academico/departamentos/sici/sici_principal.htm

Where I could possibly do the master's degrees:
http://www.uprm.edu/cms/index.php?a=file&fid=10180

Nvidia PhysX FleX:

 

[chiro]

Hey Archenox.

If you want to work with physics engines for games then there are a few things that are different than say for simulation purposes (like animated movies) or for the stuff that engineers and applied scientists use and a lot of it has to do with real time considerations.

I recommend having a good grasp of geometry, symbolic calculus and most importantly numerical calculus.

The heart of a physics engine is basically classical dynamics where each frame you have a geometry engine in combination with a numerical integrator find the state of the next frame and this continues indefinitely.

The above - when understood is actually not the hard part. The hard part comes to things like stability where in certain situations the numerical integrator goes haywire and the simulation just gets out of control.

This type of thing is actually studied in numerical integration under stability - but the game environment can be a lot more complicated in nature.

What has to be done is that you have to handle the collisions appropriately and this will mean doing things like flagging items for potential later collision (using geometry) and detecting unstable behavior in addition to situations where things "get stuck" and then reset the state of the system.

The geometry side will require you to understand quite a lot of computational geometry, scene and spatial classification, and also how to predict if the physics engine is going to become unstable.

In numerical integration you basically update deltas as a function of time. In one second the computer can only calculate so many deltas for the scene and the other thing to keep in mind is that a good physics engine will know what objects to test and what not (based on whether they are moving and not going to collide an object or whether they are static - something which the physics engines in games optimize for).

The smaller the delta the more stable the integrator and thus the physics engine is - but as mentioned above - this does not guarantee that you will avoid instabilities.

The geometry part has to be able to do comparisons, intersections across objects, and finding the closest geometric face for collision detection. Collision detection is a subject of its own and the trade-off is that you compromise speed for accuracy. Scene classification plays a big role here and if the scene is "sorted" or organized well then this can be sped up quite a lot. The simplest scene classification tool is the Binary Spaced Partitioning which partitions based on the half-space of a plane. If you know what a plane is mathematically the intuition is to divide the space on both sides of the plane (hence the term half-space).

Then you basically look at what kind of dynamics is involved. The simplest dynamics involves rigid dynamics where shape does not deform. In this case there are a number of constants - namely the inertia matrix (or the inertia tensor) which is used for the angular and rotation based dynamics and you also have the non-angular momentum for an object. The rotational and non-rotational aspects are treated differently and you integrate each thing every frame based on the code you have for each type.

Extending rigid body dynamics looks at modelling things that deform as well as break apart and this involves numerical methods that are a lot more complex - and most importantly far more CPU intensive. Unless you can use some external physics card or processor, you are not going to be able to do a lot of this. You can certainly do it "offline" (in non-real time) if you want to do animated movies but for games this will be limited.

It means that you will have to take the object and divide it up into elements and use a lot of engineering mathematics that deal with deformation. There will be tonnes of matrix mathematics and you will need to understand what is written with tensors, differential geometry, and the field known as continuum based physics and structures. This is applied mathematics that builds on quite a lot of stuff and fields that cover this sort of thing are the engineering branches that deal with force for bodies that have a continuum of density, elasticity, and other characteristics over the structure itself.

You can always provide "hacks" that simulate the behavior without doing it from first principles and you can also construct the collision structures so that they aren't as complicated - which means you trade off accuracy for speed but real uniform deformable physics is quite a pain to get right both in complexity and in processing requirements.

If you learn enough classical mechanics, computational geometry and numerical calculus you should be able to understand, implement, and most importantly extend a basic rigid body dynamics engine where you can collide with things and the move and so on. The deformable stuff will benefit from the continuum mechanics approach discussed in both physics and engineering.

Finally there is kinematics and inverse kinematics which deals with things where objects are joined to each other.

Inverse kinematics is the harder of the two (forward kinematics is trivial in comparison) and this involves you starting with a configurations of nodes, positions and constraints on how they can act (think of bones and joints in this manner) with the intention of finding out how to take the system from one state to another in the most natural way.

This is a mathematical problem and if you are to be doing serious physics with games or simulations then at some point you are going to have to do some serious IK as well.

In terms of education, I'd be focusing on physics, relevant applied math and even engineering with continuum mechanics if I were you. The coding part is just code - code is code whatever you do and if you can translate solutions to code then you don't need any classes in this regard. Getting the math, physics and engineering right is the hard part - the code is a lot easier.