You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've focused my attention with RelativisticAudioSource position, delayed by the sound of sound, on inertial objects. The simulation doesn't respect the relativistic rocket equation for quasi-Newtonian world gravity, and it will likely linearly interpolate background curvature co-motion toward collision points where co-motion itself will generally not be linear. Also, multiple rapid collisions will interpolate toward the last point of velocity change, not through the segmented path of multiple collisions.
For video game purposes, the typical use cases seem acceptable. I don't put as much emphasis on this as on collider tracking, in part because the accuracy of the sound position has 0 effect on the accuracy of RelativisticObject PhysX collision trajectory. However, there are known issues.
It might make sense to return to this known and accepted set of limitations and approximations at some point. I'm opening this issue ticket to keep this in mind, but I'm tagging this "won't fix" for the time being.
The text was updated successfully, but these errors were encountered:
I've focused my attention with RelativisticAudioSource position, delayed by the sound of sound, on inertial objects. The simulation doesn't respect the relativistic rocket equation for quasi-Newtonian world gravity, and it will likely linearly interpolate background curvature co-motion toward collision points where co-motion itself will generally not be linear. Also, multiple rapid collisions will interpolate toward the last point of velocity change, not through the segmented path of multiple collisions.
For video game purposes, the typical use cases seem acceptable. I don't put as much emphasis on this as on collider tracking, in part because the accuracy of the sound position has 0 effect on the accuracy of RelativisticObject PhysX collision trajectory. However, there are known issues.
It might make sense to return to this known and accepted set of limitations and approximations at some point. I'm opening this issue ticket to keep this in mind, but I'm tagging this "won't fix" for the time being.
The text was updated successfully, but these errors were encountered: