Re: PES2010 News & Rumours thread
Thanks Gragra and Drekkard.
But I don't get it. Why do the limbs/ball pass through the body?
I mean if they use the mesh as Gragra mentioned they should not have the bodies passing through each other. Or is this as a result of the animation that is happening that Drekkard mentioned. I saw a video of PES 2010 where the ball passed through a players chest and went to the player behind him. Does that mean that the CPU predetermined that the pass is going to the area behind the player as opposed to the players chest and bounce back onto the pitch?
As I mentioned method a) would measure every vertex on the player's mesh and would simply take too long to compute. So onto Method c)...
Method c)'s low resolution meshes are 6 sided objects each (i.e. cubes and rectangles) linked to bones. Now, they could have all those (albeit invisible) "collision detection cubes" in the game-scene on at render time but that could take away from the overall polygon count. After all at say 6 polygons per collision detection box that could add anywhere up to 200 polys per character if they were being fussy. All the characters would amount to 4600 poly's robbed (22 players plus ref). Tracking 4600 polygons colliding could cripple FPS (Frames Per Second).
So they could do the following:
- have all collision boxes turned off until the ball comes close (say 10 game metres), then turn on the relevant player's collision boxes, do the calculation, let the ball do it's thing, and then once out of that 10 game meteres area turn if off again
- not have the collision boxes in the game (thus freeing up the poly count) but instead use the XYX data (i.e. maths to construct the six sided box) via code and use maths to calculate the "area" of the collision. They would do that by getting the artists to size up an invisible box in a 3D program, and then they would note the XYZ values of the 8 corners of that box and "reconstruct" that area in code when the game runs.
either of these two ways, like Drekkard said, it's CPU intensive and prone to error. If it misses too much calculation (i.e. is not finished by the time it should be) the ball (or other player's collision box) is to have likely already passed through the area it is supposed to be calculating by the CPU to keep the game going (God I hope that made sense).
So I am guessing Drekkard is saying something like:
eg. Game runs at 30fps and collisions are calculated EVERY FRAME so it is checking for collisions 30 times a second.
Frame 21: the ball (in XYZ space) is before a player's chest collision box (so therefore not actually intersecting) it does not know it has hit it.
Frame 22: the ball has intersected, so the CPU is now calculating what to do.
Frame 23: the outcome is calculated and the ball is thrown off in a certain direction.
So why does it fail and a ball goes straight through? The ball was too fast... for the collision detection.
"But the ball wasn't travelling that damn fast!" I hear you say.
IF it's checking EVERY FRAME, surely you would expect 100% accuracy - BUT it would likely cripple FPS/Performance of the game. They may opt to check every 2nd, 3rd or even 4th frame... So then it's checking frame 20, then Frame 24 in a worst case scenario.
The Ball's already come and gone in that case... and at a 25% accuracy! (1/4 frames checked). Like Dekkard said, they may use the CPU to roughly try to interpolate ("fill in the blanks") and that would no doubt result in some particularities/bugs/weirdness.
So you can see they have to balance resources of the CPU... pumping up every accuracy setting etc would be great but I doubt the game would run well. They have to compromise somewhere.
Next time you see someone make a comment like "Frame-rate chugging? Must be the graphics" then you can say: "Well - actually the CPU is kinda busy with code too". Although the code maybe written litely (so not take up to much kb/Mb in RAM), the calculations produced by the CPU can be stratospheric.