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.
The algorithm used to detect when and where the stylus or finger is touching the tablet has been improved.
* hovering the finger/stylus over the surface of the tablet should cause buttons to highlight.
* flicking or using the stylus like a drum stick, should more accurately click buttons on the tablet.
* stabbing the tablet quickly, should also more accurately trigger button presses.
* moving the hand/stylus from behind the tablet should be less likely to cause press events.
The tablet should more constantly be placed above your hand, while facing your head.
It fixes the issue where the tablet would appear almost horizontal when your hand was close to your HMD and at eye level.
One for the tablet in HMD mode, one for desktop mode.
The default desktop mode scaling factor is now 75%, which should
reduce the size of the for users with low resolution monitors,
while still being somewhat readable.
handControllerGrab.js and WebTablet.js now parents objects to the
AVATAR_SELF_ID parentID, instead of using MyAvatar.sessionUUID, which
is unavailable when not connected to any domain.
I removed several early returns handControllerGrab.js that prevented
grabbing from working if MyAvatar.sessionUUID was invalid.
There were places in the EntityItem.cpp and EntityScriptingInterface.cpp
C++ that would log an error if parentID was set to AVATAR_SELF_ID.
This was to prevent AVATAR_SELF_ID from ever going over the network.
Instead, we now prevent this by replacing all outgoing references of
AVATAR_SELF_ID with the sessionID of the current node.
This introduces the "isAA" property to 3d overlays. When false, the overlay is rendered after
the "Antialiasing" render pass. Ironically, disabling FXAA makes the text more readable, which is
essential in 2D desktop mode.
Two new shaders were introduced.
simple_opaque_web_browser_overlay.slf
simple_transparent_web_browser_overlay.slf
These are tailored to write into the main framebuffer instead of the g-buffer.
* update grab.js to use the latest Settings edit mode detection approach
* add edit guards to handControllerGrab.js and grab.js
* update edit.js to consistently initialize Setting's edit flag
* added a new fauxJointIndex for the camera. CAMERA_MATRIX_INDEX = -7
this can be used to attach objects to the camera.
* WebTablet.js has been changed to detect when entering and exiting HMD mode
to move the tablet appropriately.
There's a known bug with the tablet entity position lagging the camera by one frame.
Basically, when using the third person camera in HMD mode. If the controllers are shown.
They should be shown in front of the users camera, not in front of the users avatar.
To accomplish this, two new faux joint indices are introduced.
CAMERA_RELATIVE_CONTROLLER_RIGHTHAND_INDEX and CAMERA_RELATIVE_CONTROLLER_LEFTHAND_INDEX.
These joint indices can be used for Overlay parenting. (But not for entity parenting because they are not transmitted over the network).
They can also be queried for by using the MyAvatar.getAbsoluteJointRotationInObjectFrame() call.
These new indices are now used by the controllerDisplay.js for the hand controller rendering.
They are also used by system/libraries/controllers.js as the origin for hand controller grabbing and interaction lasers.
* The grab sphere used to detect near grabbing is now 10cm in radius instead of 4cm.
* The visual representation of this grab sphere is always hidden, by default.
* This representation can be enabled in via the "Developer > Show Grab Sphere" menu item.
Bug fix for grabbing/equipping large objects, they no longer will drop immediately
if your grab point is too far away from the grabbed entity position.
You can do this by parenting an entity to an avatar's -2 joint index.
This will mean that the entity will follow the avatar as it moves in the world, but
will not follow the avatar's position as it moves in sensor space. Essentially, this
gives you the ability to place objects in the user's physical room.
WebTablets now are located in this feature and no longer jitter.
This makes it possible to render multiple hotspots per entity.
Also, it will use the same logic to decide how to deal with overlapping entity
equip hotspots.
