search

dmurdoch / rgl

rgl is a 3D visualization system based on OpenGL. It provides a medium to high level interface for use in R, currently modelled on classic R graphics, with extensions to allow for interaction.
https://dmurdoch.github.io/rgl/
GNU General Public License v2.0
85 stars 20 forks source link

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

Closed gonzoum closed 1 year ago

gonzoum commented 1 year ago

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 commented 1 year ago

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

dmurdoch commented 1 year ago

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 commented 1 year ago

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().