ObjectGrab message includes invalid SurfaceInfo data when in mouselook mode

Question

ObjectGrab message includes invalid SurfaceInfo data when in mouselook mode

Opened this issue 5 months ago · 7 comments

When a viewer is in mouselook mode and an agent touches something, the ObjectGrab message's SurfaceInfo block contains invalid positional data. This invalid data appears in scripts which call llDetectedTouchPos() (and related functions) in the touch() or touch_start() event.

Subsequent ObjectGrabUpdate messages include correct SurfaceInfo data when in mouselook mode, so later touch() events show the correct data.

Repro:

Rez a sphere and create the script below in it.
Briefly touch the sphere in non-mouse look mode
Observe that the script's output always shows nonzero values reflecting the position, normal, binormal, UV, and ST of the touched surface.
Enter mouselook mode
Briefly touch the box in mouselook mode
Note the script's output

default
{
    touch(integer num_detected)
    {
        llWhisper(0, "TouchFace=" + (string)llDetectedTouchFace(0)
            + "\nTouchPos=" + (string)llDetectedTouchPos(0)
            + "\nTouchNormal=" + (string)llDetectedTouchNormal(0)
            + "\nTouchBinormal=" + (string)llDetectedTouchBinormal(0)
            + "\nTouchUV=" + (string)llDetectedTouchUV(0)
            + "\nTouchST=" + (string)llDetectedTouchST(0)
        );
    }
}

Expected results:
The script's output should always return non-trivial data, corresponding to the position, normal, binormal, UV, and ST of the touched surface. Output should be the same whether the viewer is in mouselook mode or not.

Actual results:
In non-mouselook mode, I see the expected results. But in mouselook mode, the initial touch() event or two shows invalid data for everything but touched face before it starts showing the correct data:


[15:52] Object whispers: TouchFace=0
TouchPos=<0.00000, 0.00000, 0.00000>
TouchNormal=<0.00000, 0.00000, 0.00000>
TouchBinormal=<0.00000, 0.00000, 0.00000>
TouchUV=<-1.00000, -1.00000, 0.00000>
TouchST=<-1.00000, -1.00000, 0.00000>

[15:52] Object whispers: TouchFace=0
TouchPos=<0.00000, 0.00000, 0.00000>
TouchNormal=<0.00000, 0.00000, 0.00000>
TouchBinormal=<0.00000, 0.00000, 0.00000>
TouchUV=<-1.00000, -1.00000, 0.00000>
TouchST=<-1.00000, -1.00000, 0.00000>

[15:52] Object whispers: TouchFace=0
TouchPos=<133.26110, 130.82540, 22.18916>
TouchNormal=<-0.58870, -0.77060, -0.24415>
TouchBinormal=<-0.28004, 0.47775, -0.83267>
TouchUV=<0.85824, 0.59607, 0.00000>
TouchST=<0.85824, 0.59607, 0.00000>

[15:52] Object whispers: TouchFace=0
TouchPos=<133.26110, 130.82550, 22.18822>
TouchNormal=<-0.58758, -0.77002, -0.24864>
TouchBinormal=<-0.28291, 0.48338, -0.82843>
TouchUV=<0.85780, 0.59727, 0.00000>
TouchST=<0.85780, 0.59727, 0.00000>

This bug is also observable using Hippolyzer. When reproducing the bug, Hippolyzer shows that the ObjectGrab message contains the invalid/zero data:

OUT ObjectGrab [ZEROCODED]
# ID: 13103

[AgentData]
  AgentID = [[AGENT_ID]]
  SessionID = [[SESSION_ID]]
[ObjectData]
  LocalID = 104623
  GrabOffset = <0.0, 0.0, 0.0>
[SurfaceInfo]
  UVCoord = <-1.0, -1.0, 0.0>
  STCoord = <-1.0, -1.0, 0.0>
  FaceIndex = 0
  Position = <0.0, 0.0, 0.0>
  Normal = <0.0, 0.0, 0.0>
  Binormal = <0.0, 0.0, 0.0>

but then the subsequent ObjectGrabUpdate messages contain SurfaceInfo data containing the correct values (which correspond to what the LSL functions show):

OUT ObjectGrabUpdate [ZEROCODED]
# ID: 13105

[AgentData]
  AgentID = [[AGENT_ID]]
  SessionID = [[SESSION_ID]]
[ObjectData]
  ObjectID = 3e3184f3-da23-a89f-123b-98c583db3c3a
  GrabOffsetInitial = <0.0, 0.0, 0.0>
  GrabPosition = <133.4341278076172, 130.99464416503906, 22.249996185302734>
  TimeSinceLast = 19
[SurfaceInfo]
  UVCoord = <0.8573868274688721, 0.5981845259666443, 0.0>
  STCoord = <0.8573868274688721, 0.5981845259666443, 0.0>
  FaceIndex = 0
  Position = <133.2611846923828, 130.8255157470703, 22.187469482421875>
  Normal = <-0.5864834785461426, -0.7697088718414307, -0.2521611154079437>
  Binormal = <-0.28516122698783875, 0.48761269450187683, -0.8251768350601196>

Environment:

Second Life Release 7.1.7.8974243247 (64bit)
Release Notes

You are at 241.9, 118.8, 21.7 in By Design located at simhost-06639c25759dd162e.agni
SLURL: http://maps.secondlife.com/secondlife/By%20Design/242/119/22
(global coordinates 261618.0, 246903.0, 21.7)
Second Life Preflight 2024-04-13.8669470296
Release Notes

CPU: Apple M1 Pro (2400 MHz)
Memory: 16384 MB
OS Version: Mac OS X 14.4.1 Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 x86_64
Graphics Card Vendor: Apple
Graphics Card: Apple M1 Pro

OpenGL Version: 4.1 Metal - 88

Window size: 2142x1420
Font Size Adjustment: 96pt
UI Scaling: 0.75
Draw distance: 128m
Bandwidth: 10000kbit/s
LOD factor: 1.75
Render quality: 5
Texture memory: 10922MB
Disk cache: Max size 3993.6 MB (49.3% used)
HiDPI display mode: 1

J2C Decoder Version: KDU v7.10.4
Audio Driver Version: FMOD Studio 2.02.20
Dullahan: 1.14.0.202310131309
  CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54
  Chromium: 118.0.5993.54
LibVLC Version: 3.0.16
Voice Server Version: Vivox 4.10.0000.32327.5fc3fe7c.5942f08

Packets Lost: 0/406 (0.0%)
May 17 2024 16:06:07

https://secondlife.canny.io/admin/board/bug-reports/p/lldetectedtouchpos-returns-touch-invalid-vector-when-used-in-touch-start-or-touc

Answer 1 · 2024-05-17T23:03:26.000Z

This issue has been linked to a Canny post: llDetectedTouchPos returns TOUCH_INVALID_VECTOR when used in touch_start or touch 🎉

Answer 2 · 2024-09-08T20:13:46.000Z

This issue continues to be a problem for my helicopters since the update to the PBR viewer. As one example of where it is a problem, I use an overlay (example shown here) where users can click to adjust engine controls. I am using llDetectedTouchST in the overlay to detect the position of the touch, then adjusting the appropriate engine control. Many of my users like to fly in mouselook and are currently unable to use this feature. I am hoping to see some activity toward fixing this soon.

Answer 3 · 2024-09-09T21:25:04.000Z

Not reproduced on the custom build from the latest source (branch develop), grid Aditi

BUT! Reproduced on the same build, grid Agni

Answer 4 · 2024-09-09T23:14:43.000Z

This issue has been linked to a Canny post: llDetectedTouch* functions returns default data when used in MouseLook 🎉

Answer 5 · 2024-09-10T08:18:10.000Z

This text is being generated on the server side, so the issue seems to be simulator-related
A new server bug issue is created: https://github.com/secondlife/server/issues/1421

Answer 6 · 2024-09-13T14:08:59.000Z

getting a 404 error when I try to go to https://github.com/secondlife/server/issues/1421

Answer 7 · 2024-09-17T19:35:10.000Z

getting a 404 error when I try to go to secondlife/server#1421

The server repo is not public so the issues are locked down. But the server team believes this is a viewer-side issue and will get fixed with a viewer release. (Date <TBD>)