Streamplot 3D seems to be broken about makie.jl HOT 8 OPEN

I spent a little more time digging around and found that the issue is a very bad default value for arrow_size in streamplot. Maybe the arrows are not getting rescaled correctly? It is possible to manually set arrow_size to something small to reproduce the old behavior of streamplot, but it'd be nice if it just worked.

from makie.jl.

I don't think this is a regression. For 3D streamplots (and arrows) markersize is relative to data units, so any static size we set is going to be bad in some cases. In 2D it's given in pixel units, so it's not a problem. Maybe it would be good to calculate the bounding box of the initially given data and use that to set the default arrow size.

from makie.jl.

With 3D scatterplots, the markersize is not relative to data units, so scatter(ps) and scatter(100*ps) display the same plot. Perhaps 3D streamplots could use the same idea (or code) so that, say, one unit of arrow size is worth so many units of scatterplot markersize?

from makie.jl.

Maybe it would be good to calculate the bounding box of the initially given data and use that to set the default arrow size.

It's surprising this isn't being done, obviously you don't typically want arrows that are larger than the boundary, most likely you want the size of the arrows to also depend on how many streams are in the grid. For example if there is a 10,10 grid of streams then they can be larger than for a 25,25 grid of streams. If I were designing this, I would consider computing the default arrow size not only based on the boundary but also on the number of streams in the grid. Larger number of streams obviously require smaller arrow sizes, all proportional to the overall boundaries.

from makie.jl.

Feel free to PR such an improvement :)
It's only not there, because nobody has put the time into perfectioning the arrow recipe.

from makie.jl.

Here's a possible way to define it, I believe these proportions are appropriate:

arrow_size = 0.2minimum(limits.width)/minimum(gridsize)

However; I'm not sure how the limits values can be accessed from the @recipe macro, so I don't have a PR.

from makie.jl.

I implemented @chakravala's suggestion in the above pull request. It seems to work.
Any suggestions for the PR?

from makie.jl.

Since we're at it, I dislike the 32,32,32 default gridsize, it should really be 16,16,16 for 3D, while for 2D the 32 is fine.

Consider 32^3 = 32768 vs 16^3 = 4096 vs 32^2 = 1024. The 3D default gridsize ought to be 16,16,16. It's also very dense visually to have a 32,32,32 grid of streams. Having something less dense by default is pretty much always necessary.

Since PR #3525 depends on the gridsize, either it needs to be added to that PR or on a separate PR after that is merged.

from makie.jl.