how do you know the physics is about what happens between the frames?
Because I read about it. There are essentially two forms of collision detection: discrete and continuous. Discrete detection only catches collisions that happen at each physics frame. Continuous catches collisions between physics frames.
Example: Catching the bullet. Say that you fire a machine gun at somebody's hand in a game like GTA. For collision purposes the hand is 0.05 m thick while the bullets are 0.02 m long. The bullets travel at 1000 m/s.
With discrete collision detection, most bullets would miss the hand, as they in frame 0 would be in front of the hand and in frame 1 behind the hand. In neither case the bullet would be touching the hand.
Even at 1000 fps (which is really expensive if you're going to calculate collision detection in each of these frames) the probability to hit the hand is 0.07, which is like 1 hit for every 14 bullets that you fire, assuming that you adjust your position between each shot - if not then odds are 13:1 that all bullets would miss.
With continuous collision detection, every single bullet would hit even at a frame rate of 1 per year.
Let's go back to the curbs. What triggers the rumble? Is it the wheel being ON the curb, or is it the wheel travelling over the edge of the curb? I think that we can agree that it's the edge, right? Now, what is the length of the edge along the dimension of which the car is travelling? Not more than a centimeter or two, right? How long (in the same dimension) is the contact patch of the tyre? Let's say 10 cm. If the car is travelling at 30 m/s, then the tyre would be in contact with each edge for (0.1+0.02)/30 = 0.004 seconds. That is 1/250th of a second. At 60 fps you'd be able to cath a little less than every fourth edge on average. Unless you happen to time the speed and the dimensions of the curbs so that for each frame the tyre is right between two edges, in which case you wouldn't feel a thing.
With discrete collision detection, that is. With continuous detection you'd get a rumble every time you drive over a curb.
How do you know how fast any physics engine is running at?
Any physics engine? Well, in Blender I can check the physics settings. What is your method?
Are you doing debugging on the PS4?
Why would I debug the console, and what has that got to do with anything?
How do you know they aren't calculating a few iterations of the physics every frame using physics substepping?
I don't and I never said that they aren't. I responded to a hypothetical situation where it was assumed that the physics are tied to the framerate (which they may or may not be). The questions were: 1. Is the physics the reason why you pick a certain frame rate? 2. Would 60 fps be better than 30 fps for the physics?
And the situation I was trying to illustrate was; if there is a frame with a wheel on the kerb, at least you have a chance to see it, if there was no frame, you are just imagining what's happening in the gaps between frames and you might imagine something different to what the PS4 calculates.
You can't see a single frame at 60 fps. All you see is that the motions are more smooth.
BTW since 600hz was mentioned (I'm assuming as a reference to Project Cars) I had a read up about that, here's the explanation directly from the developer:
http://forum.projectcarsgame.com/showthread.php?26370-Project-CARS-On-AMD-GPUs-Clarification
So actually yes, in this case the Collision Physics (50hz) is being calculated less often that the screen refresh (60hz), so the car probably does appear to go through that wall if it's rendered before the Physics realise it has collided.
Sure, but does the physics treat the collision as if it happened on the frame, or does it calculate the actual time and point of impact?
ah well... it gives me something to plug away at later 👍
, is the glare and sun effects as distracting as it looks in the video, or are youtube compression artefacts making it look worse than it actually is?
