Rotation tools' onMove methods now use rayPlaneIntersection rather than using the giant invisible rotateOverlayTarget. It can likely be entirely removed in the next commit.
tool.onBegin's signature is now (event, pickRay, pickResult, ...) -- this allows us to avoid recomputing the ray or intersection when unnecessary.
translateXZTool is now a part of the grabberTools array; addGrabberTool and addStretchTool have been modified to return the tool reference (and not disassemble and reassemble the tools, so they can keep their own local functions and state). This does make the array potentially less type-uniform, which may (?) undo some javascript optimizations, but allows us to eventually remove some state -- and they're only 1x/frame methods.
We now compute rotationNormal in rotation tool onBegin, rather than having many different normals lying around.
Merged the final branches in mousePressEvent.
Also fixed issue with mode TRANSLATE_XZ test within updateRotationHandles.
Reviewed-by: LaShonda Hopper <lashonda@1stplayable.com>
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>
Fixes situations where attempting to click on a rotate, grab,
or scale handle that was in front of others might unexpectedly
activate the obscured handle.
As of this commit the flow of mousePressEvent such that the
first item whether it be a tool or selection is what reacts
and absorbs the click/touch. This is counter to the prior
behavior where whichever item or tool last passed the check
would determine what was hit and handled the touch _even_
when it wasn't the first thing to be touched.
* Got rid of some unused/stale vars
* Added some convenience functions
* setRotationHandlesVisible function
* setStretchHandlesVisible function
* setGrabberMoveUpVisible function
* Removed checkIntersectWith helper functions as they're
no longer used.
* Normalized onBegin signatures for all GrabberTools to
support the new flow within mousePressEvent.
* These are tools registered via addGrabberTool/makeStretchTool.
* The onBegin signature changes from onBegin( event ) to
onBegin( event, intersectResult ).
* This allows for a simpler tool triggering where tools which
utilized the additional information provided will have it,
those which may need it the future shall have it with little
issue, and those that don't care may ignore it.
NOTE(s):
* Tested normal movement within opening creation menu: Passed
* With Creation Menu Open:
* Tested clicking around the world in empty space: Passed
* Tested single selection: Passed
* Tested single selection rotation (pitch, yaw, roll): Passed
* Tested single selection translation (xz, y): Passed
* Tested multiple selection: Passed
* Tested multiple selection rotation (pitch, yaw, roll): Passed
* Tested multiple selection translation (xz, y): Passed
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
Pulled the common code shared between the rotation handle
tools out into helper funcs:
* helperRotationHandleOnBegin
* helperRotationHandleOnMove
* helperRotationHandleOnEnd
These functions either take in or derive the necessary info
needed to handle a specific rotation axis.
NOTE(s):
* Tested yaw, pitch, & roll handles using a box. The behavior
remained consistent with that prior to this commit.
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
This wraps the selections rotation update handling into common helper
function utilized by all rotation handle tools (yaw,pitch,roll).
This function is the generalized fix previously exclusive to yawHandle.
This functions is now called within onMove for yaw, pitch, & rollHandle
tools.
NOTE(s):
* Tested yaw, pitch, & roll rotation didn't see any aberrant behavior.
** Tested overlapping shapes and selecting the overlapping portions followed
by a rotation handle. Only one took hold as a selection.
** Tested multiple selection and objects rotated & repositioned about the
encapsulating bounding box's center point as expected.
* Tested translation with multiple items selected and it behaved as
expected.
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
* Removes unregister tools switch which was never reached.
* Rolls all code rotation handle related code within mousePressEvent
to the respective rotation handler onBegin functions.
* onBegin call site updated accordingly to provide intersection
data that code depends upon.
* Moves all translateXZTool code explicitly within mousePressEvent
to the tool's onBegin function.
* onBegin signature updated accordingly to provide intersect
results that the tool relies upon.
* Found and fixed a bug with translateXZTool
where its startingElevation and startingDistance properties
were _only_ set when local _debug_ var was set.
* This appears to have been responsible for being able
to move the object farther than was visible. Re-tested
with fix and wasn't able to get that behavior any longer.
* Wrap intersect tests within more reader friendly functions.
NOTE(s):
* Tested GrabberMoveUp and Rotation Handles. They work as they
did previously as expected.
* Tested selection behavior and it currently maintains as expected.
* Tested translationXZTool and it maintains its prior behavior with
the improvement noted above.
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
This fixes the issue where grabbers would re-appear when rotating
the selected object rather than staying hidden.
updateHandles will now take the mode into account when deciding
if the non-light grabber handles should be visible. This can be
subverted by the user selecting a light source as in line with
the previous behavior.
Adds some debug prints in event handlers guarded by local
wantDebug checks.
Has some minor cleanup changes:
* Remove unused var within updateRotationHandles
* Readability improvement for light check within updateHandles
* Pulled up rotate mode check within updateHandles
* Added grabberCloner visibility flag within updateHandles
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
Prior Issue Count: 35
Current Issue Count: 3
Resolved:
* 17 used out of scope issues.
* 11 already defined issues.
* 2 missing semicolon issues.
* 1 implicit comparison against null issue.
* 1 readability warning.
Remaining Issues as of this commit:
* scripts/system/libraries/entitySelectionTool.js: line 17, col 1, Read only.
** HIFI_PUBLIC_BUCKET assignment
* scripts/system/libraries/entitySelectionTool.js: line 19, col 1, Read only.
** SPACE_WORLD assignment
* scripts/system/libraries/entitySelectionTool.js: line 30, col 1, Read only.
** SelectionManager assignment
One notable item was a chunk of code from makeStretchTool's onMove
function which wasn't in scope of the vars being utilized.
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
We're seeing the ignoreRayIntersection flag not take effect before findRayIntersection calls. This may be due to editOverlay and editOverlays becoming non-blocking in 1f7d2b2 .
This altered the flow in mousePressEvent significantly; the first block, intended to handle scale/clone only, started handling rotation (should have been second block) and sometimes selection (should have been third block).
Similarly, in the various rotate grabbers' onMove methods, the pickRay will no longer intersect anything other than rotateOverlayTarget; this avoids some awful behavior when scrubbing over the size and clone grabbers.
This also reverts unnecessary parts of the prior commits to keep the diff for this WL cleaner, and adds a few TODO comments to revisit about redundant statements and incorrect names.
In addition, we've noticed but not fixed herein:
* There is a minor edgecase near 0 and 180, where it's difficult to get within a degree or two of the poles occasionally.
* The scale/clone grabbers don't stay disappeared for rotation in some cases. This doesn't impact usability anymore, but it'd be nice to determine why they come back when they hide briefly.
* The addGrabbers for yaw/pitch/roll could be deduplicated, and yaw has some multiselect "reposition" enable/disable logic that pitch and roll lack.
Reviewed-by: LaShonda Hopper <lashonda@1stplayable.com>
hifi: #21216 - Resize entities with hand controllers while editing
Modified StretchTool to allow for movement in 3D
- uses data from motion controller (position and rotation) to
stretch/resize the entities/primitives in 3D.
- the range of the resize depends on distance to the object.
