Help me with my thesis - The biggest problems in physics
by Heikki Siltala · in General Discussion · 02/06/2008 (6:09 am) · 5 replies
Full topic: Help me with my master's thesis - The biggest pitfalls in implementing physics to your game?
Hi, I'm doing my master's thesis(or "Pro Gradu") in the Department of Information Processing Science in the University of Oulu, Finland, and I need some empirical data... and it seems data gathered from forums is valid for this kind of research... SO YOU CAN HELP! (plz do) :) .. Any answers will be processed anonymously.
So, my first question is:
What are the biggest pittfalls/problems you have run into when implementing physics into your game(s)? (let's say the 10 biggest problems per person, though even one is appreciated)
And the second question:
What is your recommended solution to these problems? (if you have any)
Clarification: I need YOUR problems (and possible solutions to them) to present them in my thesis.
Thanks in beforehand to any who have time to answer my silly questions :)
Hi, I'm doing my master's thesis(or "Pro Gradu") in the Department of Information Processing Science in the University of Oulu, Finland, and I need some empirical data... and it seems data gathered from forums is valid for this kind of research... SO YOU CAN HELP! (plz do) :) .. Any answers will be processed anonymously.
So, my first question is:
What are the biggest pittfalls/problems you have run into when implementing physics into your game(s)? (let's say the 10 biggest problems per person, though even one is appreciated)
And the second question:
What is your recommended solution to these problems? (if you have any)
Clarification: I need YOUR problems (and possible solutions to them) to present them in my thesis.
Thanks in beforehand to any who have time to answer my silly questions :)
About the author
Recent Threads
#2
There will always be some lag-related physics failure, however proper interpolation will keep everything smooth in all but extreme network conditions. IE, by the time the physics interpolation fails, the interpolation of the entire game has failed, and you need to consider fixing your connection to the server or picking a closer one.
There are other issues specific to individual physics packages as well. PhysX, for example, likes to handle all collision internally, which conflicts with the TGE collision detection setup. While you can basically have PhysX handle all of the actual collision physics, you'll be running the original TGE collision detection on parallel just to keep the callbacks. Obviously there should be ways to solve this (get PhysX to do collision call-backs? Not sure if it provides any way of getting this info in the SDK, need to look into it), but it's an annoying performance sink by default. Hopefully it will be easy to just scrap the TGE collision code on my PhysX objects and get PhysX itself to set off all the onCollision/onImpact methods.
Differing processing rates can also be an issue. If your physics engine does 100 tics/sec but your game engine only does ~30/sec, then any attempts to control applied force from inside the game engine tic cycle will have odd results. For example, when attempting to make an object hover in a normal gravity environment, applying -grav * ticTime force should work, but with the physics engine updating more often than this tic count, there are short periods where gravity is not neutralized and the object doesn't remain still as a result (it bounces up and down a bit). The solution is to either do such force changes inside the physics engine's tics or to apply force over time and let the physics engine spread it out correctly over all of its ticks. The second solution is more realistic and works quite well.
I'd like to write more about this but I've got a minor hand injury which is making typing very not-fun. Perhaps I'll have some more to write when I don't have to type it with 8 fingers. =)
02/06/2008 (10:35 am)
I'm inclined to agree on the client/server thing. Actually getting the physics into the game is generally the easy part, however handling those physics accurately over a potentially very lagged connection is the difficult bit. The solution is to basically do what GG did with its very light physics engine, the Rigid Class. Every object which uses this class has an elaborate interpolation setup designed to make sure the objects are always smoothly interpolated on the client, even when lag comes into play. I haven't been able to duplicate this level of interpolation with the engine I'm using (PhysX), nor has the author of the actual PhysX TGE implementation I'm using, however it's something that's very possible and I hope to get it working in the future.There will always be some lag-related physics failure, however proper interpolation will keep everything smooth in all but extreme network conditions. IE, by the time the physics interpolation fails, the interpolation of the entire game has failed, and you need to consider fixing your connection to the server or picking a closer one.
There are other issues specific to individual physics packages as well. PhysX, for example, likes to handle all collision internally, which conflicts with the TGE collision detection setup. While you can basically have PhysX handle all of the actual collision physics, you'll be running the original TGE collision detection on parallel just to keep the callbacks. Obviously there should be ways to solve this (get PhysX to do collision call-backs? Not sure if it provides any way of getting this info in the SDK, need to look into it), but it's an annoying performance sink by default. Hopefully it will be easy to just scrap the TGE collision code on my PhysX objects and get PhysX itself to set off all the onCollision/onImpact methods.
Differing processing rates can also be an issue. If your physics engine does 100 tics/sec but your game engine only does ~30/sec, then any attempts to control applied force from inside the game engine tic cycle will have odd results. For example, when attempting to make an object hover in a normal gravity environment, applying -grav * ticTime force should work, but with the physics engine updating more often than this tic count, there are short periods where gravity is not neutralized and the object doesn't remain still as a result (it bounces up and down a bit). The solution is to either do such force changes inside the physics engine's tics or to apply force over time and let the physics engine spread it out correctly over all of its ticks. The second solution is more realistic and works quite well.
I'd like to write more about this but I've got a minor hand injury which is making typing very not-fun. Perhaps I'll have some more to write when I don't have to type it with 8 fingers. =)
#3
Ow. Ow. Ow. Molesting your physics frequency like that causes not inconsiderable pain.
Better is to tell your physics engine to change the frequency it operates at. On ODE you have no choice but to do this [the C api doesn't allow a default parameter for stepsize]. On bullet it's the third parameter to stepSimulation.
I *know* PhysX has the ability to do this, but having finally found the download on their website and figured out how to extract the documentation, it's all in windows help file format, for which I do not have a reader. Sorry, you'll have to hunt it down yourself.
Gary (-;
02/06/2008 (11:56 am)
Quote:Differing processing rates can also be an issue. If your physics engine does 100 tics/sec but your game engine only does ~30/sec, then any attempts to control applied force from inside the game engine tic cycle will have odd results. For example, when attempting to make an object hover in a normal gravity environment, applying -grav * ticTime force should work, but with the physics engine updating more often than this tic count, there are short periods where gravity is not neutralized and the object doesn't remain still as a result (it bounces up and down a bit). The solution is to either do such force changes inside the physics engine's tics or to apply force over time and let the physics engine spread it out correctly over all of its ticks. The second solution is more realistic and works quite well.
Ow. Ow. Ow. Molesting your physics frequency like that causes not inconsiderable pain.
Better is to tell your physics engine to change the frequency it operates at. On ODE you have no choice but to do this [the C api doesn't allow a default parameter for stepsize]. On bullet it's the third parameter to stepSimulation.
I *know* PhysX has the ability to do this, but having finally found the download on their website and figured out how to extract the documentation, it's all in windows help file format, for which I do not have a reader. Sorry, you'll have to hunt it down yourself.
Gary (-;
#4
The first and primary, is just caused by the simple limitations of the library versus what you want to do. If you want to have a character control a multi-bodied actor group while it's being driven by animation, but you also want to have dynamically based collision against other physical objects in the game world, and *then* have those interactions affect your player, you have to do some *very* tricky things in PhysX. Especially since you want the server and client to match up. It's also very difficult to build physics constructs that will be interpreted in a way that's friendly to the engine (for instance, when making a ragdoll for a skeleton in 3DSMax, you have to position the origins of shapes to coincide with the orientations of nodes in your skeleton, if you want to use the transforms from those actors to position the skeleton. Tricky.). The solutions for these things are won through mainly trial and error, and that can eat up a lot of time, especially if the pipeline starts with art.
Next I'd say is networked physics, and this is even harder. In an ideal world, your simulations running on client and server are 100% deterministic, so you can do only minor corrections on client simulations and maintain consistency. The truth is, that almost never happens. Solutions for this are basically up in the air, it's an exceedingly tough problem in games and only gets worse as your need for lower bandwidth usage intensifies. A possible way to do it is to try and predict where both server and client will move based on current velocity, acceleration, and position. Then send the client the actual server position and velocity, and try and correct to that. There are corner cases where this works very poorly (e.g., when the client is blocked by something in the client sim, and cannot reach the server position but continues to correct there).
02/13/2008 (11:35 pm)
I'd say the biggest problem with implementing physics into a game engine is twofold. The first and primary, is just caused by the simple limitations of the library versus what you want to do. If you want to have a character control a multi-bodied actor group while it's being driven by animation, but you also want to have dynamically based collision against other physical objects in the game world, and *then* have those interactions affect your player, you have to do some *very* tricky things in PhysX. Especially since you want the server and client to match up. It's also very difficult to build physics constructs that will be interpreted in a way that's friendly to the engine (for instance, when making a ragdoll for a skeleton in 3DSMax, you have to position the origins of shapes to coincide with the orientations of nodes in your skeleton, if you want to use the transforms from those actors to position the skeleton. Tricky.). The solutions for these things are won through mainly trial and error, and that can eat up a lot of time, especially if the pipeline starts with art.
Next I'd say is networked physics, and this is even harder. In an ideal world, your simulations running on client and server are 100% deterministic, so you can do only minor corrections on client simulations and maintain consistency. The truth is, that almost never happens. Solutions for this are basically up in the air, it's an exceedingly tough problem in games and only gets worse as your need for lower bandwidth usage intensifies. A possible way to do it is to try and predict where both server and client will move based on current velocity, acceleration, and position. Then send the client the actual server position and velocity, and try and correct to that. There are corner cases where this works very poorly (e.g., when the client is blocked by something in the client sim, and cannot reach the server position but continues to correct there).
#5
1) spatial query - with more dynamic physic objects in the game, performance degrades expnentially, due to collision checking in terms of O(n^2). Some engines attempt to use OctTree, AABB Tree, and Spherical BVH in attempt to reduce the search to O(log n) but deleting and re-inserting moving objects in a tree are still too costly. Ratcliff's spherical BVH mentioned in Game Programming Gems 2 is a good article but there is no mention of time measurements for these processes and what the cost of randomly removing and recreating supernodes are. I've yet to test his 3D model.
2) phycis integration accuracy over cost - a) Jacobian matrix solver - most accurate and most costly, b) RK4 - still costly as n increases and objects are networked, c) Euler - mostly commonly used and accepted, even if it's less accurate. What I haven't see much of is the use of Verlet Integrator. My understanding is that the method lies some where between b and c, but I've yet to test it in a game.
3) network - much has already been discussed about this already, but while most games are server deterministic and clients interpolate the error and tick back to the correct position, I've would like to see more articles written about Dead Reckoning Algorithm and would like to see some demos, maybe even comparing two methods would be ideal. Using Dead Reckoning Algorithm means less packet transmission for all objects even physics objects, which can potentially eat up all the bandwidth due to large amounts of data that's required to be stored and networked.
My list outlined above are things I tried to improve and are not necessarily all the bottle necks related to physics in games. I'm sure there are lots of papers on the subject and I look forward to reading yours when it's finished.
02/19/2008 (9:29 am)
There are several problems associated with physics and other components required to process physics. I'll list problems that I commonly see as problems, not in any particular order:1) spatial query - with more dynamic physic objects in the game, performance degrades expnentially, due to collision checking in terms of O(n^2). Some engines attempt to use OctTree, AABB Tree, and Spherical BVH in attempt to reduce the search to O(log n) but deleting and re-inserting moving objects in a tree are still too costly. Ratcliff's spherical BVH mentioned in Game Programming Gems 2 is a good article but there is no mention of time measurements for these processes and what the cost of randomly removing and recreating supernodes are. I've yet to test his 3D model.
2) phycis integration accuracy over cost - a) Jacobian matrix solver - most accurate and most costly, b) RK4 - still costly as n increases and objects are networked, c) Euler - mostly commonly used and accepted, even if it's less accurate. What I haven't see much of is the use of Verlet Integrator. My understanding is that the method lies some where between b and c, but I've yet to test it in a game.
3) network - much has already been discussed about this already, but while most games are server deterministic and clients interpolate the error and tick back to the correct position, I've would like to see more articles written about Dead Reckoning Algorithm and would like to see some demos, maybe even comparing two methods would be ideal. Using Dead Reckoning Algorithm means less packet transmission for all objects even physics objects, which can potentially eat up all the bandwidth due to large amounts of data that's required to be stored and networked.
My list outlined above are things I tried to improve and are not necessarily all the bottle necks related to physics in games. I'm sure there are lots of papers on the subject and I look forward to reading yours when it's finished.
Torque Owner Gary "ChunkyKs" Briggs
My personal experience is that getting stuff to behave the same on the client and on the server is the biggest problem. That being the case, you might find this an interesting read.
Gary (-;