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>
