Physics Implementation

Oct 30, 2007 at 8:04 AM
Edited Oct 30, 2007 at 8:06 AM

shawmishrak wrote:
Haha, yeah, this topic has gone way off topic from the original "how should I name the public variables to be consistent with everyone else's work."

What do you mean by "simple data types?" A 60-120 Hz update rate is pretty standard on modern hardware.


With simple data types, I'm referring to Vector, Matrix, float, etc. bacially structs, but not limited to, complex types would be Entity. The reason I refer to these as simple is that the operations done on them are often mathemetical, most physics is calculations.

60-120 hz is usually refered to the fequency in which the game is being run, or rather the refreshrate of the screen being drawn. This shouldn't have anything to do with the game update itself, at least we should bind to the refreshrate for anything (that's soo 80ties). For me this implies that the physics engine will run on it's own CPU at a much higher cycle rate than the main game thread, which is doing a lot of game logic.
Coordinator
Oct 30, 2007 at 8:20 AM
Edited Oct 30, 2007 at 8:20 AM
Is there really a need to perform physics calculations much faster than the game loop? Having the physics calculations even 1Hz faster than the game loop would ensure that every game loop has fresh physics information.

Hertz is a simple way of referring to anything per/second, so 60-120 times per second, as Shaw referred to, I would think would be more than enough. I wouldn't expect a complicated scene to always run near 120Hz anyway, the BulletX sample on my Core2Duo 2.0ghz runs down to 25fps with about 100 cylinders falling in the vicinity of each other. I'm fairly certain the even the BulletX alpha is including an algorithm to cull out collisions of objects that aren't nearby.
Oct 30, 2007 at 8:40 AM
Just to be certain, the fps you see on screen is the number of frames which are rendered per second, this shouldn't have anything directly to do with the number of cycles the physics engine is running. Running the physics simulation at the same speed as the main game loop gives you a useable (simple) physics behavior, but won't give you a realistic physics behavior. In order to achieve physics correctness the physics loop has to run much faster than the game loop, though there are some assumptions here
  • The main game loop don't need to update entities faster than the frame rate
  • The game has entities which are moving relatively fast (bullets/cars/etc)
  • The game has entities which can collide (No reason to have physics if nothing interacts)
The slower the physics engine runs the less realistic the behavior seems. One example is that two entities get stuck within each other before the bounce off. For more pricise physics calculations the deltas have to be as small as possible.
Coordinator
Oct 30, 2007 at 2:57 PM
Right, but I don't believe you would notice a difference in physics that updated at 60hz(fps), or more, as the differences in physics would only occur between frames. I actually wrote a tutorial on ray tracing a while back and explain why physics on high speed objects, like bullets, really can't be done accurately without a ray tracing algorithm. For a small bullet to hit a person that was in its path, 100% of the time, the FPS update of the bullet had to be around 1200-1500fps I believe.

For instance, let us say we have a large bullet, around 3 inches long. In our example we have two people standing on a football field, on at the 0-yard line, one at the 50-year line. The bullet, in yards, is 1/12th of a yard, and to travel a yard, in frames, and be able to cover every inch of that yard without leaving a gap, it would need to travel all 12/12ths of that yard, so 12 frames per yard. Turns out with some research I did for my tutorial a bullet will travel the entire football field (100 yards) in 1 second. So we need to travel 100 yards, at 12 frames per yard, in 1 second. 100 * 12 * 1 = 1200. 1200fps to simulate a bullet. Or....ray tracing to the object the bullet will be hitting, then place the bullet at that point, at the calculated speed, and calculate the physics right away for the collision (if a small bullet is going to be factored for collision).
Oct 30, 2007 at 3:50 PM

Sturm wrote:

With simple data types, I'm referring to Vector, Matrix, float, etc. bacially structs, but not limited to, complex types would be Entity. The reason I refer to these as simple is that the operations done on them are often mathemetical, most physics is calculations.


I'm still not understanding why this implies the physics simulator should be able to run way over 120 Hz (simulator loops per second). An Entity would be composed of simple data types. And the solvers are iterative in nature (at least the one's I'm planning on using), so its not like you just do a simple matrix equation to get an "answer".


Sturm wrote:

60-120 hz is usually refered to the fequency in which the game is being run, or rather the refreshrate of the screen being drawn. This shouldn't have anything to do with the game update itself, at least we should bind to the refreshrate for anything (that's soo 80ties). For me this implies that the physics engine will run on it's own CPU at a much higher cycle rate than the main game thread, which is doing a lot of game logic.


The physics engine will be asynchronous, yes, but that doesn't mean it's going to run much faster or slower than the game update. For consistency, the internal physics loop will use fixed-time iterations, whether that is 60 Hz, 75 Hz, 120 Hz, whatever is deemed an appropriate balance between accuracy and performance.


LordIkon wrote:
Is there really a need to perform physics calculations much faster than the game loop? Having the physics calculations even 1Hz faster than the game loop would ensure that every game loop has fresh physics information.


I think the concern is in accuracy. The larger the time-step between frames, the more artifacts you will get in the simulation. The physics simulator is a little different than the graphics system. With graphics, any updates faster than the monitor's refresh rate is pointless. Some may even argue anything over 30 Hz is pointless. That's because no useful work is done in the frames the eye cannot see. In a physics simulator, however, intermediate frames will allow you to reach a more accurate "solution."

For a real example, imagine integrating velocity to get position. Further suppose that the velocity is constantly changing based on environmental factors (collisions, gravity, etc.) such that we have a continuous function v(t). Now we want to find the position at time t1, given the initial state t0 (i.e. t0 is the previous frame, t1 is the next frame. Is it going to be more accurate to integrate v(t) over 10 points between t0 and t1, or 100 points between t0 and t1?

That's why a higher physics update rate is desirable, but rarely feasible. I don't see us being able to get beyond 60-120 Hz, nor do I think we need to.

But, this does not mean that the physics update loop needs to run a lot faster than the game update loop to be reasonably accurate.

As for fast-moving objects, ray-casting is definitely ideal here. There are continuous collision detection techniques that aim to resolve the issue of collision between fast-moving objects that would never be detected by discrete collision detection, but that would be a long way off if I'm the only physics developer.
Oct 30, 2007 at 4:54 PM
Why not just implement a system which will be able to run at available speed or at a set update rate? some systems won't be able to run 60hz while others migh be able run run faster than 120 (Maybe using PhysX)
Oct 30, 2007 at 5:55 PM
Yes, as I mentioned earlier, it will be adjustable.
Oct 30, 2007 at 7:28 PM
We should probably give some thought to how to divide the Xbox CPU among our various components. The Xenon processor is distributed as follows when using XNA:

Hardware Thread    Core    Availability
0                  0       No, reserved for XNA Framework
1                  0       Yes
2                  1       No, reserved for XNA Framework
3                  1       Yes
4                  2       Yes
5                  2       Yes

I forget exactly what the "default" hardware thread for an XNA game process on Xbox is, but it really doesn't matter as you can re-assign it to any hardware thread at start-up. What I'd like to do is partition our work across the 4 hardware threads available to us. In other words, stake your claim to the hardware threads now!

I'd like to run the main Game on thread 1, and start physics on thread 4. I would like to reserve thread 5 for the future parallelization of the physics simulator, but that won't be for awhile. The goal at the moment is to just get it working on a thread separate from the Game thread, then start to parallelize is after it's all working.

So, that leaves thread 3 and (for the moment) thread 5 up for grabs. Any takers? LordIkon's AI processing? Game logic processing? Networking?
Coordinator
Oct 30, 2007 at 7:33 PM
It should be something worth threading, something that would normally put a strain on performace. AI is feasable in certain situations, specifically certain types of pathfinding. Networking has some possibilities.

It also has to be something that is threadable. Anything might be "threadable" when done right, but threading certain things might not present any benefits. I have very little multithreading experience so I don't want to make any claims without researching it first.
Oct 30, 2007 at 7:48 PM
I'm not sure how hardware threads work, but wouldn't splitting the physics to work in threads 4 and 5 give no performance benefit, as they run on the same core?
Oct 30, 2007 at 8:00 PM
It's true that running on two separate cores may give slightly better performance over running on two hardware threads on the same core, all else being equal, but when you're on the same core you can optimize cache access and end up with higher net gain. It's the same concept as Intel's Hyper-Threading processors. It's a little harder to do in the managed world, but I think its doable. Besides, if you throw something unrelated into thread 5 you could end up with a lot of resource contention.

For details, see http://en.wikipedia.org/wiki/Simultaneous_multithreading.
Oct 30, 2007 at 11:15 PM
I think having 4+5 allocated to physics and related logic makes sense, then we should have 1 set for doing game logic / AI and 3 for core engine logic and networking.
Oct 31, 2007 at 12:41 PM
One thing to keep in mind is that the xbox manages threading totally different to windows.. or doesnt manage as the case may be..
on windows you can keep spouting off threads and it will set the most apropriate affinity for you, where as on the xbox it doesnt, you would manually have to choose which affinity to run on before launching the threads. this is also something you wouldnt want to do in windows, so the thread management would be different for windows and xbox
Oct 31, 2007 at 1:25 PM
Yes, also once support for more systems are included for dotNet this might also expand support for Xna. Therefore a ThreadManager will be needed, which will be able to handle threading correct on the platform it was build.
Oct 31, 2007 at 1:37 PM
conkerjoe, yeah that's the whole point of doing this manual assignment. Though in some cases you want to do this on Windows as well. The Windows process scheduler is good, but sometimes it can still help to manually restrict threads to certain processors.

Sturm, that's an interesting thought, but I'm not holding my breath on any .NET/XNA support on other platforms/consoles, at least not officially. It's a Microsoft technology.