The raycaster's line (when showLine is true) is not accurate when the raycaster's origin is not (0, 0, 0)

[Clicky02]

Description: When a raycaster has an origin other than (0, 0, 0), the line it creates will not accurately show the path of the raycast.

• A-Frame Version: 1.2.0
• Platform / Device: Should apply to all platforms/devices, but tested in Firefox 89
• Reproducible Code Snippet or URL:

There are two blocks of code responsible for this (both in raycaster.js)

The first is in the update function.

The key part here is that it sets unitLineEndVec3 to the unit vector of the sum of the origin and direction vectors.

The second is the drawLine function.

The key part here is the end point for the line uses the unitLineEndVec3 variable from before. Essentially it sets the line's end point to:

normalize(origin + direction) * scalarLength

Instead, it should set the end point to something equivalent to:

origin + (normalize(direction) * scalarLength)

When the origin is 0,0,0, these two are exactly the same, but when the origin is anything else, the line is not accurate to the raycaster. For example, imagine a raycaster with its origin at (30, 0, 0) and a direction of (0, 1, 0) that is intersecting with something 1 unit away at (30, 1, 0). The unitLineEndVec3 variable would be set to a unit vector that is mostly in the +x direction. Then, the line's start would be set to the origin (which is correct), but the line's end would be set to something around (1, 0, 0), which is nowhere near where the actual raycaster is intersecting.

In my case, I am using the raycaster component with oculus controller model for interacting with a menu. By default, the raycaster is not placed at the origin. So, when the menu is close to the user, there is a notable disconnect from the raycaster's end and the menu's surface. Additionally, when the intersection begins you can see the direction of the line shift.

[dmarcos]

Thanks. PRs welcome

[kylebakerio]

I've also encountered an issue along these lines, and had a hacky fix that I later decided wasn't a perfect solution, but didn't keep digging. I do remember tracing it through the source code far enough to adjust the origin of a ray to 0 0 0, iirc, though.

It seems to have broken some raycaster functionality for me in some cases in A-Frame 1.2.0 in my app, if I remember right, but my cursor situation is complex enough that it was difficult for me to construct an example to file an issue. In the end, it was a major factor in me staying behind in 1.0.4 for the time being (1.1.0 had other issues that I can't recall right now).

[kfarr]

I'm curious @Clicky02 if you have any links or screenshots of "not working" and "desired working" examples of the raycaster behavior that is being described here. It's hard for me to visualize what is wrong and being fixed, and I can't recall encountering issues on my own with the inspector raycaster in default perspective camera mode.

[kylebakerio]

I think the issue is that the current raycastor only handles the default case correctly, but when the origin should be changed (there are settings to do so), it fails to compensate? rough interpretation from memory and glancing at his code. If you try to go run some experiments along these lines (e.g., try to have a magic window clicking experience where you want the line fired from the center of the top 1/3rd of the screen instead of from the dead center of the screen, as I recently did), you'll see that things don't seem to work as expected.

that's only my most recent run-in with this issue, I also ran into it in a VR setting, but I can't recall what caused the bug for me or how I worked around it in the end, was several months ago. I found a hacky workaround at the time, and later undid the hack and did it differently. It may have been a problem with cardboard and fallen off of my priority list...? Not sure.

[Clicky02]

I don't actually have any screenshots anymore, but I just threw together a fiddle that clearly shows something is wrong.

https://jsfiddle.net/Luxusor/8rszcdLb/

[kfarr]

@Clicky02 What would be the desired behavior in that example?

[Clicky02]

Using the code from my PR, here's an updated fiddle with what it should look like vs what it actually looks like in Aframe right now.

https://jsfiddle.net/Luxusor/8rszcdLb/34/

The blue raycaster is the fixed one, and the red raycaster is the current one

[Clicky02]

Also, I'd like to add that this is just a visual bug. The PR doesn't alter which direction the raycast is going or anything, it just makes the visual representation of the raycast match the actual path that the raycast takes. So when the red raycaster randomly shortens, the actual raycaster is colliding with something, its just that the line isn't properly showing the raycaster's path.

[mikemainguy]

I just noticed this in switch from 1.3 to 1.4.1 . it seems more noticeable on oculus than in 1.3 release.

[mikemainguy]

Attached quick demo.... I put a small mark on the object where the raycaster is intersecting when the object turns yellow...it appears to be offset based on the origin shift of the raycaster, but the endpoint of the line being drawn is not.

raycaster.mp4