mirror of
https://github.com/HifiExperiments/overte.git
synced 2025-05-07 08:08:35 +02:00
fa74fbc986
Previously, when rotating, it would be easy to achieve 1 degree granularity, except near the 0 degree and 180 degree "poles", where it would often e.g. jump from 10 to -10, or 174 to -175, or similar.
yawZero/pitchZero/rollZero were all based on the yawHandle/pitchHandle/rollHandle ray intersection, and were not necessarily coplanar with rotateOverlayTarget. As a result, centerToZero didn't lie on the expected plane, while centerToIntersect did. This had the effect of distorting the rotation range.
We also have a possible issue in here with editOverlay(rotationOverlayTarget,{rotation:...}) not taking effect immediately. Better to take the existing ray and cast against a known plane, as e.g. translateXZTool and such do. No risk of stale rotation in that case.
This also cleans up rotationHelper args a bit to avoid some string switches and keep flow a little more readable.
TODO: propagate ray-plane test to helperRotationHandleOnMove rather than relying on ray hit location; normalize onBegin/onMove/etc across all tools to take queryRay and results args to avoid recreating the ray.
Reviewed-by: LaShonda Hopper <lashonda@1stplayable.com>
|
||
|---|---|---|
| .. | ||
| accountUtils.js | ||
| cloneEntityUtils.js | ||
| controllerDispatcherUtils.js | ||
| controllers.js | ||
| dataViewHelpers.js | ||
| entityCameraTool.js | ||
| entityIconOverlayManager.js | ||
| entityList.js | ||
| entitySelectionTool.js | ||
| globals.js | ||
| gridTool.js | ||
| overlayUtils.js | ||
| progressDialog.js | ||
| soundArray.js | ||
| stringHelpers.js | ||
| toolBars.js | ||
| ToolTip.js | ||
| touchEventUtils.js | ||
| Trigger.js | ||
| utils.js | ||
| WebTablet.js | ||
| Xform.js | ||