Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize view and projection matrices #3550

Closed
wants to merge 14 commits into from

Conversation

ffreyer
Copy link
Collaborator

@ffreyer ffreyer commented Jan 13, 2024

Description

This prepares some things for #3226:

  • move translations from projection to view matrices
  • track eyeposition in Axis and PolarAxis
  • rework Axis3 to use perspectiveprojection and lookat without modification (though I split up lookat into two steps)
  • add inv(::Quaternion)

And some random minor cleanup of Axis3 docs (indention, wrong render order in W/GLMakie, double-plotting of Label) + camera controller (name change).

Axis3 comparsion

Axis3 has more extensive changes so things could be different. Here are some new vs old comparisons with docs:

Aspect

Screenshot from 2024-01-13 14-39-03

Screenshot from 2024-01-13 14-39-03

Viewing angles

Screenshot from 2024-01-13 14-41-01

Tick placement seems to be slightly different (e.g. bottom left z is cut off more, top left z's overlap more(?))

Screenshot from 2024-01-13 14-41-35

Slightly less space to the title here as well

Perspectiveness

Screenshot from 2024-01-13 14-42-26

viewmodes

Screenshot from 2024-01-13 14-50-56

Also checked this with perspectiveness = 0.6, no visible changes.

Tight frustum testing/debugging

This will show you the generated frustum (i.e. what area of the scene will be rendered) with th view space bounding box (+ bounding sphere for :fit) of the Axis3.

using GeometryBasics

function camera_debug(gridpos, ax::Axis3)
    function frustum_snapshot(cam)
        r = Rect3f(Point3f(-1, -1, -1), Vec3f(2, 2, 2))
        rect_ps = coordinates(r) .|> Point3f
        insert!(rect_ps, 13, Point3f(1, -1, 1)) # fix bad line

        inv_pv = inv(cam.projectionview[])
        return map(rect_ps) do p
            p = inv_pv * to_ndim(Point4f, p, 1)
            return p[Vec(1,2,3)] / p[4]
        end
    end

    scene = ax.scene
    cam = scene.camera
    frustum = map(pv -> frustum_snapshot(cam), cam.projectionview)

    scene2 = LScene(gridpos, show_axis = false)

    _cc = Makie.Camera3D(
        scene2.scene, projectiontype = Makie.Orthographic,
        near = 0.001f0, far = 1000.0f0, clipping_mode = :static
    )
    lines!(scene2, frustum, color = :blue, linestyle = :dot)

    # bbox is Axis3 specific
    bbox = ax.finallimits
    model = ax.scene.transformation.model
    bb = map(model, bbox) do model, bb
        ps = [(model * to_ndim(Point4f, p, 1))[Vec(1,2,3)] for p in Makie.corners(bb)]
        Rect3f(ps)
    end
    r = map(bb -> maximum(norm.(Makie.corners(bb))), bb)

    linesegments!(scene2, bb, color = :black)
    wireframe!(scene2, map(r -> Sphere(Point3f(0), r), r), color = (:black, 0.2), transparency = true)
    # scatter!(scene2, scene.camera.eyeposition, color = :red)
    scatter!(scene2, Point3f(0), color = :blue)

    r = map(frustum) do frustum
        ps = vcat(frustum[1:12], frustum[14:end])
        normal_mesh(ps, faces(Rect3f()))
    end
    mesh!(scene2, r, color = (:red, 0.3), fxaa = false, transparency = true)
    notify(frustum)

    return scene2
end

begin
    fig = Figure()

    # show the extent of each cell using a box
    b = Box(fig[1, 1], strokewidth = 0, color = :gray95)
    translate!(b.blockscene, Vec3f(0, 0, -10_000))

    ax = Axis3(
        fig[1, 1]; viewmode = :stretch, protrusions = 0,
        aspect = (1,2,3), perspectiveness = 0.5
    )
    hidedecorations!(ax)
    camera_debug(fig[1, 2], ax)
    fig
end

Type of change

  • internal adjustments

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
Copy link
Collaborator

MakieBot commented Jan 13, 2024

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(fig)
using create display create display
GLMakie 4.56s (4.50, 4.62) 0.05+- 114.35ms (109.54, 120.26) 3.87+- 569.14ms (562.17, 576.55) 4.72+- 9.37ms (9.06, 9.57) 0.23+- 26.72ms (26.44, 26.91) 0.15+-
master 4.55s (4.51, 4.59) 0.03+- 112.33ms (109.81, 115.40) 2.23+- 572.35ms (564.85, 578.93) 5.04+- 9.21ms (8.93, 9.53) 0.18+- 26.62ms (26.51, 26.87) 0.12+-
evaluation 1.00x invariant, 0.01s (0.18d, 0.74p, 0.04std) 0.98x invariant, 2.02ms (0.64d, 0.26p, 3.05std) 1.01x invariant, -3.21ms (-0.66d, 0.24p, 4.88std) 0.98x invariant, 0.16ms (0.77d, 0.18p, 0.20std) 1.00x invariant, 0.1ms (0.74d, 0.19p, 0.14std)
CairoMakie 3.91s (3.86, 3.97) 0.05+- 105.74ms (103.98, 109.30) 1.88+- 158.87ms (156.88, 161.77) 1.73+- 9.44ms (9.34, 9.53) 0.07+- 1.13ms (1.12, 1.14) 0.01+-
master 3.94s (3.86, 4.10) 0.08+- 105.83ms (104.24, 109.39) 1.67+- 161.63ms (158.82, 166.22) 2.39+- 9.49ms (9.36, 9.60) 0.08+- 1.14ms (1.12, 1.16) 0.01+-
evaluation 1.01x invariant, -0.03s (-0.48d, 0.39p, 0.06std) 1.00x invariant, -0.09ms (-0.05d, 0.93p, 1.78std) 1.02x faster ✓, -2.76ms (-1.32d, 0.03p, 2.06std) 1.00x invariant, -0.05ms (-0.63d, 0.26p, 0.07std) 1.01x invariant, -0.01ms (-0.94d, 0.11p, 0.01std)
WGLMakie 4.61s (4.57, 4.66) 0.04+- 106.64ms (104.61, 109.51) 1.54+- 9.27s (9.15, 9.42) 0.09+- 11.25ms (10.96, 11.60) 0.23+- 116.69ms (111.20, 120.87) 3.10+-
master 4.60s (4.57, 4.65) 0.03+- 106.96ms (105.11, 115.11) 3.63+- 9.31s (9.21, 9.44) 0.09+- 11.42ms (10.90, 13.57) 0.96+- 117.91ms (112.70, 121.80) 3.45+-
evaluation 1.00x invariant, 0.01s (0.42d, 0.45p, 0.03std) 1.00x invariant, -0.32ms (-0.12d, 0.83p, 2.59std) 1.00x invariant, -0.04s (-0.44d, 0.43p, 0.09std) 1.02x invariant, -0.17ms (-0.25d, 0.66p, 0.59std) 1.01x invariant, -1.22ms (-0.37d, 0.50p, 3.27std)

@ffreyer
Copy link
Collaborator Author

ffreyer commented Jan 13, 2024

space 3D failing is expected because the near and far planes are now tight to the finallimits in Axis3. This should also change OIT there, but I don't think we explicitly test that.

Failures in CairoMakie are one-pixel offsets of tick labels in Axis3. GLMakie and WGLMakie are the expected space 3D

@ffreyer ffreyer mentioned this pull request Mar 3, 2024
8 tasks
@ffreyer ffreyer changed the title Some preparations for Float32 fixes / Standardize view and projection matrices Standardize view and projection matrices Mar 18, 2024
@asinghvi17
Copy link
Member

Were these changes merged in 0.21?

@ffreyer
Copy link
Collaborator Author

ffreyer commented May 30, 2024

No they weren't.

This came from a thought that we'd implement Float32 scaling based on the model, view and projection matrix, i.e. independently of limits which aren't known by the backend. A consistent structure for those matrices would have been useful for that.

Now this is less important but maybe still useful as a clean up. I.e. maybe it's easier to follow what Axis3 does camera wise after this. It might also be the case that some lighting calculation or SSAO makes some assumptions about camera matrices that aren't true without this (i.e. transpose = inv).

@ffreyer
Copy link
Collaborator Author

ffreyer commented Jul 18, 2024

space 3D failing is expected because the near and far planes are now tight to the finallimits in Axis3. This should also change OIT there, but I don't think we explicitly test that.

Still true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants