Animation is an illusion of motion caused by a sequence of still images. The way a physics engine works is by computing those still images -- the frames -- for each iteration in a mathematical model (the physics you want.)
If you want 60 frames per second for a smooth animation, you have to compute the whole frame less than 1/60th of a second. The more complicated your physics model is, the harder it is to do this.
>I just wonder why AAA games use pretty much the same math? Are there no better math?
The math they use is just standard physics, often using some simplifications or optimizations to speed up the calculation. "Better math" is a curious term. If you want more accuracy, you have to give up speed. You can't have both. You either get jittery/jerky motion or you get unrealistic effects. Of course, running on a faster machine or finding a better optimization will help, but that also requires a ton of expertise and is sometimes plain infeasible.
>I mean CAD systems obviously do something better... Is that the same thing as with drawing triangles vs. raytracing?
CAD systems with physics engines do the same thing as above, and they have to make the same kinds of decisions. Usually, CAD software is meant for design, so it would opt for higher precision. This isn't suitable for games except on very high-end machines, which would exclude a lot of people from buying your game.
As for ray tracing vs rasterization: Yes, it is the same kind of trade-off. Ray tracing can be made very accurate and do some amazing things, but the frame rate is usually so low that you have to pre-render the whole animation beforehand. That is, if you want high quality.
Rasterization gives medium-low quality at very high framerates. It is very common because it is 'good enough looking' for most purposes, where an equivalent quality ray tracer would be very slow. Of course, a physics engine is independent of your rendering method: you will have to compute physics for your scene whether you use ray tracing or rasterization, so you have to take both into account for determining how jittery your animation will look.
The math is not just standard physics. That undermines the essences of the difficulties of doing physical simulations. Many of the design choices have to do with numerics, discretization of time, collision detection, etc.
Physics doesn't concern itself, for example, with how to represent polyhedral shapes, or how to compute their intersections. In the world of computer simulation, there are surely more algorithmic developments to be made. Even if the physics hasn't changed (much) for the last 300 years, there are new ways to precondition systems, and solve them, and so on. I think that's what is meant by "better math".
I think you make a good point about the trade-off difference between CAD and games. In addition to requiring that games be simulated in real-time, you also want the simulation to be causal. In a CAD tool, you can take advantage of being able to do "multiple passes" through time to refine your simulation. In a game, once you've computed the quantities pertinent to a frame, you don't get to go back and recompute those quantities and present them.
> "Better math" is a curious term. If you want more accuracy, you have to give up speed.
What I mean is for example to integrate something numerically you can just add small increments but this will lead often to crap unstable solutions. Or you can use Runge-Kutta and get very accurate stable result.
If you want 60 frames per second for a smooth animation, you have to compute the whole frame less than 1/60th of a second. The more complicated your physics model is, the harder it is to do this.
>I just wonder why AAA games use pretty much the same math? Are there no better math?
The math they use is just standard physics, often using some simplifications or optimizations to speed up the calculation. "Better math" is a curious term. If you want more accuracy, you have to give up speed. You can't have both. You either get jittery/jerky motion or you get unrealistic effects. Of course, running on a faster machine or finding a better optimization will help, but that also requires a ton of expertise and is sometimes plain infeasible.
>I mean CAD systems obviously do something better... Is that the same thing as with drawing triangles vs. raytracing?
CAD systems with physics engines do the same thing as above, and they have to make the same kinds of decisions. Usually, CAD software is meant for design, so it would opt for higher precision. This isn't suitable for games except on very high-end machines, which would exclude a lot of people from buying your game.
As for ray tracing vs rasterization: Yes, it is the same kind of trade-off. Ray tracing can be made very accurate and do some amazing things, but the frame rate is usually so low that you have to pre-render the whole animation beforehand. That is, if you want high quality.
Rasterization gives medium-low quality at very high framerates. It is very common because it is 'good enough looking' for most purposes, where an equivalent quality ray tracer would be very slow. Of course, a physics engine is independent of your rendering method: you will have to compute physics for your scene whether you use ray tracing or rasterization, so you have to take both into account for determining how jittery your animation will look.