makieorg / makie.jl Goto Github PK

View Code? Open in Web Editor NEW

2.3K 28.0 278.0 646.96 MB

Interactive data visualizations and plotting in Julia

Home Page: https://docs.makie.org/stable

License: MIT License

Julia 62.83% GLSL 5.96% JavaScript 30.99% HTML 0.18% TeX 0.01% CSS 0.02%

julia plotting visualization julia-language gpu graphics

makie.jl's People

Contributors

Stargazers

Watchers

Forkers

mpastell mkborregaard hvukman mschauer ashedko nhdaly hunslater ssfrr jpsamaroo blegat anthony-wang beastyblacksmith daschw louisponet smldis saschamann okwh noisyoscillator raphbacher rowhit musm carpenecopinum zgornel pgbarletta maximerivest pablosanjose barche lstagner alblaz asinghvi17 dlfivefifty kskyten batmanabcdefg ajd3v csertegt3 rgerzaguet heiderich suzil logankilpatrick aramirezreyes simondanisch aerdely n8xm tokazama cpfiffer scls19fr djjty zeitguy iomeone ianbutterworth mlackner freemin7 miketartar eschnett prototypefund tubbz-alt dutta-alankar albert-de-montserrat ffreyer visr jlchan hexaeder mofii vchuravy ericphanson kolia marlin-na johnnychen94 sethaxen touste evoart st-- theogf t-bltg shreyagangadhar knuesel wulan87 kolaru michaelhatherly standardgalactic greimel krastanov stjordanis paurierap devmotion kimlaberinto felixcremer yakir12 jlbosse rainerheintzmann jtrakk science-ed tlienart goretkin ashtonsbradley heindelj datseris briochemc rlschuller behinger

makie.jl's Issues

horizontal mouse rotate is always on world axes

it seems that vertically rotating with the mouse up/down acts on the camera's coordinate system, but horizontal rotation (mouse left-right) is rotating along the world's axis. To me it seems like it would be more intuitive to have horizontal rotation also be around the camera's "up" axis, but I suppose this could be a subjective preference.

update colors in mesh

Exploring the huge possibilities of Makie, I was surprised that the following example didn't actualize the colors. Whereas the analogous call for meshscatter actualizes the color.
It is not the right way to update an attribute?

using Makie
scene = Scene(resolution = (500, 500))
x = [0, 1, 2, 0]
y = [0, 0, 1, 2]
z = [0, 2, 0, 1]
color = [:red, :green, :blue, :yellow]
i = [0, 0, 0, 1]
j = [1, 2, 3, 2]
k = [2, 3, 1, 3]
indices = [1, 2, 3, 1, 3, 4, 1, 4, 2, 2, 3, 4]
m = mesh(x, y, z, indices, color = color)
wireframe(m[:mesh], color = :black, linewidth = 2)
m[:color] = [:blue, :red, :blue, :red]
center!(scene)

pan/zoom on 2D graphs

When plotting high-density data I often use the pan/zoom functions in PlotlyJS. It would be super useful to be able to navigate similiarly in a 2D Makie scene.

PlotlyJS's box zoom behavior is also very nice, where it lets you either define a rectangle to zoom or zoom just along the x or y axes, depending on how you drag. That seems lower-priority than basic pan/zoom though.

compatibility attributes/keyword arguments

scene = Scene(resolution = (500,500), position = [0, 0])

is ok, but

scene[:position] = [100, 100] or scene[:resolution] = (800, 800)

does not produce any effect. i would have expect some compatibility between keyword arguments and attributes

option to flip heatmap

currently heatmap puts cell (1,1) in the top-left corner. This is often what you want (like when visualizing an image), but other times you want it on the bottom-left (e.g. in an audio spectrogram).

for reference PyPlot's imshow function takes the origin="upper" or origin="lower" options.

UndefVarError: to_markersize not defined

Line 18 in this example https://github.com/SimonDanisch/Makie.jl/blob/master/docs/src/examples/theming.jl seems to call an undefined function.

2D/3D camera behavior is too magical (or not magical enough?)

From what I can tell the camera is 2D if the first thing plotted is flat, e.g. lines(1:20, rand(20), zeros(20) will use a 2D camera, (as will lines(1:20, rand(20), ones(20)) but lines(1:20, rand(20), rand(20)) will create a 3D camera. Adding a 3D plot after first adding a 2D plot doesn't seem to upgrade the camera to 3D.

I had expected the camera to be a property of the Scene, and would exist before you'd actually added any objects to the scene (it just wouldn't have anything to look at), and could be set with something like scene = Scene(camera=:perspective). Currently it seems like the camera is a property of the object being plotted (e.g. lines(1:20, rand(20), zeros(20), camera=:perspective), but I don't understand the use-case for per-object cameras.

For context, I hit this when trying to do a plot like this:

using a bunch of lines calls. Each one is flat so the scene ends up using the 2D camera.

Makie.jl/REQUIRE should include AbstractNumbers

Just went to use Makie and got an error about an uninstalled package AbstractNumbers. The dependency should be included in the REQUIRE list.

Common attributes

The key feature of Plots.jl is that every command is just plot, and every plot has a common set of attributes.

http://docs.juliaplots.org/latest/attributes/

Can that page be replicated in Makie?

unstoppable warning when running legend example from the docs

After trying:

using Makie, GeometryTypes, Colors

# Create some plots for which we want to generate a legend
scene = Scene()
plots = map([:dot, :dash, :dashdot], [2, 3, 4]) do ls, lw
    linesegment(linspace(1, 5, 100), rand(100), rand(100), linestyle = ls, linewidth = lw)
end
push!(plots, scatter(linspace(1, 5, 100), rand(100), rand(100)))
center!(scene)

from the docs, I get a repeating warning (it repeats itself until I kill the Julia session:

WARNING: Message queue is full. Ordering may be incorrect.

I'm on Makie master (and GeometryTypes v0.4.4, Colors 0.8.2)

use `:z` for heatmap data property?

I generally think of heatmap and surface as being closely-related, so I figured I could update the data of a heatmap with hm[:z] = newdata, but apparently it wants hm[:heatmap] = newdata. Do you think :z might be a better property name for that, to match surface?

Missing dependency: ColorBrewer

22:35 $ julia runtests.jl
ERROR: LoadError: LoadError: ArgumentError: Module ColorBrewer not found in current path.
Run `Pkg.add("ColorBrewer")` to install the ColorBrewer package.\

documentation is down

The readme points to http://www.glvisualize.com/Makie.jl/stable/, but that appears to be down.

Line not displayed

The line z is not displayed. Uncommenting the third point in z makes the line visible.

using Makie, Colors, GeometryTypes
scene = Scene(resolution = (200, 200))
x = [Point3f0(0,1,l) for l in [0., 1., 2., 3.]]
z = [Point3f0(0,0,l) for l in [-0.5, #=0.0,=# 0.5]]
lines(x, linewidth=3.5, color=colorant"black")
lines(z, linewidth=3.5, color=:darkred)

center!(scene)

Running surfacelink generated errors

julia> include("docs\\src\\examples\\surfacelink.jl")
WARNING: imported binding for range overwritten in module Main
1   : #version 330
2   :
3   : #extension GL_ARB_conservative_depth: enable
4   :
5   : struct Nothing{ //Nothing type, to encode if some variable doesn't contain any data
6   :     bool _; //empty structs are not allowed
7   : };
8   : struct Grid1D{
9   :     float ref;
10  :     float offset;
11  :     float _step;
12  :     int dims;
13  : };
14  : struct Grid2D{
15  :     vec2 ref;
16  :     vec2 offset;
17  :     vec2 _step;
18  :     ivec2 dims;
19  : };
20  : struct Grid3D{
21  :     vec3 ref;
22  :     vec3 offset;
23  :     vec3 _step;
24  :     ivec3 dims;
25  : };
26  :
27  : in vec4 uv_offset_width;
28  : // uv_width;
29  : in vec3 position;
30  : uniform Nothing position_x;
31  : uniform Nothing position_y;
32  : uniform Nothing position_z;
33  : //Assembling functions for creating the right position from the above inputs. They also indicate the type combinations allowed for the above inputs
34  : ivec2 ind2sub(ivec2 dim, int linearindex);
35  : ivec3 ind2sub(ivec3 dim, int linearindex);
36  :
37  : in vec2   scale; // so in the case of distinct x,y,z, there's no chance to unify them under one variable
38  : uniform Nothing scale_x;
39  : uniform Nothing scale_y;
40  : uniform Nothing scale_z;
41  : vec3 _scale(Nothing scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index);
42  : vec3 _scale(vec3    scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index);
43  : vec3 _scale(vec2    scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index);
44  : vec3 _scale(Nothing scale, float   scale_x, float   scale_y, float   scale_z, int index);
45  : vec3 _scale(vec3    scale, float   scale_x, float   scale_y, float   scale_z, int index);
46  : vec3 _scale(vec2    scale, float   scale_x, float   scale_y, float   scale_z, int index);
47  :
48  :
49  :
50  : in vec2 offset;
51  :
52  : in vec4 rotation;
53  : vec3 _rotation(Nothing r){return vec3(0,0,1);}
54  : vec3 _rotation(vec2 r){return vec3(r, 3.1415926535897);}
55  : vec3 _rotation(vec3 r){return r;}
56  :
57  : float get_rotation_len(vec2 rotation){
58  :     return length(rotation);
59  : }
60  : float get_rotation_len(Nothing rotation){
61  :     return 1.0;
62  : }
63  : float get_rotation_len(vec3 rotation){
64  :     return length(rotation);
65  : }
66  : vec3 _scale(Nothing scale, float scale_x, float scale_y, Nothing scale_z, int index){
67  :     float len = get_rotation_len(rotation);
68  :     return vec3(scale_x,scale_y, len);
69  : }
70  : vec3 _scale(vec3 scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index){
71  :     float len = get_rotation_len(rotation);
72  :     return vec3(scale.xy, scale.z*len);
73  : }
74  :
75  : in vec4        color;
76  : uniform Nothing    color_map;
77  : uniform Nothing    intensity;
78  : uniform Nothing   color_norm;
79  :
80  : float get_intensity(vec3 rotation, Nothing position_z, int index){return length(rotation);}
81  : float get_intensity(vec2 rotation, Nothing position_z, int index){return length(rotation);}
82  : float get_intensity(Nothing rotation, float position_z, int index){return position_z;}
83  : float get_intensity(vec3 rotation, float position_z, int index){return position_z;}
84  : vec4 color_lookup(float intensity, sampler1D color_ramp, vec2 norm);
85  :
86  : vec4 _color(vec3 color, Nothing intensity, Nothing color_map, Nothing color_norm, int index, int len);
87  : vec4 _color(vec4 color, Nothing intensity, Nothing color_map, Nothing color_norm, int index, int len);
88  : vec4 _color(Nothing color, float intensity, sampler1D color_map, vec2 color_norm, int index, int len);
89  : vec4 _color(Nothing color, sampler1D intensity, sampler1D color_map, vec2 color_norm, int index, int len);
90  : vec4 _color(Nothing color, Nothing intensity, sampler1D color_map, vec2 color_norm, int index, int len){
91  :     return color_lookup(get_intensity(rotation, position_z, index), color_map, color_norm);
92  : }
93  :
94  : uniform vec4 stroke_color;
95  : uniform vec4   glow_color;
96  :
97  : uniform uint objectid;
98  : uniform int len;
99  :
100 : out uvec2 g_id;
101 : out int   g_primitive_index;
102 : out vec3  g_position;
103 : out vec4  g_offset_width;
104 : out vec4  g_uv_offset_width;
105 : out vec3  g_rotation;
106 : out vec4  g_color;
107 : out vec4  g_stroke_color;
108 : out vec4  g_glow_color;
109 :
110 :
111 :
112 : void main(){
113 :     int index         = gl_VertexID;
114 :   g_primitive_index = index;
115 :     vec3 pos;
116 :     pos = vec3(position  );
117 :     g_position        = pos;
118 :     g_offset_width.xy = offset.xy;
119 :     g_offset_width.zw = _scale(scale, scale_x, scale_y, scale_z, g_primitive_index).xy;
120 :     g_color           = _color(color, intensity, color_map, color_norm, g_primitive_index, len);
121 :     g_rotation        = _rotation(rotation);
122 :     g_uv_offset_width = uv_offset_width;
123 :     g_stroke_color    = stroke_color;
124 :     g_glow_color      = glow_color;
125 :
126 :     g_id              = uvec2(objectid, index+1);
127 : }
128 :
WARNING: shader C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\sprites.vert didn't compile.
ERROR: 0:68: 'get_rotation_len' : no matching overloaded function found (using implicit conversion)
ERROR: 0:68: 'get_rotation_len' : function is not known
ERROR: 0:72: 'get_rotation_len' : no matching overloaded function found (using implicit conversion)
ERROR: 0:72: 'get_rotation_len' : function is not known
ERROR: 0:91: 'get_intensity' : no matching overloaded function found (using implicit conversion)
ERROR: 0:91: 'get_intensity' : function is not known
ERROR: 0:122: '_rotation' : no matching overloaded function found (using implicit conversion)
ERROR: 0:122: '_rotation' : function is not known
ERROR: 0:121: 'assign' :  cannot convert from 'const highp float' to 'varying 3-component vector of highp float'

1   : #version 330
2   :
3   : #extension GL_ARB_conservative_depth: enable
4   :
5   : struct Nothing{ //Nothing type, to encode if some variable doesn't contain any data
6   :     bool _; //empty structs are not allowed
7   : };
8   : struct Grid1D{
9   :     float ref;
10  :     float offset;
11  :     float _step;
12  :     int dims;
13  : };
14  : struct Grid2D{
15  :     vec2 ref;
16  :     vec2 offset;
17  :     vec2 _step;
18  :     ivec2 dims;
19  : };
20  : struct Grid3D{
21  :     vec3 ref;
22  :     vec3 offset;
23  :     vec3 _step;
24  :     ivec3 dims;
25  : };
26  :
27  : in vec4 uv_offset_width;
28  : // uv_width;
29  : in vec3 position;
30  : uniform Nothing position_x;
31  : uniform Nothing position_y;
32  : uniform Nothing position_z;
33  : //Assembling functions for creating the right position from the above inputs. They also indicate the type combinations allowed for the above inputs
34  : ivec2 ind2sub(ivec2 dim, int linearindex);
35  : ivec3 ind2sub(ivec3 dim, int linearindex);
36  :
37  : in vec2   scale; // so in the case of distinct x,y,z, there's no chance to unify them under one variable
38  : uniform Nothing scale_x;
39  : uniform Nothing scale_y;
40  : uniform Nothing scale_z;
41  : vec3 _scale(Nothing scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index);
42  : vec3 _scale(vec3    scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index);
43  : vec3 _scale(vec2    scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index);
44  : vec3 _scale(Nothing scale, float   scale_x, float   scale_y, float   scale_z, int index);
45  : vec3 _scale(vec3    scale, float   scale_x, float   scale_y, float   scale_z, int index);
46  : vec3 _scale(vec2    scale, float   scale_x, float   scale_y, float   scale_z, int index);
47  :
48  :
49  :
50  : in vec2 offset;
51  :
52  : in vec4 rotation;
53  : vec3 _rotation(Nothing r){return vec3(0,0,1);}
54  : vec3 _rotation(vec2 r){return vec3(r, 3.1415926535897);}
55  : vec3 _rotation(vec3 r){return r;}
56  :
57  : float get_rotation_len(vec2 rotation){
58  :     return length(rotation);
59  : }
60  : float get_rotation_len(Nothing rotation){
61  :     return 1.0;
62  : }
63  : float get_rotation_len(vec3 rotation){
64  :     return length(rotation);
65  : }
66  : vec3 _scale(Nothing scale, float scale_x, float scale_y, Nothing scale_z, int index){
67  :     float len = get_rotation_len(rotation);
68  :     return vec3(scale_x,scale_y, len);
69  : }
70  : vec3 _scale(vec3 scale, Nothing scale_x, Nothing scale_y, Nothing scale_z, int index){
71  :     float len = get_rotation_len(rotation);
72  :     return vec3(scale.xy, scale.z*len);
73  : }
74  :
75  : in vec4        color;
76  : uniform Nothing    color_map;
77  : uniform Nothing    intensity;
78  : uniform Nothing   color_norm;
79  :
80  : float get_intensity(vec3 rotation, Nothing position_z, int index){return length(rotation);}
81  : float get_intensity(vec2 rotation, Nothing position_z, int index){return length(rotation);}
82  : float get_intensity(Nothing rotation, float position_z, int index){return position_z;}
83  : float get_intensity(vec3 rotation, float position_z, int index){return position_z;}
84  : vec4 color_lookup(float intensity, sampler1D color_ramp, vec2 norm);
85  :
86  : vec4 _color(vec3 color, Nothing intensity, Nothing color_map, Nothing color_norm, int index, int len);
87  : vec4 _color(vec4 color, Nothing intensity, Nothing color_map, Nothing color_norm, int index, int len);
88  : vec4 _color(Nothing color, float intensity, sampler1D color_map, vec2 color_norm, int index, int len);
89  : vec4 _color(Nothing color, sampler1D intensity, sampler1D color_map, vec2 color_norm, int index, int len);
90  : vec4 _color(Nothing color, Nothing intensity, sampler1D color_map, vec2 color_norm, int index, int len){
91  :     return color_lookup(get_intensity(rotation, position_z, index), color_map, color_norm);
92  : }
93  :
94  : uniform vec4 stroke_color;
95  : uniform vec4   glow_color;
96  :
97  : uniform uint objectid;
98  : uniform int len;
99  :
100 : out uvec2 g_id;
101 : out int   g_primitive_index;
102 : out vec3  g_position;
103 : out vec4  g_offset_width;
104 : out vec4  g_uv_offset_width;
105 : out vec3  g_rotation;
106 : out vec4  g_color;
107 : out vec4  g_stroke_color;
108 : out vec4  g_glow_color;
109 :
110 :
111 :
112 : void main(){
113 :     int index         = gl_VertexID;
114 :   g_primitive_index = index;
115 :     vec3 pos;
116 :     pos = vec3(position  );
117 :     g_position        = pos;
118 :     g_offset_width.xy = offset.xy;
119 :     g_offset_width.zw = _scale(scale, scale_x, scale_y, scale_z, g_primitive_index).xy;
120 :     g_color           = _color(color, intensity, color_map, color_norm, g_primitive_index, len);
121 :     g_rotation        = _rotation(rotation);
122 :     g_uv_offset_width = uv_offset_width;
123 :     g_stroke_color    = stroke_color;
124 :     g_glow_color      = glow_color;
125 :
126 :     g_id              = uvec2(objectid, index+1);
127 : }
128 :
WARNING: shader C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\sprites.vert didn't compile.
ERROR: 0:68: 'get_rotation_len' : no matching overloaded function found (using implicit conversion)
ERROR: 0:68: 'get_rotation_len' : function is not known
ERROR: 0:72: 'get_rotation_len' : no matching overloaded function found (using implicit conversion)
ERROR: 0:72: 'get_rotation_len' : function is not known
ERROR: 0:91: 'get_intensity' : no matching overloaded function found (using implicit conversion)
ERROR: 0:91: 'get_intensity' : function is not known
ERROR: 0:122: '_rotation' : no matching overloaded function found (using implicit conversion)
ERROR: 0:122: '_rotation' : function is not known
ERROR: 0:121: 'assign' :  cannot convert from 'const highp float' to 'varying 3-component vector of highp float'

ERROR: LoadError: program 34 not linked. Error in:
C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\fragment_output.frag or C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\util.vert or C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\sprites.geom or C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\sprites.vert or C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\..\assets\shader\distance_shape.frag
Attached vertex shader is not compiled.

Stacktrace:
 [1] compile_program(::Array{GLAbstraction.Shader,1}, ::Array{Tuple{Int64,String},1}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLAbstraction\src\GLShader.jl:205
 [2] (::GLAbstraction.##78#84{Dict{Symbol,Any},NTuple{5,String}})() at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLAbstraction\src\GLShader.jl:270
 [3] get!(::GLAbstraction.##78#84{Dict{Symbol,Any},NTuple{5,String}}, ::Dict{Any,GLAbstraction.GLProgram}, ::Tuple{NTuple{5,String},Array{Array{String,1},1}}) at .\dict.jl:449
 [4] gl_convert(::GLVisualize.GLVisualizeShader, ::Dict{Symbol,Any}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLAbstraction\src\GLShader.jl:262
 [5] GLAbstraction.RenderObject(::Dict{Symbol,Any}, ::GLVisualize.GLVisualizeShader, ::GLAbstraction.StandardPrerender, ::Void, ::Reactive.Signal{GeometryTypes.HyperRectangle{3,Float32}}, ::Void) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLAbstraction\src\GLTypes.jl:308
 [6] assemble_robj(::Dict{Symbol,Any}, ::GLVisualize.GLVisualizeShader, ::Reactive.Signal{GeometryTypes.HyperRectangle{3,Float32}}, ::UInt32, ::Void, ::Void) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\utils.jl:36
 [7] assemble_shader(::Dict{Symbol,Any}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\utils.jl:63
 [8] visualize(::Any, ::GLAbstraction.Style{:default}, ::Dict{Symbol,Any}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\GLVisualize\src\visualize_interface.jl:21
 [9] (::GLVisualize.#kw##visualize)(::Array{Any,1}, ::GLVisualize.#visualize, ::Any, ::Symbol) at .\<missing>:0
 [10] MakiE.TextBuffer(::GeometryTypes.Point{3,Float32}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\MakiE\src\primitives\text.jl:25
 [11] #axis#126(::Array{Any,1}, ::Function, ::MakiE.Node{Tuple{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}},Base.#identity}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\MakiE\src\axis.jl:92
 [12] axis(::MakiE.Node{Tuple{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}},Base.#identity}) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\MakiE\src\axis.jl:92
 [13] #axis#125(::Array{Any,1}, ::Function, ::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::Vararg{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},N} where N) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\MakiE\src\axis.jl:88
 [14] axis(::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::Vararg{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},N} where N) at C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\MakiE\src\axis.jl:88
 [15] include_from_node1(::String) at .\loading.jl:569
 [16] include(::String) at .\sysimg.jl:14
while loading C:\Users\PetrKrysl\AppData\Local\JuliaPro-0.6.0.1\pkgs-0.6.0.1\v0.6\MakiE\docs\src\examples\surfacelink.jl, in expression starting on line 23

julia>

The window that popped up did display a colored surface and a yellow wireframe grid.

views (and scattermesh)

What a piece of work: Impressive examples and a real documentation!
I wanted to know if there is already a convenient way with MakiE to switch from 3D to 2D view?
Less crucial, I wonder if there is some plan to extend the possibilities of the meshscatter function. In a call like

meshscatter(positions, color = colorsG, marker = sphere_mesh)

a set of different spheres is drawn with respect to different centers in the positions list. Would it be possible to generalize this for spheres with different radii? Analogously, it would be great to have such a possibility for attributes of different GeometryTypes: for instance Cylinders require 2 positions, etc.

rename linesegment -> linesegments

continuous lines are plotted with lines, it seems more consistent to plot a collection of segments with linesegments rather than the current linesegment. One weirdness is that GLVisualize seems to use :linesegment for its style description, so I'm not sure if you want to leave GLVis as it is and translate, or make the change to both packages. (or leave everything as it is and close the issue) :)

mouse sensitivity too high when rotating 3D scene

MWE:

using Makie, GeometryTypes, Colors

scene = Scene()
dots = scatter(rand(10), rand(10), rand(10))
center!(scene)

When I click and drag on the scene window, it rotates very quickly (about 1cm is a full rotation). I have a relatively high DPI screen, so if it's measuring mouse movement in pixels that would make it more sensitive.

GPU-less install

One of the great things about Plots.jl's setup is it can install pretty much anywhere because the extra functionality is all provided by backends. I can't see getting Makie.jl to work on my friendly neighborhood cluster, while GR works fine. And then there are cases where there's no access to OpenGL (without VirtualGL), but other options like Plotly works.

Will there be a nice way to be able to install Makie in those setups? I like the GLVisualize-first approach and think it makes a lot of sense to ensure that there's a fully complete and fully Julia backend, but at the same time it limits the usefulness if it has to be directly required.

install Pkg.checkout("name") first

My install worked with checking out the main branch before checking out the makie branch. (v0.6)

Pkg.clone("https://github.com/SimonDanisch/Makie.jl.git")
Pkg.checkout("GLAbstraction")
Pkg.checkout("GLAbstraction", "sd/makie")
Pkg.checkout("GLVisualize")
Pkg.checkout("GLVisualize", "sd/makie")

# For UV examples, e.g. earth texture on sphere, or textured cat
Pkg.checkout("MeshIO")
Pkg.checkout("MeshIO", "sd/objuv")
Pkg.checkout("GeometryTypes")

# For image loading
Pkg.add("ImageMagick")

# For precompilation
Pkg.clone("https://github.com/SimonDanisch/PackageCompiler.jl.git")
Pkg.build("PackageCompiler")
Pkg.checkout("StaticArrays")
Pkg.checkout("GLWindow")
Pkg.checkout("GLWindow", "sd/static")
Pkg.checkout("GLFW")

various InterruptException issues

This isn't quite MWE, but this sort of thing tends to cause problems:

using Makie

s = Scene()
hm = heatmap(rand(32, 32))

for _ in 60000
    hm[:heatmap] = rand(32, 32)
    sleep(0.001)
    # press Ctrl-C to interrupt this thing
end

One behavior I've seen here is that it spits out an endless stream of "Message Queue is full" messages that stop when I close the scene window, but then start again when I create a new scene, and I need to restart the Julia process. I've also seen a similar thing where it just takes a long time for Julia to print out all the queued-up warning messages.

One solution to some of the message queuing error messages might be to only print the warning when the queue goes from the not-full to full state, and not every time a message tries to post to the full queue.

Another thing I've seen happen is that the window freezes and is un-closeable (pressing the X doesn't do anything). Is it possible that whatever loop is handling the close event could get interrupted.

Part of this would be helped if something like this is implemented on the Base side, but it still seems like maybe there are some places Makie could clean up better on an InterruptException.

lighting attributes

Can we access/modify the lighting/reflectance properties of an object/mesh in Makie?

axis broken

Since recent updates, axis seems to be broken

julia> r = linspace(-0.5, 2.5, 4);
julia> Makie.axis(r, r, r)
ERROR: MethodError: Cannot `convert` an object of type GLAbstraction.GLBuffer{Float32} to an object of type Float32
This may have arisen from a call to the constructor Float32(...),
since type constructors fall back to convert methods.
Stacktrace:
 [1] signal_convert(::Type{T} where T, ::GLAbstraction.GLBuffer{Float32}) at $HOME/.julia/v0.6/GLAbstraction/src/GLUtils.jl:112
 [2] macro expansion at $HOME/.julia/v0.6/GLAbstraction/src/GLUtils.jl:185 [inlined]
 [3] _default(::GLAbstraction.GLBuffer{GeometryTypes.Point{3,Float32}}, ::GLAbstraction.Style{:linesegment}, ::Dict{Symbol,Any}) at $HOME/.julia/v0.6/GLVisualize/src/visualize/lines.jl:114
 [4] default(::Any, ::Any, ::Any) at $HOME/.julia/v0.6/GLVisualize/src/visualize_interface.jl:4

I suspect it may be related to this PR but was not able to go further.

Scene magic

As @Evizero pointed out in JuliaPlots/Plots.jl#392:

for what its worth, the way scene = Scene() seems to affect global state already seems very magical to me. then again i suppose Plots does the same thing

I agree with that and I meant to discuss the magic we actually want here ;)
I have a few ideas and problems which I wanted to write down.

Should Scene() open a new window? I'm thinking about having it create a new tab as well
I was planning to make scatter(name = :myname); scatter(name = :myname) overwrite the first plot, while without having the same name they would get added with a unique default name (:scatter1, :scatter2, ...). I'm not sure if that isn't too quirky, and if that shouldn't mean that Scene() without a new unique name shouldn't create a completely new scene! But I also want an easy way to replace a scene that is meant to take the same place. I could even reuse the GPU objects in that case, making the example even more efficient.

Recipes

I don't want to derail any further JuliaPlots/Plots.jl#392.

Let's use this issue to collect feedback about various ways to make recipes.

This version of MakiE recipe:

function MakiE.to_mesh(b, m::typeof(lakemesh)) 
    vertices = map(1:size(m.node, 1)) do i
        Point3f0(ntuple(j-> m.node[i, j], Val{2})..., 0)
    end
    triangles = map(1:size(m.elem, 1)) do i
        GLTriangle(Int.(ntuple(j-> m.elem[i, j], Val{3})))
    end
    GLNormalMesh(vertices, triangles)
end

is implemented as

Typ = typeof(lakemesh)
@recipe function f(m::Typ) 
    vertices = map(1:size(m.node, 1)) do i
        Point3f0(ntuple(j-> m.node[i, j], Val{2})..., 0)
    end
    triangles = map(1:size(m.elem, 1)) do i
        GLTriangle(Int.(ntuple(j-> m.elem[i, j], Val{3})))
    end
    GLNormalMesh(vertices, triangles)
end

@mkborregard thinks:

To me, the@recipe macro just signals to me that this is a recipe, and I can trust it to Just Work(TM).

Not sure why the last bit is important. I just think, that the recipe macro is less generic, doesn't compose that well and is unnecessarily opaque. A well known generic construct like overloading a method seems to me much more trustworthy and future proof.

E.g. you can compose them like this:

struct MyType end
to_color(x::MyType) = RGB(rand(), rand(), rand())
lines(x, y, colormap = [MyType() for i = 1:10])

This works, since to_colormap falls back to to_color.(array). Similarly this can be used in other situations. I'm actually already heavily using this kind of composition internally!

Anyways, I don't think that the details are very important right now.
What I plan to do is rethink these concepts freely, and when we do the refactor, I want to reevaluate my solutions and the ones in Plots.jl - and hopefully get a ton of unbiased feedback! :)

Based on that we can decide what we should keep! So it would be best if we just have people open mindedly play around with MakiE, and then just write down what isn't working for them! I will do my best to document those features, so that people trying thinks out have an easy start!

support `lines(ys)`

Sometimes I have a vector of floats I want to quickly plot, e.g. lines(rand(20)). I'm not sure if this will conflict with lines(positions) usage, but maybe if it dispatches on ::Vector{<:Real} or something it could be unambiguous.

String as marker

It would be nice to use Strings as markers in scatter.
https://github.com/SimonDanisch/Makie.jl/blob/cef849737a6833c2b96987025c1b90bf4ec1da25/src/plotsbase/converts.jl#L324 also seems strange. Cheers

Trouble with to_world

I'm trying to run the following example. The highlighted line is causing an error. to_world doesn't like the symbol :auto for the camera argument ("ERROR: type Symbol has no field view").

https://github.com/JuliaPlots/Makie.jl/blob/master/docs/src/examples/scattermouse.jl#L13

turn around

Is there a convenient way to rotate a camera around an object/mesh with Makie ?
Not really an issue, sorry.

Axis freezes when one axis is a integer range

E.g.

axis(8:11, 8:1.0:10.0, 8.0:1.0:10.)

Feature request: default names to axis

There are case where, from the function call, the plotting package can determine how to label the axis and the legend:

when using the @df macro in StatPlots to plot columns a data table: the axis should be labelled with the appropriate column label
when using some macro mechanism, for example @label plot(X, [Z, logistic.(Z)]) (see #1072 ) could create a legend with entries Z and logistic.(Z)

The difficulty with implementing this is that the translation from the argument names (as visible at "macroexpand" time) to the axis of the plot is not straightforward (for example plot(y) should have a y axis label and density(y) should have a x axis label) which makes these macros tricky to write.

The best solution we could find was to add a _default_names keyword argument to all plot calls, which would take all the extra label info from the macro (basically all the names of the main arguments, which could correspond to x,y, z or to the legend if the user is passing a vector of vectors such as [Z, logistic.(Z)]), combine it with the label explicitly provided by the user (which should have priority) and label the plot appropriately. Then writing these macros becomes very simple.

It could be a bit painful to add this _default_names keyword a posteriori so I thought I should mention it already.

See here for previous discussion.

scatter(pos) results in StackOverflowError

I tested the package using Pkg.test("MakiE") and the test fails with StackOverflowError.
The issue is happening at the instruction pscat = scatter(pos).
I'm on Windows 10 with julia 0.6.0.

mouse rotation not active

It happens quite frequently that it is not possible to rotate the scene with the mouse whereas zooming in or out is always possible. I am on linux with GLFW 1.4.1 master + glfw-3.2.1.
Sometime rotation woks perfectly on the same scene..
I do not know which experiments/information could help to identify the problem..

Scene() -> Segmentation fault

I've reproduced this across two different computers.
One running Ubuntu, the other Fedora.
Both are using Julia v0.6.2, and have AMD graphics cards.

julia> using Makie
 
julia> scene = Scene()
Segmentation fault (core dumped)

julia> Pkg.test("Makie")
INFO: Computing test dependencies for Makie...
INFO: No packages to install, update or remove
INFO: Testing Makie
================================================================================================================[ ERROR: Makie ]================================================================================================================

failed process: Process(`/home/chris/Documents/prog/julia-dev/julia/usr/bin/julia -Cnative -J/home/chris/Documents/prog/julia-dev/julia/usr/lib/julia/sys.so --compile=yes --depwarn=yes --check-bounds=yes --code-coverage=none --color=yes --compilecache=yes /home/chris/.julia/v0.6/Makie/test/runtests.jl`, ProcessSignaled(11)) [0]

================================================================================================================================================================================================================================================
INFO: No packages to install, update or remove
ERROR: Makie had test errors

I am on the latest master of Makie and GLVisualize.

Any suggestions? Segfaults don't give much guidance on where to look.
If I can help by running or check anything, let me know.

change light of a scene

the key :light is not a Node which makes it static. Is it on purpose?

Plot object and Plots.jl compatibility

Following the discussion at #918, I wanted to discuss more in detail the following two points:

what is a (backend independent) plot object (as in Plots.Plot)?
to what extent this representation is compatible with

To clarify the first question, in Plots.jl a user command (say plt = scatter(rand(10, 2), markershape = :circle, color = :blue)) goes to a pretty sophisticated pipeline, at the end of which we get a "backend independent" plot object, where all the relevant information to display it is encoded explicitly.

I'd like to understand what is the equivalent of that in MakiE. The main thing that I could find is the Scene type. It is not completely obvious how everything is encoded there. It seems that the series are somehow encoded in the various scene.data[:scatter] entries, but I couldn't quite figure out how.

Also, I'm not entirely sure as to how the "interlinked" nature of the attributes is encoded in a Scene object. I'm assuming it is implemented with the MakiE.Node objects but I couldn't quite understand how (here's a relevant discussion in Plots: #1149), so docs on MakiE.Scene and MakiE.Node would be extremely appreciated.

The reason to ask all of this is to be able to build a constructor

function MakiE.Scene(plt::Plots.Plot)
    ...
end

so that in the future it will be possible to include your work on MakiE in the Plots echosystem.

`scene[:time]` doesn't update for 2nd scene

MWE:

using Makie

scene = Scene()
t = linspace(0,4pi,100)
y = lift_node(scene[:time]) do phase
    cos.(t .+ phase*2pi+1)
end
lines(t, y)
center!(scene)

When you run this the 1st time you see a sinusoid moving across the screen. Running it again (e.g. from the REPL or Atom) the wave displays but doesn't move.

Unexpected position of 2D Axis ticks labels

The example scattermouse.jl give me a result which is different compare to the one showed in the README.
The position of the x and y axis ticks labels are respectively on the upper side and on the right side instead of being in the lower and the left side.

Issues with window/frame sizes

This is a continuation of issue #207 on GLVisualize.jl, but I want to focus on its manifestation in MakiE so as to use the newest interfaces. To provide a step-by-step of what I've done so far:

julia> using MakiE

julia> scene = Scene()

This creates the following blank scene:

Using the scene.data dictionary, we can see the current parameters for the window and the frame:

julia> scene.data[:window_size]
2-element MakiE.ArrayNode{Int64,1,Base.#identity,GeometryTypes.Vec{2,Int64}}:
 840
 525

julia> scene.data[:window_area]
<Node: GeometryTypes.SimpleRectangle{Int64}(0, 0, 840, 525)>

julia> scene.data[:framebuffer_size]
2-element MakiE.ArrayNode{Int64,1,Base.#identity,GeometryTypes.Vec{2,Int64}}:
 1680
 1050

If I change the window size at all, the window seems to adjust to the correct size:

Not the most exciting visualization, but running the same Julia commands:

julia> scene.data[:window_size]
2-element MakiE.ArrayNode{Int64,1,Base.#identity,GeometryTypes.Vec{2,Int64}}:
 846
 530

julia> scene.data[:window_area]
<Node: GeometryTypes.SimpleRectangle{Int64}(0, 0, 1692, 1060)>

julia> scene.data[:framebuffer_size]
2-element MakiE.ArrayNode{Int64,1,Base.#identity,GeometryTypes.Vec{2,Int64}}:
 1692
 1060

The main observation here is that in the first case, window_area matches the value of window_size, but after resizing the frame, window_area matches framebuffer_size. I've tried to hunt down the logic for initializing and later updating window_area, since it seems to be the parameter linked to this behavior, but admittedly I'm kind of running in circles. Hopefully this is enough evidence to point to a culprit, and if there's more I can provide I'd be happy to do so.

A place to discuss architecture.

In plotting and especially in interactive plotting, sooner or later the generalized problem end up in providing a means of a scene graph that is rendered and displayed. Have you thought about splitting into a OpenGL compositor and the plotting part? I'm asking this after reading: https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/

meshscatter function broken ?

Last update of MakiE seems to have broken meshscatter function

using MakiE, GeometryTypes, Colors, Interact
scene = Scene(resolution = (500, 500))
large_sphere = HyperSphere(Point3f0(0), 1f0)
positions = decompose(Point3f0, large_sphere)
meshscatter(positions, color = RGBA(0.9, 0.2, 0.4, 1))
scene

gives

ERROR: MethodError: no method matching vec2quaternion(::Reactive.Signal{GeometryTypes.Vec{4,Float32}})
Closest candidates are:
  vec2quaternion(::StaticArrays.StaticArray{Tuple{4},T,1} where T) at $HOME/.julia/v0.6/GLVisualize/src/visualize/particles.jl:255
  vec2quaternion(::StaticArrays.StaticArray{Tuple{3},T,1} where T) at $HOME/.julia/v0.6/GLVisualize/src/visualize/particles.jl:258
...

axis labels too small for large axes

this example from the docs is fine:

using Makie
scene = Scene(resolution = (500, 500))
aviz = axis(linspace(0, 2, 4), linspace(0, 2, 4))
center!(scene)

but if you make the axis larger the labels get very small, e.g. aviz = axis(linspace(0, 20, 4), linspace(0, 20, 4))

System image transfer

Hi,

Thank you for the fix in Precompile... Following up with

# or the safer option:
ENV["MAKIE_COMPILE"] = "build" # just builds a system image the needs to be added manually
Pkg.build("Makie") # can take around ~20 minutes

where are we supposed to put the system image? What is the 'exact' procedure?

Thank you again for your help,

Best regards

support `:offset` attribute more widely

After recently learning about the handy :offset attribute, I quickly tried to use it in some other contexts and it doesn't seem to be supported. I tried creating 2 offset axes:

scene = Scene()
ax1 = axis(0:10, 0:10, offset=Point2f0(0, 0))
ax2 = axis(0:10, 0:10, offset=Point2f0(12, 0))
center!(scene)

but only saw one, I also tried layout out a grid of heatmaps:

scene = Scene()
for i in 1:2, j in 1:2
    heatmap(rand(5, 5), offset=Point2f0(i*8, j*8))
end
center!(scene)

but also only saw one.

Transition to Plots.jl

Considering that MakiE is designed quite differently from Plots.jl, any transition to Plots.jl will
basically mean replacing Plots.jl. I don't see how to slowly incorporate ideas from MakiE into Plots.jl without a huge amount of work. I think we're at a good time to still make drastic much needed changes, so we shouldn't try to be conservative here.

So I propose to let MakiE live as it's own package for a while until we can ensure, that all features from Plots.jl are well covered.
Then we can think about renaming MakiE, make a PR to Plots.jl to replace the internals with MakiE or simply deprecate Plots.jl and suggest to move to MakiE.

This would look something like this:

Pre release MakiE (should happen today)
Implement some more high level recipes from Plots.jl
Introduce a compatibility layer for PlotsRecipeBase to see if MakiE support the whole range of features used in packages
factor out MakiE Plotsbase into an abstract plotting package with no dependencies
Create backend packages
Refactor into packages - replace/rename Plots.jl with new internals

Other backends

I'm inclined to implement a reference backend different from GLVisualize with Cairo. I already have some code for this from my experiments in Visualize.jl.
Cairo is completely orthogonal to GLVisualize and offers missing bits and pieces like PDF/SVG export.
The orthogonality seems to be an important quality for different backends to make the choice of backends clearer to the user.

Since GR is the favorite Plots.jl backend, it would also make sense to start with GR as a reference implementation.
It's less orthogonal and I'm not as familiar with the API, though.
But if @jheinen is on board and willing to help me out, this could also be a great start!

cc: @daschw @mkborregaard @piever @ChrisRackauckas @Evizero @ViralBShah

Missing function?

test failures on my machine

I'm not sure if the expectation is that other folks can run the test suite at the moment, but if so I'm having some trouble.

My test output is here. The first couple failures seem to be where the images don't match, but without much of a useful error message. Then some shaders aren't linking, with errors like:

program 84 not linked. Error in: 
  /home/sfr/.julia/v0.6/GLVisualize/src/../assets/shader/fragment_output.frag or /home/sfr/.julia/v0.6/GLVisualize/src/../assets/shader/util.vert or /home/sfr/.julia/v0.6/GLVisualize/src/../assets/shader/uv_normal.vert or /home/sfr/.julia/v0.6/GLVisualize/src/../assets/shader/standard.frag
  error: fragment shader input `o_color' has no matching output in the previous stage

Interactivity in IJulia, resp. WebGL-support

Are there any plans to support interactivity and things like rotating 3D-plots in IJulia? I guess WebGL would be they way to go, but I don't know about the state of WebGL-support in GLVisualize.

I think this would be a very important feature - more and more, people will run computations on large (and powerful) remote machines - and while there are solutions for remote-display OpenGL, they all require quite a bit of machinery on both server and client side.

Grammar of graphics API

I think we should make sure that this all has a grammar of graphics API on it as an extra convenience since a lot of data scientists are adamant on using it.

One-off error in either heatmap or image?

Steps to reproduce on a hopefully not too old master (around christmas)

scene = Scene(resolution = (500, 500))
heatmap(rand(32, 32))
image(map(x->RGB(x,0.5, 0.5), rand(32,32)))