makieorg / makie.jl Goto Github PK
View Code? Open in Web Editor NEWInteractive data visualizations and plotting in Julia
Home Page: https://docs.makie.org/stable
License: MIT License
Interactive data visualizations and plotting in Julia
Home Page: https://docs.makie.org/stable
License: MIT License
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/
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.
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.
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)
Line 18 in this example https://github.com/SimonDanisch/Makie.jl/blob/master/docs/src/examples/theming.jl seems to call an undefined function.
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.
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.
Is there a convenient way to rotate a camera around an object/mesh with Makie ?
Not really an issue, sorry.
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.
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)
The readme points to http://www.glvisualize.com/Makie.jl/stable/, but that appears to be down.
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.
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.
Scene()
open a new window? I'm thinking about having it create a new tab as wellscatter(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.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
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")
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.
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:
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
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.
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.
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..
Just went to use Makie
and got an error about an uninstalled package AbstractNumbers
. The dependency should be included in the REQUIRE
list.
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)
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
?
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))
Can we access/modify the lighting/reflectance properties of an object/mesh in Makie?
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.
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.
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.\
the key :light
is not a Node
which makes it static. Is it on purpose?
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?
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.
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.
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.
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
.
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
E.g.
axis(8:11, 8:1.0:10.0, 8.0:1.0:10.)
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!
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.
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.
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
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.
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
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) :)
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
Following the discussion at #918, I wanted to discuss more in detail the following two points:
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.
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.
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
...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.