The range of the function is targeting (-180, 180] such that
the statement:
if (degrees < -180)
should be:
if (degrees <= -180)
to account for degrees being -180.
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
SelectionManager was being referred to as selectionManager.
* eslint pass used .eslintrc.js
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
* This should reduces the noise for the eslint passes on this script.
* eslint pass using .eslintrc.js
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
* Also adds some paren grouping to help with readability of some statements.
* eslint pass on script using .eslintrc.js
Changes to be committed:
modified: scripts/system/libraries/entitySelectionTool.js
z:z appears to have been a typo, as there's no var z. Should likely be z:1.
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
* isActiveTool now respects null and undefined args.
* If null or undefined toolHandle is passed, activeTool
is directly tested against those values. Rather than
explicitly returning false.
* Added some clarification to unknown tool warning message.
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
Fixes issue with light selection actions having inconsistent ui
in comparison to other selections from an earlier commit change.
As of this commit:
* When translating point lights, the edge grabbers are no longer be visible.
* When rotating or translating spot lights, the edge grabbers are no longer visible.
Note:
* For both point & spot lights, when translating and/or rotating, their circle
and/or radial guides should remain visible. This commit shouldn't have any
influence on that behavior.
Tested:
* Rotating and translating spot lights.
* Translating point lights. Didn't test rotation as only spot
lights support rotation.
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
This var isn't needed as the var essentially piggy backed
off of activeTool and activeTool.mode.
This also helps guard against the _majority_ of situations
where mode check fails due to typo inserted when composing
the check.
Most instances of manual string checks have been replaced by
querying activeTool via new isActiveTool function. For instances
that still require a direct mode check getMode will return
the mode string associated with the current activeTool.
TODO: Get this code reviewed.
It was down below the amidst the mouse event handlers. This just moves
it up with the other that.update handle functions definitions.
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
Ran lint pass and found the dupe define.
As noted in a previous commit, the only remaining lint
issues are as follows:
* 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
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
Fixes issue where when translating the selected object(s),
user view was obstructed by grabber handles.
This also brings more consistency to the selection ui state between
rotation and translation user interactions. Both types
of interactions feel nicer with the selection ui as concise
as possible during the action, limited only to that useful for
the current interaction.
Expected Behavior:
Note the following presumes you're in creation mode.
* When the selection is clicked, the rotation, stretch, clone,
and translateY handles should turn invisible.
* When moving a selection along either the x or z axis, the
rotation, stretch, clone, and translateY handles should be
invisible and remain that way until the user releases the selection.
* When the selection is released, the rotation, stretch, clone,
and translateY handles should become visible.
* When the translateY handle is clicked, the rotation, stretch, and
clone handles should turn invisible. The translateY handle should
remain visible.
* When moving the selection along the y axis, the rotation, stretch,
and clone handles should be invisible and remain that way until the
user releases the selection. The translateY handle should be visible
during the entire interaction.
* When the selection is released, the rotation, stretch, clone should
become visible. The translateY handle, visible the entire time, should
already be visible.
* When the user click somewhere other than a selection, entity object,
creation menu or tools, then any current selection should be
unselected and all creation ui local to it should turn invisible.
* When the user exits creation mode, any current selection should be
unselected and all creation ui local to it should turn invisible.
TODO:
* We may want to visit the scaling interaction ui as well; however,
that could be a later task as it's tangential. The changes here
are a good first step.
* The idea with that interaction is perhaps only showing the
handle for the current scaling operation. Currently when
scaling all of the other handles remain visible, though
their appearance does update.
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
* Added some wantDebug guards to print sections without them.
* Normalized error logging statements to have script name
and/or specific script function where reasonable.
* All error statements contain at least the script name
and a descriptive snippet of the error or clue to resolve it.
* Removed some stale todos.
Reviewed-by: Leander Hasty <leander@1stplayable.com>
Changes Committed:
modified: scripts/system/libraries/entitySelectionTool.js
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
