Mouse and view are not moving synchronously when dragging canvas

I've patched the dragging behavior. The idea is to cast rays into the scene and project them into the x-y plane (z == 0, there where the graph layout resides). Such a ray is constructed for the mouse position at which the drag was started, and for the current mouse position. This yields two points in the plane dragOrigin and dragDestination. The difference between both points tells us how far we have to translate the camera (location and target). Works fine in both 2D view and 3D view.

P.S. Similar code could be useful to improve dragging of nodes when the view is 3D.

I think it is better to map the mouse positions to the near plane (this is very easy as it is basically what gluUnproject does) and then subtracts those points to get the translation vector. You are basically constraining the movement along the {z=0} plane which is good in 2D, but not really in 3D.

I think I misunderstood your problem. Projecting on the graph plane seem to be the correct solution I guess. In 3D it may not work correctly though. Moving the camera you can in fact have your camera front vector basically perpendicular to the z-axis. In this case the intersection between your rays and the plane may suffer from precision issue. What about projecting to the plane perpendicular to the camera and containing the graph center (the point at the center of the bounding box containing the graph)?

I admit that the case you describe can cause precision problems. I thought that the 3D tilting angle is restricted in Gephi and that this case could thus be avoided. We use the implementation that I submitted as a patch in a different tool where a 2D map is shown in a 3D space, which is analog to showing a 2D graph layout in 3D space in Gephi. I works quite well in our tool, but yes it could happen that dragging gets imprecise. Nonetheless, I do think that the proposed patch gives a better feeling to dragging.

Anyways, I've played some more with the navigation and recognized that in addition to the problem with my patch there are two more issues:

- in case of tilted 3D display, when moving nodes, node and mouse pointer are out of sync
- using mouse wheel zoom can screw up the camera when zooming in too much.

In order to come up with suitable solutions one would need to know where objects will appear in the scene and what navigation should be possible in the view. The following options come to my mind:

representation:
- graph layout in 2D only (this is what Gephi has right now)
- graph layout in the x-y plane (z=0) with 3D tilt (this is the 3D mode of Gephi)
- arbitrary 3D layout; no restriction to a plane (is this planned for future versions of Gephi?)

navigation:
- Translation of the layout (referred to as right mouse button dragging)
- Tilt in 3D (Gephi's 3D mode)
- Zooming: essentially camera movement aligned with camera direction (Gephi mouse wheel interaction)
- Rotation of the layout around arbitrary axes (is this planned for Gephi?)
- Orbit: rotation of the camera around a point in the layout (is this planned for Gephi?)

editing:
- translation of nodes (edges)

Depending on the particular representation, different implementations of navigation are needed: object-centric (user manipulates the model, e.g., by means of virtual trackballs) or user-centric (user moves through scene, e.g., fly-through-camera). I think Google did a quite good job in implementing 3D interaction in Google Earth. Maybe one can get some inspiration from there. With regard to editing node/edge positions one have to take care not to run into well-known 3D manipulation problems.

How to proceed? Could you explain a bit more your suggestion of projecting to the plane perpendicular to the camera and containing the graph center? Isn't it that the graph center could be behind the camera?

I'm currently implementing a new version of the visualization module which will work quite differently than the current one. I'm working on the rendering system now, but mouse interaction will be implemented in the future. The new system works entirely in 3D, so real 3D layouts and navigation is in theory possible. The Gephi graph system has some restrictions though, so the reality may be different.

In 2D I will surely use something like your solution. In practice though the code might be easier than that since the z=0 plane will always face the camera. In 3D I think Gephi navigation has to be completely rewritten. Suggestions are welcome in this regard.

> representation:
> - graph layout in 2D only (this is what Gephi has right now)
> - graph layout in the x-y plane (z=0) with 3D tilt (this is the 3D mode of Gephi)
> - arbitrary 3D layout; no restriction to a plane (is this planned for future versions of Gephi?)

While arbitrary 3D layouts will be supported by the new visualization engine I'm working on, I don't know if they are planned to be released soon. The layout is currently constrained to a plane.

> navigation:
> - Translation of the layout (referred to as right mouse button dragging)
> - Tilt in 3D (Gephi's 3D mode)
> - Zooming: essentially camera movement aligned with camera direction (Gephi mouse wheel interaction)
> - Rotation of the layout around arbitrary axes (is this planned for Gephi?)
> - Orbit: rotation of the camera around a point in the layout (is this planned for Gephi?)

Are you interested in having all of them? If 3D layouts will be supported, the translation can be tricky. I think I will play with some 3D modelers to see how they solved this problem. With the current layout problem I can probably simply limit the angle between the camera and the plane and use a solution like yours. This will probably also solve some of the other problems you are experiencing.

> in case of tilted 3D display, when moving nodes, node and mouse pointer are out of sync

There are limits to the position of the nodes. This might be the reason nodes and mouse become out of sync when the angle is wide. We can probably display the limits to the position of the nodes in the visualization window to make this behaviors less strange.

> using mouse wheel zoom can screw up the camera when zooming in too much.

You are right. I don't know what's the problem.

> How to proceed? Could you explain a bit more your suggestion of projecting to the plane perpendicular to the camera and
> containing the graph center? Isn't it that the graph center could be behind the camera?

You are probably right and it would probably look strange anyway. So I think it is better to simply use your solution and restrict the angle to the {z=0} plane (there is no reason to see the graph from a very wide angle anyway).

> - graph layout in 2D only (this is what Gephi has right now)
> - graph layout in the x-y plane (z=0) with 3D tilt (this is the 3D mode of Gephi)
> - arbitrary 3D layout; no restriction to a plane (is this planned for future versions of Gephi?)

Arbitrary layout are already possible, though the navigation possibilities limit their use. It's not a priority as 3D layout is recognized to be more confusing than helping but I saw some nice ideas, for instance representing the time as the Z position. So it is in the roadma.

> navigation:
> - Translation of the layout (referred to as right mouse button dragging)
> - Tilt in 3D (Gephi's 3D mode)
> - Zooming: essentially camera movement aligned with camera direction (Gephi mouse wheel interaction)
> - Rotation of the layout around arbitrary axes (is this planned for Gephi?)
> - Orbit: rotation of the camera around a point in the layout (is this planned for Gephi?)

Rotation and Orbit are not planned but rotation could be developed if we find the time.

> in case of tilted 3D display, when moving nodes, node and mouse pointer are out of sync

I was unable to solve the moving issue in the current engine and moving nodes in 3D is not really working now. I think you are both more skilled than me for these things.

> using mouse wheel zoom can screw up the camera when zooming in too much.

You mean in 3D? I know the problem, though I don't exactly know why. I can explain how zooming works currently however. My idea was to scale the zooming factor according to the distance camera-object. More far you are, faster you're zooming. As zooming works with the mouse position, I know if objects are under the mouse ( I actually look for bounding boxes). With this distance I get the zooming factor. This code is probably not safe enough to handle negative numbers or something like that, which may cause these issues.