cpml
cpml copied to clipboard
(breaking) vec3: Rename angle_to -> angle_between
In vec2, angle_to is signed and angle_between is unsigned. We only have the unsigned version in vec3, so use the corresponding name.
Remove the vec3 implementation from vec2 and use vec2's style implementation. It doesn't allocate new vectors and works even if you somehow call vec3.angle_between(vec2(), vec2()).
Nice.
vec3.angle_to has a bug for same vec3. v3.angle_to(v3)
will return nan
use acos(a:dot(b) / (a:len() * b:len()))
will fix it, so, could you add a testing case for this?
assert.is.equal(angle_between(a, a), '0.00')
acos(a:dot(b) / (a:len() * b:len()))
also has this bug when a:len() * b:len() is zero or lua5.4, we should check a == b
.
@xiejiangzhi I guess you mean the old code that I removed had that bug? I can add that test and ensure it passes: assert.is.equal(angle_between(a, a), '0.00')
when a:len() * b:len() is zero or lua5.4, we should check a == b.
I don't think angle_between should check for zero length vectors. At this low level, the user should be required to pass in valid inputs. There are very few asserts here and cpml doesn't have a way to strip asserts in production builds. Also, we have no correct result for angle_between(vec2.zero, vec2.zero)
? I can update the doc comment to explain this restriction.
(Also not sure how lua5.4 changes anything?)
0 / 0 and acos(v) v > 1 will get nan.
maybe same case make v > 1 in mycode.
I found that in some cases abs(a:dot(b))
greater than abs(a:len() * b:len())
I think it's because of floating point issues, a == b
or a == -b
Updated doc to mention nonzero inputs. Added test for angle_between(a,a) == 0.
I think handling abs(a:dot(b)) > abs(a:len() * b:len())
should be done in a separate PR since it'd also move clamp
to _private_util.
@shakesoda How does it look?