Although normalized vectors in FSO are supposed to stay normalized, occasionally small floating point errors can pop up. In most cases these do not cause a problem, but in certain cases these errors can rapidly accumulate and corrupt an otherwise well-behaved matrix. This can most easily be seen with daisy-chained dock sequences or docked ships with angled dockpoints.
This PR audits the usage of `vm_vector_2_matrix_norm` to re-normalize vectors in cases where floating point errors could accumulate. There are also a few new Assertions for extra vigilance.
Follow-up to #6596. Fixes#6634.
Most places in the code that use `vm_vector_2_matrix` do so on already-normalized vectors. Changing these to `vm_vector_2_matrix_norm` avoids redundant normalization.
According to DahBlount:
> Most atan2 implementations for a long time had problems when the inputs were close to machine epsilon or when x was less than or equal to 0
And according to z64555:
> Modern versions of C++ should have an atan2() that works correctly when the inputs are at 0 or near epsilon of the floating point specification, meaning Volition's workaround shouldn't be needed anymore.
So this removes `atan2_safe` and changes all instances to `atan2`. Consequently, the angle range in FRED now shows as [-180, 180] as expected.
Fixes#3730.
* Remove old interpolate angles quick
* Remove old interpolate functions
These are no longer used.
* Add linear interpolate vm function
More clearing functions
* Add physics snapshot struct to silo interpolation
Two of these two functions require an object pointer, so they cannot be in physics_state.cpp
With doxygen documentation
* Try to placate Linux
* Address Feedback
* And update declaration, of course
* Attempt to appease linter
See title. There were some cascade effects, but the changes are mostly contained to the model code. The calls to `gr_render_model` and `g3_render_primitives` use `const_cast` because constifying that API would require a whole other PR.
Adds gravity! Applies on a per-mission basis, and weapons, ships, debris, and asteroids now have a configurable "gravity const" which multiplies the effect of gravity on them, by default everything except debris is 0 (meaning no effect even when the mission has gravity). AI and the lead indicator will also lead for ballistic trajectories as well, given a gravity-affected weapon. No FRED support or gravity direction control yet, to come in later PRs.
Written by Asteroth, derived from our ai code. I added a couple safety checks and changed the type to void to match our library.
Co-Authored-By: Asteroth <[email protected]>
In #4443, `fl_near_zero` was set to use default epsilon values in the `IS_VEC_NULL` check. In this comparison, epsilon is the wrong threshold because it used to have a much smaller threshold. The fix restores the previous definitions of `IS_VEC_NULL` and `IS_VEC_NULL_SQ_SAFE` by exposing the epsilon value as an optional parameter (similar to how `IS_NEAR_ZERO` used to work. This PR also restores `IS_VEC_NULL_SQ_SAFE` where it was replaced by `IS_VEC_NULL.`
* more cleanup in preparation for model translation
1) Clean up stepped rotation, fixing some logic, adding safeguards for invalid values, and allowing rotations to go in the opposite direction
2) Add more specific SEXP error checking for AWACS and rotating subsystems
3) Assorted refactoring and polishing
* address feedback, plus a bit of extra cleanup
* Change animation turret canonicalization to now correctly calculate the closest natual turret positon
* Add angle error to vm function for convenience
* Div by Zero safety for non IEEE compliant systems
* Incorporate style changes
Goober5000