The functions derived from `vm_vec_mag_quick` run *slower* than `vm_vec_mag`, according to @Baezon who did some testing. So this PR makes all calls to the _quick functions use their more accurate counterparts.
A few early on descriptions in this file are inconsistent or even plain wrong. This should correct that.
Also, rename vm_vec_imag() to vm_vec_inv_mag_quick() to better describe what it is.
It turns out that `angles_2_matrix ` would return a pitch value that was not the actual pitch from the 3x3 matrix. The pitch line in the code is uses a modifed `cosp` as the demoninator to calculate the pitch angle. I looked up online what the caclulation should be and found a more accurate way than using the modifed cosp, is to use ( fvec.xyz.x^2 + fvec.xyz.z^2 )^0.5 I tested using the new calculation throughouly and in each test it returned the proper pitch value from the 3x3 orientation matrix.
This allows to render screen space decals into the deferred lighting
buffers no matter how complex the underlying geometry is.
Currently there is only limited support for using this in the engine.
Only weapon impact decals are supported at the moment for testing
purposes.
This uses UBOs for building a buffer object of uniform data before
using that data to draw objects. This should reduce the CPU overhead by
reducing the amount of glUniform calls required for executing a single
draw call. This is especially useful if rendering is limited by the CPU
which should help performance for people with slower CPUs.
This fixes#910.
Fixes a subtle problem with vm_test_parallel() wherein a relative error
was accidentally converted into an absolute error.
Instead of comparing the result of the cross product to the zero vector,
the two calculated components of the cross product are compared against
each other. This permits vectors whose cross product is a large number
but whose cross product partials are within relative error of each other
to be treated as parallel.
For example, the following two vectors may now be considered as parallel
whereas before they were not:
v1 = (1000004.0, 1.0, 1.0)
v2 = (1000000.0, 1.0, 1.0)
The relative difference between them is sufficiently small according to
vm_vec_equal() for them to be considered equal, but their cross product
would have elements whose magnitudes would be near 4.0 which would
otherwise indicate that they are not parallel. By comparing the partials
instead, a higher degree of consistency is maintained.
Signed-off-by: Peter Mitsis <[email protected]>
vm_vector_2_matrix was improperly guarded against bad parameters. In the
case I encountered the uvec was the negative of fvec which produced a
null vector when the cross product of the two vector was constructed.
These changes should fix that bug by ignoring the uvec parameter. Since
vm_vector_2_matrix and vm_vector_2_matrix_norm are basically the same, I
converted the former into an alias of the latter and only fixed that
code.
The routine vm_vec_normalize_quick_mag() did not normalize a vector.
Instead of dividing the vector by the 'quick magnitude', it multiplied
it. This routine was only called by one other routine (which was
fortunately unused)--vm_vec_normalized_dir_quick_mag().
Given both the incorrect behavior as well as their lack of use, those
routines have been removed.
Signed-off-by: Peter Mitsis <[email protected]>
Uses fl_abs() (which evaluates to fabsf()) instead of an if-else
statement to get the absolute value of a float. A compiler for the
x86 platform is able use SSE instructions to optimize calls to fabsf().
Signed-off-by: Peter Mitsis <[email protected]>
Goober5000