3D Camera Orientation Widget

[ffreyer]

Description

Old Description

Implements the Widget from #2624, which allows you to orient a 3D axis by clicking on different faces of the mesh, or rotating that mesh with mouse interactions. This will need some adjustments after #2746.

I think this looks pretty bad atm so I'm open to suggestions.

Blender has this with only 6 directions, which is a bit too coarse imo.

Maybe this should be similar to the Navball in Kerbal Space Program, which could also double as an (external) axis type thing. To orient the plot we could allow different angular step size, which we could round to on click. (Ignore all the UI around the ball)

This pr is in some sense a continuation/more polished implementation of #2624. The goal is to provide another tool for controlling and understanding the orientation of the 3D camera. I'm taking inspiration from Kerbal Space Program here, which uses a textured ball to represent the orientation of a rocket relative to the planets surface.

My current Makie version looks like this:

The background color choice in KSP, light blue and brown, is probably meant to represent the sky and the ground. (The blue side always faces up). I wanted to avoid dark backgrounds for this, so I switched from brown to green, which I hope still gets that thought across. The green is a bit darker than the blue, so it should still be differentiable with color blindness.

This will need some adjustments after #2746.

TODO:

• apply rotations of the ball to a linked LScene or Axis3 and vice verse
• move attributes to Block
• make a prototype for the Navball version
• allow this to be detached from layouting
• allow a detached controller to be draged around in the window
• add click interactions for focusing a view direction
• add scroll interactions to adjust the granularity of click interactions
• cleanup debug printing
• add different textures for different zoom levels to keep things readable
• general cleanup

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• Added an entry in NEWS.md (for new features and breaking changes)
• Added or changed relevant sections in the documentation
• Added unit tests for new algorithms, conversion methods, etc.
• Added reference image tests for new plotting functions, recipes, visual options, etc.

[MakieBot]

Compile Times benchmark

Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than the base branch. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running:

using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))

	using	create	display	create	display
GLMakie	4.29s (4.27, 4.32) 0.02+-	103.89ms (102.13, 106.37) 1.34+-	528.75ms (526.27, 531.12) 1.78+-	8.65ms (8.32, 8.89) 0.23+-	25.62ms (25.53, 25.77) 0.08+-
master	4.26s (4.22, 4.30) 0.03+-	104.19ms (103.00, 107.72) 1.59+-	527.26ms (524.45, 530.56) 2.15+-	8.58ms (8.33, 8.83) 0.23+-	25.64ms (25.50, 25.96) 0.15+-
evaluation	0.99x slower X, 0.03s (1.39d, 0.02p, 0.02std)	1.00x invariant, -0.3ms (-0.20d, 0.71p, 1.47std)	1.00x invariant, 1.48ms (0.75d, 0.19p, 1.97std)	0.99x invariant, 0.07ms (0.30d, 0.58p, 0.23std)	1.00x invariant, -0.02ms (-0.17d, 0.76p, 0.12std)
CairoMakie	3.86s (3.71, 4.00) 0.14+-	107.66ms (105.07, 111.10) 2.62+-	131.67ms (128.46, 135.24) 2.34+-	8.55ms (8.39, 8.77) 0.16+-	1.00ms (0.99, 1.01) 0.01+-
master	3.72s (3.69, 3.80) 0.04+-	107.87ms (105.13, 110.97) 2.18+-	131.76ms (130.14, 134.19) 1.48+-	8.43ms (8.30, 8.59) 0.11+-	985.42μs (976.16, 992.26) 5.14+-
evaluation	0.96x slower X, 0.14s (1.43d, 0.03p, 0.09std)	1.00x invariant, -0.21ms (-0.09d, 0.87p, 2.40std)	1.00x invariant, -0.09ms (-0.04d, 0.94p, 1.91std)	0.99x invariant, 0.11ms (0.80d, 0.16p, 0.14std)	0.99x slower X, 0.01ms (2.42d, 0.00p, 0.01std)
WGLMakie	4.53s (4.48, 4.57) 0.03+-	108.71ms (104.33, 120.70) 5.74+-	9.04s (8.89, 9.22) 0.10+-	9.86ms (9.28, 10.63) 0.69+-	71.04ms (70.46, 71.81) 0.51+-
master	4.56s (4.52, 4.65) 0.04+-	105.80ms (104.13, 107.75) 1.39+-	9.04s (8.92, 9.23) 0.11+-	9.52ms (9.23, 10.54) 0.46+-	70.80ms (69.67, 71.64) 0.83+-
evaluation	1.01x invariant, -0.03s (-0.76d, 0.18p, 0.04std)	0.97x invariant, 2.91ms (0.70d, 0.24p, 3.56std)	1.00x invariant, 0.0s (0.04d, 0.95p, 0.10std)	0.97x invariant, 0.34ms (0.58d, 0.30p, 0.57std)	1.00x invariant, 0.23ms (0.34d, 0.54p, 0.67std)

[asinghvi17]

There are some nice textures we could use for a KSP like navball here - all under a FOSS license

[ffreyer]

Oh, cool. I think as a default we'd want a texture with x/y/z marked rather than north, south, etc, but I could try to be compatible with those textures.

[ffreyer]

Navball prototype with a texture from the repo:

I think with a (linear) gauge showing the step width rather than the plain text this would be pretty nice.

[asinghvi17]

I could do a spherical axis instead, that might actually be better since it's more customizable. Will send the code when I can.

[ffreyer]

I was planning to generate a texture with Makie code. That could be customized, though you probably want to do it in CairoMakie because fxaa makes this kinda of ugly in GLMakie.

[ffreyer]

This is how it currently looks: (outdated, see initial post)

The texture is generated with the two prs I referenced. The white region marks where you can snap to on click, and it reacts to hovers. The degree indicator appears when you scroll and disappears after 3s

[ffreyer]

TODO:

• Updating img with Sampler(img) does seem to change Sampler.data but creates the same texture as pre-update if that update happens before displaying.
• Anisotropic filtering doesn't work anymore?