Examples: Use epsilon for zoomChanged comparison in OrbitControls

[SimonFH]

Description

zoomChanged was set using strict inequality, which could trigger unnecessary updates due to floating point precision errors. Instead, use an epsilon threshold to determine significant changes

[gkjohnson]

I'll have to check the history later but if I recall correctly the event used to behave like this (or something similar) and it led to the camera changing subtly but without an event which can cause issues if work is being done based on the camera position. The "subtle difference" can also be more noticeable depending on the camera near plane is and how close the camera is to a surface.

My feeling is that the camera shouldn't move (or zoom) if no event is fired.

edit

See #27831, which seemed to address some issues relating to epsilon and inconsistent change updates, and #27620 - there have been some other work in this area but it's known that this is a problem and maybe has never actually been fixed. It would nice to have this addressed at some point so that the controls do not move without firing change events.

[sciecode]

My feeling is that the camera shouldn't move (or zoom) if no event is fired.

I agree with this assessment.

It's not recommended to entirely remove EPS, because of floating-point precision issues that naturally arise, particularly when damping is enabled. Which would lead to change events firing way too frequently.

However, we could reevaluate the comparisons against EPS, and adjust appropriate scaling factors for each condition as to not lead to jerkiness (particularly for zoom and damped orbit), but also prevent these changes from affecting the camera if the conditions are not met.

see #31545 (comment)

[Mugen87]

So...how should we proceed with this PR? AFAICS this change makes the zoom check more consistent with other ones where epsilon is used as well. The mentioned reevaluation is probably something out of scope of this PR.

[sciecode]

The PR in its current form is incomplete, as it doesn't even handle all cases zoomChanged is checked. So it would fail when used with orthographic camera, and both perspective and orthographic cameras when zoomToCursor is enabled.

Besides that, even if we did adjust all the missing cases. Simply comparing zoom differences to EPS would make the issues in #27831 be present again. Zoom is particularly sensitive to changes, due to a variety of reasons, but the worst cases are pinch/drag gestures in certain trackpads (e.g. macbooks). As they have a built-in damp which dispatches multiple really small deltas instead of incrementally smaller ones.

I believe a well-tested PR addressing the appropriate scaling factors for each change is warranted here.
I can give it a go this next weekend.