Creating CAD style camera handling

[Kevin-Mattheus-Moerman]

This relates to:
JuliaGL/GLAbstraction.jl#96 (and also: MakieOrg/Makie.jl#38, JuliaGL/GLAbstraction.jl#76, JuliaGL/GLAbstraction.jl#80, MakieOrg/Makie.jl#329).

Moving discussion here as it is about AbstractPlotting's camera handling (in particular https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/camera/camera3d.jl)

[Kevin-Mattheus-Moerman]

The goals is to have AbstractPlottings camera handling be like this (screenshot of MeshLab):

i.e. such that moving the cursor to the left or right (screen's/viewer's [1 0] direction) rotates the object around the screen's/viewer's vertical axis ([0 1]). Similarly moving the cursor up or down (screen's/viewer's [0 1] direction) will rotate the object around the screen's/viewer's left-right or horizontal axis ([1 0]).

[CarpeNecopinum]

Replacing
rotation = rotate_cam(theta_v, right_v, Vec3f0(0, 0, sign(upvector[3])), dir)
in line 189 by
rotation = rotate_cam(theta_v, right_v, upvector, dir)
already gets us most of the way there.

Additionally I suggest removing line 174 (cam.lookat[] = lookat + zoom_translation) for a more CAD-style feeling, as it allows rotation of a zoomed-in object.

If desired, I can open a PR for this.

[CarpeNecopinum]

In general I think we should allow multiple different 3d camera variants to exist in AbstractPlotting.jl, as the old behavior is probably better for "just a plot"-style scenes.

On the other end of the spectrum, I prefer a FPS/Spaceship-style camera movement (like in https://github.com/CarpeNecopinum/Shiny.jl/blob/master/src/movement.jl) for large, complex scenes.

[asinghvi17]

@CarpeNecopinum, that would be great!

[Kevin-Mattheus-Moerman]

👏 @CarpeNecopinum please do

[mschauer]

Can you specify what the mechanics is? Do I understand that this corresponds to picking a vector from the center ending on the plane of view and moving the arrow tip on the plane of view and taking the rotation of the corresponding vector?

[SimonDanisch]

cameras are also just recipe like, and the camera argument already works with arbitrary functions, that add a camera to the scene ;) So the design is already ready for different cameras!

[CarpeNecopinum]

@mschauer It essentially just translates mouse drags on the x-axis to rotation around some "upwards" axis and mouse drags on the y-axis to rotation around some "right" axis.

The original cam3d! always used the global z-axis as "upwards", which gives you a turntable-style rotation where the up-axis of the camera and the z-axis of the world will always stay somewhat aligned (though you can flip the camera upside down).

The CAD-style camera uses the up-axis of the camera as "upwards" for the rotation, which allows any rotation to be achieved.

[mschauer]

Ok, get it, thank you. That is equivalent or maybe actually the same as what I said. it would be worth to try to do it as I described and check if that gives a natural feel (if done right, then moving the mouse up and then right gets you to the same rotation as moving first right and then up). So the reference axes should perhaps not change while the mouse key is pressed.

[asinghvi17]

We could create a CamCAD or something which would have this behaviour, and leave Cam3d intact, if people want that. Or, we could do it the other way around as well - it's simply a matter of dispatching to the correct methods, and the CamCAD could (maybe should) be a subtype of Cam3D (they will probably share a lot of code).

[CarpeNecopinum]

Since all the difference is in the event handlers anyways, we could probably do with just keeping the one Camera3D, but replace cam3d! with cam3d_cad! and cam3d_turntable! (still taking suggestions on the names 😉 , with cam3d! as alias to cam3d_turntable for compatibility with existing code).

[asinghvi17]

A keyword argument in the constructor is always an option (cam3d!(;mode = :turntable)) for example.

[CarpeNecopinum]

Should we make it part of the Theme then? That way, people could set their preferred style in the scene and rely on the automatic detection of 2d vs. 3d scenes, rather than having to call cam3d! with the preferred mode explicitly.

[asinghvi17]

So something like cam3dstyle = :cad?

[SimonDanisch]

Camera is already part of the theme:
https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/theming.jl#L44
and can be set to whatever camera function ;)

A keyword argument in the constructor is always an option (cam3d!(;mode = :turntable)) for example.

I don't like if kw_args change behaviour drastically... Also, this way we can't pass it to the camera keyword argument. Although, that you can't pass kw_args to the camera is a bit lame and something we should fix.

[asinghvi17]

One thing we can do, is implement this suggestion:

Since all the difference is in the event handlers anyways, we could probably do with just keeping the one Camera3D, but replace cam3d! with cam3d_cad! and cam3d_turntable! (still taking suggestions on the names 😉 , with cam3d! as alias to cam3d_turntable for compatibility with existing code).

and leave the default as it is, with the option to change the default at 1.0.0 release.

[CarpeNecopinum]

Camera is already part of the theme:
https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/theming.jl#L44
and can be set to whatever camera function ;)

One issue I just found is that setup_camera! checks for a limited list of function names, and errors out if the function in the theme doesn't match any of (cam2d!, cam3d!, campixel!).
(https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/interfaces.jl#L598)

You can still add a custom camera function by calling it explicitly, but it being able to be part of the theme would definitely be nicer.

I thought about replacing the check by testing if the camera function can be called on scene, but that'll effectively done by Julia already, so I'd suggest just leaving it out entirely.

[SimonDanisch]

We could leave the check to open this up ;) or add the new camera to the list! The question is, do we want to have cameras live in packages, or are we fine with adding all custom cameras to AbstractPlotting?

[asinghvi17]

I think it's perfectly fine for a package to define it's own camera style...

[SimonDanisch]

Yeah it's fine, but I wonder if it wouldn't be better to enforce that people add it as a PR, so that different cameras are more visible!

[asinghvi17]

Sure, that makes sense...perhaps we should add a warning in the docs, along with any new camera page that's added - which I could get around to in a week or so. We could also print a request to upstream a new camera type if it's detected.