trouble with axes changing when issuing arrow3d call in 2nd plot of an mfrow3d()

[gonzoum]

I posted this on stackexchange and got a reply that I should post here too. here is link with screenshots:
https://stackoverflow.com/questions/75978601/axes-change-when-using-overlay-with-next3d-in-rgl

Here is a reproducible example of the problem. I want to create side by side plot3d in rgl with shared mouse.

#use an example from rgl's manual
set.seed(1234)
x <- sort(rnorm(100))
y <- rnorm(100)
z <- rnorm(100) + atan2(x, y)

#create side by side plot
open3d()
mfrow3d(1, 2, sharedMouse=TRUE)
plot3d(x, y, z, col=rainbow(100))
arrow3d(c(0, 0, 0), c(2, 2, 2), type="lines")

next3d()
plot3d(x, y, z, col=rainbow(100))
All good so far and the two plots look right.

Now overlay the arrow3d to the plot on the right side

arrow3d(c(0, 0, 0), c(2, 2, 2), type="lines")

and the axes change with the arrow not placed correctly

Can't figure out what is happening. If I plot each of these two plots with arrow3d() in separate open3d() calls they look identical. I tried other approaches such as combineWidgets in the manipulateWidget package, which works correctly but I can't figure out how to share the mouse across subscenes. plotly will be too tricky because my application require many 3d arrows along a path to create a trajectory and 3d arrows apparently are not easy to implement in plotly outside of annotations.

Running rgl 1.1.3 on R 4.2.2 on a mac (x86_64-apple-darwin17.0). Stackexchange reply confirms issue persists with arrow3d() on rgl 1.1.9. Additional commands like adding a next3d() doesn't fix the problem.

[dmurdoch]

I see it too; not sure of the cause, but probably isn't hard to fix. Will take a look.

[dmurdoch]

Looks like the problem is in rgl.window2user. It works out the locations of the parts of the arrow by converting the two points to window coordinates, computing the arrow there, then converting back to user coordinates. It appears that for some reason the final conversion is being done relative to the first pane, so the arrow ends up far to the right of where the data are located. I should be able to put together a fix this afternoon.

[dmurdoch]

Now fixed in 1.1.10 . There are a lot of internal changes in that version besides this bug fix, and you might run into other unrelated issues. If so, I'd appreciate another report.

Alternatively, if you'd rather stick with 1.1.3, I think you could get arrow3d() to work by making your own copy of it and of the fixed rgl.window2user().