Hook up ticksize attribute for Axis3

[fatteneder]

Description

Implements #2339

MWE

using GLMakie
GLMakie.activate!()
f = Figure()
ax3 = Axis3(f[1,1], xticksize=0.03, yticksize=0.07, zticksize=0.15)
meshscatter!(ax3, rand(10),rand(10),rand(10), label="test")
display(f)

Type of change

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

Checklist

• Added an entry in NEWS.md (for new features and breaking changes)

[jkrumbiegel]

Thanks for getting this rolling :) the thing is that you hooked up an implementation that I didn't want to keep, because it's just a hack to get ok looking ticks by default as the ticks are tied to the axis length. This way I could draw them in data coordinates. But really, they should be drawn in screen coordinates so we can give them proper screen based lengths which are then comparable to Axis.
You'd have to project the direction vectors into screen space and then scale them to the chosen length in that space, plotting them with space = :pixel which we didn't have at the time I wrote Axis3.

[fatteneder]

I swear I read your comment in the issue ... but then I must have become too excited once I figured out where to put the ticksize, so I ignored it hahaha :)

I can take a look at that over the weekend.

[jkrumbiegel]

No worries, it would be cool if you could get it to work! The Axis3 code is always a bit more complex because of the three dimensions plus rotations that mean you have to think more abstractly about where things end up visually..

[fatteneder]

I pushed something that works locally for me. I kicked out the to_topscene_2d_z part, but not sure if that is ok.

[jkrumbiegel]

Seems to work well! What's the 10000 constant in there? I don't remember why I set the z the way I did at the time, even with the comment explaining it. Maybe it was just for the case when the ticks go inward, otherwise the plot shouldn't overlap them no?

[jkrumbiegel]

And I think the space = :pixel is not necessary after all because the topscene is already a campixel one

[fatteneder]

The -100000 is needed so that ticks appear behind any plotted objects.
The comment is just taken here:

Makie.jl/src/makielayout/blocks/axis3d.jl

Lines 452 to 460 in c8a36f3

	# this function projects a point from a 3d subscene into the parent space with a really
	# small z value
	function to_topscene_z_2d(p3d, scene)
	o = scene.px_area[].origin
	p2d = Point2f(o + Makie.project(scene, p3d))
	# -10000 is an arbitrary weird constant that in preliminary testing didn't seem
	# to clip into plot objects anymore
	Point3f(p2d..., -10000)
	end

And I think the space = :pixel is not necessary after all because the topscene is already a campixel one

Ok, I can fix that later.

[fatteneder]

Close up: Close up:

I think the tick placement needs more tuning, because if you look close you can see that the ticks don't exactly align with the grid lines (the x ticks show the biggest difference).

This issue was already there before this PR. I could not figure out the problem right now. I will have to take a closer look again tomorrow.

[fatteneder]

I will have to take a closer look again tomorrow.

Sorry for the delay, but I was busy in the past week ...

I took at look this again. I checked that the endpoints of the grid lines agree with the ends of the tick lines we draw -- they are correct.
Right now I suspect that the issue is in Makie.project. In particular, if I change here

Makie.jl/src/camera/projection_math.jl

Lines 300 to 306 in e0cb400

	function project(proj_view::Mat4f, resolution::Vec2, point::Point)
	p4d = to_ndim(Vec4f, to_ndim(Vec3f, point, 0f0), 1f0)
	clip = proj_view * p4d
	p = (clip ./ clip[4])[Vec(1, 2)]
	p = Vec2f(p[1], p[2])
	return (((p .+ 1f0) ./ 2f0) .* (resolution .- 1f0)) .+ 1f0
	end

the last line to

return (((p .+ 1f0) ./ 2f0) .* (resolution .- 1f0)) .+ 0.5f0

then things look much better:

• before
  

• after
  

Q: What is the logic behind this line? I am having a difficult time determining whether the factor 0.5f0 is the solution or a hack ...

[jkrumbiegel]

Huh I feel like I debugged a similar off by a pixel projection bug in CairoMakie a long time ago.
But shouldn't we have seen the same problem in other places too if this was the case?

[jkrumbiegel]

Maybe the grid lines are just moved down a tiny bit, I did something like that to improve z fighting issues but maybe I just moved the panels back a little bit and not the grid lines.

[fatteneder]

Maybe the grid lines are just moved down a tiny bit

That was also my first idea.
But from what I can tell, ticks and grid lines are both plotted with linesegments. Becaues of that I compared their (3d) endpoints and they agree exactly.

Regarding the z shift: We only apply the -10000 z shift to the ticks. But removing it does not change anything.

[fatteneder]

Huh I feel like I debugged a similar off by a pixel projection bug in CairoMakie a long time ago.

I couldn't find an issue or PR in this repo, but I would like to see what your reasoning was there back then. Could you maybe try to dig it up for me?

[SimonDanisch]

The ~0.5 pixel offset seems like it's not a regression from this PR, so I think it shouldn't hold up merging the PR!
We should definitely investigate this though ;)

[jkrumbiegel]

yeah if that's the only thing, let's merge for now

[github-actions]

Missing reference images

Found 1 new images without existing references.
Upload new reference images before merging this PR.