That would be superfluous.

The physics engine has nothing to do with rendering and should not prepare any information for the renderer. Any information passed between physics and rendering is intermediate. In other words the fact that there is a current and previous transform for interpolation is only because a layer was injected into the system specifically to bind physics and rendering together. Otherwise they would and should be entirely completely unrelated systems.


The physics system prepares only date related to physics, which in this case means the current transform of each object.
An intermediate layer stores the current transform into to the “lastTransform” for an object on each physical update.
And finally the renderer is run each frame using the above transforms with a time value to interpolate between them. The time value and the interpolation process are repeated for each frame. No information from the physics is prepared except for what the physics itself does: The current transform.


L. Spiro

I have one last simple question, and I believe I know the answer. I assume the safest way to handle passing the data from Physics to Rendering would be all at once in a structure. For example, have a PhysicsFrame class that holds the ObjectID, its transformation, and the Matrix of every changed object in the physics frame. Then pass that to the Renderer, and have it apply the percentage of interpolation between the new matrix and the old matrix per object. Does that make sense?

I'm afraid not.
First, [font=courier new,courier,monospace]objectID [/font]or ids in general are typically unnecessary. We have far better tools which are pointers. Personally, I'm against most uses of IDs.
For Bullet, object transform is just poured out to the external code by using a proper interface. That is, if it's good enough for Bullet, I guess it will be good enough for you as well.