The logical structure you would need to model this would be scene graph represented as an octree, used in high performance game engines.
O wait, clarify what you do not get. Inertia across time? The idea and supposition that there are in fact future frames? MDT? Sum of all "da photons" where expanding frames insect that at space time coordinate equal the mass of the object? I'm not a teacher, I can barely read phd. You should ask them about mdt. I'm just a programmer that is trying get realistic simulations without bogging down my GPU.
Each instance of the rock in each future frame is somewhere. Unto you move it. You simply simulate the future with a scenegraph and output position, velocity, and mass for each future frame for some frequency of frames. Note that e=mc squared is applicable to the objects both in each frame and for all the frames in the set.
Run your numbers for confirmation. Play with the geometric relations and physical properties between instances off object you are observing.
I did it with discreet coordinates the math for continuous coordinates is beyond my skill set.
It should lead you to the same sort of optimization I found.
A hint might be "include a r component in you object representing energy state". Where the object is in the lowest resolution node in your tree.
Imagine the player whipping his mouse to the right. Use this r component as "energy level" and when you whip to the right, I increase camera r proportionally.
High r yields a motion blur coefficient that is...useful.
Effectively moves the origin node of your player up to a higher level in the tree. That way objects that are close to the viewer blur without me having to interpolate the key frame animations at too high a frequency. The same thing apples to a meteor streaking across the sky. It's so far away in the scene graph, you simply cannot afford to update the physics on it more than once per second.
The r component allows you to update its physics once per second, effectively sorting it closer to the viewer so you draw it 33/sec and use the extra calcs for something else.
I know. But motion blur is tough.