What side skills are essential / noteable plusses for becoming a game physics programmer?

job related to game physics

[s]Well, there aren't many jobs related to game physics to be honest. Game physics is continuously improving, but there aren't any major leaps , compared to e.g. rendering. There are some good, even some free, physics engine avaiable and creating a physics engine, a stable physics engine ,is incredible hard. Therefore most, if not all, studios uses one of this engines.

Mathematics is getting more and more important in rendering (but this market is already ruled by existing professional engines too).[/s]

Okaay... sorry for getting Off Topic

What about other side-skills?

Well, soft skills are useful.

Please stay On Topic.

Okaay... sorry for getting Off Topic

Well, soft skills are useful.

Haha. I'm sorry if you think I was being rude, but let's be honest here, everyone that did a little bit of research knows that making physics engines is hard, and it's also hard to find a job as game physics programmer. It's a danger to every similar thread to fall down to those discussions. To avoid these, I replied "please stay on topic"

How much should I know about graphics programming, and to what extent should I know DirectX/OpenGL?
What about networking?
What about other side-skills?

I'm a graphics programmer, but have worked with physics programmers.
Knowing enough of a graphics API (of any kind) so that you're comfortable with drawing debug shapes (e.g. visual versions of your physics capsules/boxes/spheres, or force lines, arrows, etc) would be handy. Also, knowing how to transfer object transform data (e.g. a 4x4 matrix) from your physics engine over to the visual objects.
You'd almost always be doing this via a higher-level graphics engine, not D3D/GL directly, so learning those APIs specifically isn't a strict requirement.
Perhaps if you were doing something more advanced, like soft-body simulation, or CFD/Navier–Stokes equations, etc, then you'd want to have a much better grasp on graphics and visualisation techniques.

If you knew enough about networking to be able to have a conversation about how to handle the network-replication of physics-driven objects, and different networking strategies, like dependent lock-stepping, authoritative servers, etc, then that would be a plus.

Being qualified in another role -- either general gameplay programming, and/or another speciality like animation systems, would be very useful.
As mentioned in the off-topic above, (almost) everyone uses existing physics engines, so the job of the physics programmer is to tame that existing code and make it do exactly what a specific game requires -- this might not keep you busy for a whole project, so being able to perform other roles might be required of you.

As for educational materials, I always see the same few books on people's desks.

Shell scripting. Whether that be bash script, powershell, or something a little more friendly like Python, is up to you. But either way, you need to know your way around the shell (find, grep, sed, etc.), and know how to write scripts to automate repetitive tasks.

Shell scripting. Whether that be bash script, powershell, or something a little more friendly like Python, is up to you. But either way, you need to know your way around the shell (find, grep, sed, etc.), and know how to write scripts to automate repetitive tasks.

Could you name an example specific to physics programming where shell scripting is used? I've heard of shell scripting before, but that's about it.

Could you name an example specific to physics programming where shell scripting is used? I've heard of shell scripting before, but that's about it.

I was more intending that as a general injunction towards any form of programming. A programmer who doesn't know their way around the shell, or can't automate simple tasks, is a pretty useless programmer in most environments.

Also, physicists love python.

I can automate simple tasks easily, I just don't know my way around the shell... Is that a problem?
And I do know some python. Not exactly an expert on the language but I can make most tasks work with it

I just don't know my way around the shell... Is that a problem?

It's not necessarily a deal breaker, but it's definitely something I consider a deficiency in any serious developer.

What happens when you need to search for a specific pattern in 500 MB of build log files stored on a remote build server? For a someone familiar with the command line thats a one-line call to ssh+grep. If you are stuck in GUI-land, it's likely to present a stumbling block...

What happens when you need to search for a specific pattern in 500 MB of build log files stored on a remote build server? For a someone familiar with the command line thats a one-line call to ssh+grep. If you are stuck in GUI-land, it's likely to present a stumbling block...

In GUI land, you open a remote desktop connection to the server and then open the log in your favourite text editor.

YMMV, but I learned bash/grep/sed/etc in University and then never touched them again. Mostly because they don't exist on Windows, and there's not much point installing some Unix-style shell like cygwin, when a Python interactive shell is actually more powerful.
If I need to automate something, I'll use Visual Studio macros, or a Python script (or PHP, or JavaScript, or even C), or use Excel, or a DSL like CMake.

On the topic of every-programmer side skills - make sure you're comfortable with version control systems. Ideally, both a centralized one like Subversion/Perforce, and a distributed one like Git/Mercurial.

Hi Xcrypt,

I worked as game physics programmer for a number of years during the xbox/ps2 -> 360/ps3 transition.

From the sound of things, you want to do physics simulation programming? Games being one application of this?

If it is the mathematics of physics simulation that interests you then graphics programming is not that important. It will depend on how visual you want your simulations to be...

If your actually interested in making physics games, then I would say graphics are important. My understanding of graphics was pretty minimal when I started but when your physics simulation starts to interact with skeletons/geometry (such as with ragdolls or cloth) you'll need to have a decent understanding of how skeletons work and local/parent spaces and translating worldspace simulation data into changes in local position and orientation of bones of the skeleton. Cloth/hair simulation is harder again dealing with vertex and geometry formats (i.e. as your simulation manipulates the cloth the vertex normals and uv coordinates might need adjusting).

But, game physics is made easier by all the popular engines (bullet, havok, physX to name the most popular). These all provide a foundation from which to implement the physics of your game.

Bullet is also great if you want to get involved in the mathematical side as all the source is included. You could implement your own solver and take advantage of all other scaffolding that is already setup. Or create your own system for what ever you want to simulate.

Also, physics programming (from a game perspective) is significantly more about providing a efficient and easy interface to the physics engine being used. I spent most of my time implementing wrappers around different underlying engines and providing features to artists (e.g. configurations so artists could add physics functionality to their art assets).

I should also note that physics programming is a specialty of programming... I'd suggest developing your general programming skills (shell scripting/operating systems/ C++ (and other languages)/ algorithms/ etc) as well so that you make yourself as attractive as possible to potential employers. Getting started in the industry as a physics programmer is pretty hard, most juniors would start off learning many different aspects of game programming (graphics/ai/ gameplay/ asset pipline/ etc) before choosing a specialty... And in this day and age where AAA titles are on the decline and mobile games on the rise, a jack of all trades is much more useful

But, if your at the bleeding edge of mathematics, with good concurrent/vector programming skills, companies developing physics engines need employee too (albeit jobs are few and far between).

I hope that helps.

Cheers,
Brad

From the sound of things, you want to do physics simulation programming? Games being one application of this?

If your actually interested in making physics games, then I would say graphics are important.

I should also note that physics programming is a specialty of programming... I'd suggest developing your general programming skills (shell scripting/operating systems/ C++ (and other languages)/ algorithms/ etc) as well so that you make yourself as attractive as possible to potential employers. Getting started in the industry as a physics programmer is pretty hard, most juniors would start off learning many different aspects of game programming (graphics/ai/ gameplay/ asset pipline/ etc) before choosing a specialty... And in this day and age where AAA titles are on the decline and mobile games on the rise, a jack of all trades is much more useful

I hope that helps.

Cheers,
Brad

Thanks Brad, yes I want to do physics simulation programming. I am just as interested in the mathematical side as in the graphical side though.
I already have basic understanding of the D3D10 graphics pipeline, made a few applications and a basic 3D game engine with it, but I'm still far from an expert with it. The reason I mentioned graphics is because I saw some physics programmer portfolios, and they seem to be an expert on anything from rigid bodies to soft bodies and CFD, as well as graphics.

Also, I have a year or two experience with C++. Of course one can never master C++, but I'd say I know the language well above average.

I'm definitely interested in other aspects of game programming as well, and I will try to develop them as well as I go through my learning process. It's just that physics is definitely my favourite branch within game programming

I worked as physics programmer my whole career. Initially I implemented a physics engine for Lair - on the PS3. After this I worked at Havok in the destruction and physics team. After some time as freelancer where I most mentionable implemented a bunch of subsystems (contact creation and solving) for Ubisofts inhouse Motion engine which is now used in e.g. Ghost Recon. Lately I integrated Blizzard inhouse engine used in Diablo 3 into Starcraft 2 - Heart of the Swarm. Now I am at Valve and do physics again

From my experience there are two things. Physics engine development and physics engine integration. Usually people are somewhat familiar with one the two though I argue it definitely helps to understand both ends. Obviously understanding the limitations of physics engines helps with integrating them. On the other end understanding the common requirements of a game engine helps with implementing the needed features in a physic engine.

For writing physics engines there is indeed not much bundled information out there. There is lot of information and there is a lot of useless information. I think in the first years I spend a lot of time reading through useless crap, picking up a gem every here and there. If you want to learn about physics engines I recommend taking Box2D Lite and port it to 3D. Then iterate from there with broadphases, block solvers, different friction, contact models or whatever interest you. One thing that is is really important is that the requirements for physics engines are changing. From my experience constraint solvers and ragdolls are nice, but what is much more important is is fast collision detection. This includes containment queries and any kind of casting rays, boxes, capsules, etc. So usually when you become a physics programmer you also become an expert on collision detection. Another thing that is always forgotten (even in some commercial packages until more recent times) is geometry processing. E,g convex hulls, convex hull simplification or convex decomposition. A solid understanding of computational geometry is very helpful.

For the integration part this is usually setting up the game engine to route collision queries through the physics system and attach it to the animation system. E.g. switching to ragdolls from animations and inherit the velocity. Or drive to some pose from where ta character can stand up. So on this end a good idea of a general game engine workings and of course the animation system in particular is very helpful.

Regarding your question about graphics programming I have a solid understanding of OpenGL and DirectX, but I would not be able to write a deferred renderer without some upfront reading into this topic. And to be honest this was never required. Usually you setup a simple rendering for your testbed for your physics engine which is quite trivial or you setup the current render system in the game to do your debug rendering. Personally I found that the better graphics programmers always a some artistic understanding which I am missing totally.

So if you want to learn physics programmer I recommend looking into Box2D and all of Erin Catto's presentations. Get something up and running and then experiment with this. A good start is a simple pendulum and a falling sphere. Then a box, a stack, etc. Don't try to reinvent everything, but make sure you understand the current state of the art first including its limitations.

Besides Erin's work you can also look for publication of Claude Lacoursiere. He was one of the initial engineers on the ODE while it was developed at MathEngine and he has put some good lectures out there at Umea (a swedisch university). You can google for "Spook" as well in the context.

For collision detection I recommend the books from Gino v.d. Bergen and Christer Ericson.

I hope this helps a bit. Good luck!
-Dirk

So if you want to learn physics programmer I recommend looking into Box2D and all of Erin Catto's presentations. Get something up and running and then experiment with this. A good start is a simple pendulum and a falling sphere. Then a box, a stack, etc. Don't try to reinvent everything, but make sure you understand the current state of the art first including its limitations.

For collision detection I recommend the books from Gino v.d. Bergen and Christer Ericson.

I hope this helps a bit. Good luck!
-Dirk

Thanks Dirk, good to hear from you!

Have those books, they are very nice. Comp geometry / collision detection is probably what I'm best at (thanks to those books). I'm having some trouble implementing a good solver though.
I've seen Erin's Catto ppt presentations before, they help but it would be better if I could find the text associated with them. I tried to look for them for a while but never found them. Do they exist?

I made a very basic 2D physics engine, just basic different shaped rigid bodies moving, rotating and colliding against each other, using mostly SAT for CD, and a very basic impulse based solver. I was just planning to take on Box2D Lite, but then my math studies started, don't have that much time atm. I will definitely pick up that idea again when I have some time!

Erin talks about a bunch of solver stuff in his presentation. His first presentation is called "Iterative Dynamics" essentially explains the ODE quickstep solver. A later presentation talks about sequential impulses. You can find his presentations here: http://code.google.c.../downloads/list

For solvers I recommend looking into "Computational Dynamics" by Shabana. Also the PhD thesis of Kenny Erleben is quite good It is also a great explanation of the ODE quickstep solver. http://image.diku.dk...n.05.thesis.pdf

Note that they are essentially three kind of solvers. Position based solvers (sometimes refereed to as Verlet solvers) which are usually used in cloth simulation. Look at the original Jakobsen GDC paper on this. Also Mueller has a nice paper called Position-Based Dynamics. Next you have the velocity based solvers which are currently used in all game rigid-body simulators out there - to my best knowledge. Finally there are the acceleration based solvers which are expalined quite nicely in the Baraff papers, but they are not very frequently used in games. They are *maybe* more important in engineering, but I am not sure what the current state of the art is there. Alygoryx uses the Spook solver as developed in Claude's PhD if I understand them correctly and this is also a velocity based approach.

Helmut describes some difference in his Master thesis pretty well. You can find it here: http://www.digitalru...dy Dynamics.pdf

Here are the papers about Spook: http://www8.cs.umu.s.../spooknotes.pdf
This is the course at Umea I recommended: http://www8.cs.umu.s...dv058sched.html

Enjoy!


Jacobsen: http://www8.cs.umu.se/kurser/5DV058/VT09/lectures/JacobsenGDC2003.pdf
Mueller: http://www.matthiasmueller.info/

That's just *insert f word* awesome! Thanks a lot