FR: Vector3D: Add operator==/!=

Feature Requests
1

See title - it’s a very simple FR!

2

Comparing floating point values to each other is potentially problematic, and so == and != on a Vector3D will also be problematic. It would only be suitable for specific cases such as comparing to (0, 0, 0).

3

It’s a perfectly valid request in my experience. Besides, this is why JUCE provides exactlyEqual and approximatelyEqual. Treating floating points vals like some untouchable, museum piece isn’t a good idea.

I’d rather this than have to consume glm and use vec3.

4

Which would mean, rather than implementing the operators juce would implement overloads for

template<typename FloatType>
bool approximatelyEqual (
    const juce::Vector3D<FloatType>& a, 
    const juce::Vector3D<FloatType>& b)
{
    return approximatelyEqual (a.x, b.x)
        && approximatelyEqual (a.y, b.y)
        && approximatelyEqual (a.z, b.z);
}

And the same for exactlyEqual.

It’s up for discussion, if implementing the operator calling approximatelyEqual is wise or not.

5

Or check if the difference vector has almost a zero norm (withlengthIsBelowEpsilon)?

6

I was thinking about that, but I would think calculating the norm is slightly more expensive than just comparing the components. Not to mention of numerical errors when multiplying and taking the square root.

1 Like
7

I think we’re overcomplicating this.

operator==/!= can just be component-wise exact equality - useful for sentinels/tests/known-constructed values, and somewhat consistent with other JUCE geometry types that already have ==/!= (Point<>, Rectangle<>).

For float-tolerant comparisons, make it explicit: Unity does exactly this split where Equals is exact, and == is approximate because floats. Unreal also defines vector equality as component-wise via ==/!=. And any game engines or apps using glm::vec3 are subjected to this implementation: glm/glm/detail/type_vec3.inl at e7970a8b26732f1b0df9690f7180546f8c30e48e · g-truc/glm · GitHub .

Vector3D being the odd one out (especially in the OpenGL module) is just friction.