there really aren't any truly deterministic (that is to say deterministic across platforms/architectures/compilers) 3D physics engines out there
... due to floating point calculations, right?
The physics engine would be free to perform its calculations with hardware-accelerated floating point values
So ... you're still going to have the exact same problem.
I think you're misunderstanding something. Nothing you do on the rendering side (or in between rendering and physics) is going to make the physics deterministic. It's not even going to make the rendering deterministic, since the input, the physics, is still non-deterministic.
The physics output would remain non-deterministic, but the point of the conversion buffer class in between the physics calculations and rendering would be to change the non-deterministic floating point values from the physics engine to fixed point values according to a pre-determined rule set (ex. one such rule could apply to the floating point values 53.012345679013455670012 and 53.012345679013455679936, changing the values to fit a Q3.8 fixed point specification such that each value resolves to 53.01234568. A more complicated example might be the values 53.012345679 and 53.012345671 which a more complex custom rounding function would specify should both resolve to 53.01234567 simply for the sake of determinism in Q3.8 fixed point).
That way, even though the physics calculations themselves aren't deterministic the results the user sees in the rendering should be deterministic. Essentially the trade-off is that you would need to give up on some of that sweet physics engine calculation integrity in some cases, but you could (in theory) ensure that what the user sees is deterministic. Also the rendering would be working with fixed point so its performance might not be as good as it could be with floating point on certain architectures, but the calculations the rendering engine needs to perform are generally fairly basic linear algebra (fairly basic at least compared to what the physics engine has to contend with) so I wouldn't expect much trouble from that.
Does that make more sense now?
The second idea I had last night while playing Braid
Just thought I'd throw it out there; I realize it would be impractical for most situations. Still, in conjunction with other strategies it could potentially be of use...
EDIT: naturally, the level of non-determinism of the given physics engine cross-platform/architecture/compiler is important... if the integer portion of a calculated value from the physics engine changes for the exact same scenario across two different platforms then it becomes a whole new ball game. If however the integer portion remains the same and only the fractional bits differ you would only need to impose rounding function rules, which should be do-able. Even in the former case it might be possible to make the buffer class work, but it would require some very clever implementation. How far off do results from Bullet tend to be across different platforms (ex. i7 PC to ARM Android, both with FPU)? Does anybody have a numeric cross-comparison of Bullet's calculated results (not just performance) driving some core physics behaviors [collision, effects of gravity etc.] on different platforms?