mirror of
https://github.com/overte-org/overte.git
synced 2025-05-05 08:22:48 +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>
|
||
|---|---|---|
| .. | ||
| assets | ||
| commerce | ||
| controllers | ||
| html | ||
| libraries | ||
| marketplaces | ||
| particle_explorer | ||
| tablet-ui | ||
| attachedEntitiesManager.js | ||
| audio.js | ||
| audioMuteOverlay.js | ||
| audioScope.js | ||
| avatarFinderBeacon.js | ||
| away.js | ||
| bubble.js | ||
| chat.js | ||
| dialTone.js | ||
| directory.js | ||
| edit.js | ||
| fingerPaint.js | ||
| firstPersonHMD.js | ||
| generalSettings.js | ||
| goto.js | ||
| help.js | ||
| hmd.js | ||
| makeUserConnection.js | ||
| menu.js | ||
| mod.js | ||
| nameTag.js | ||
| notifications.js | ||
| pal.js | ||
| progress.js | ||
| snapshot.js | ||
| tablet-goto.js | ||
| tablet-users.js | ||
| voxels.js | ||