Makie is a new plotting library in need of tests and documentation.
One needs to go through all sections of the current documentation, make sure they are understandable and add examples to the documentation where necessary. Depending on how much time is left, there are endless opportunities to create impressive and creative plotting examples for the example database.
Expected Results: greatly improved documentations
Recommended skills: Attention to detail and a lot of experience with plotting.
Mentors: Simon Danisch
This project involves overloading the Makie API for backends to draw all the different plot types. You will start with a skeleton from already present backends, so it's about filling the gaps and making sure all tests pass for the new backend.
Expected Results: a fully working new backend to Makie
Recommended skills: One should be familiar with a graphics drawing API like Cairo or WebGL for this project.
Mentors: Simon Danisch
Plots.jl offers a lot of recipes. In Makie, we will need to make sure that they are available and work correctly. This project will involve writing a compatibility layer for PlotRecipes.jl and then making sure that all the recipes that are spread around the Julia plotting community work! Expected Results: porting and testing as many recipes as possible Recommended skills: Experience with Plots.jl would be great Mentors: Simon Danisch
We are working on deep refactor of GLAbstraction, to finally make a fully fledged, general purpose layer above OpenGL.
The work happens at this PR and has the following goals:
getting rid of Reactive/Color/ and other not strictly opengl related packages. Instead offer overloadable APIs to do the job
Introduce leaner VertexArray buffer, integrating nicely with view(buffer, faces). A mesh is then basically just view(vertices::Vector{Point3f0}, indices::Vector{GLTriangle})
Introduce UniformBuffers to hold state in shaders independent of executing the shader
Introduce lean RenderObject, that doesn't hold any data, besides information on the shader layout - data will get transferred via calling the object with new data. When uniformbuffers are used, data can also be updated in place
remove GLVisualize specific code, that was basically just parked here because I didn't had a better place to put it
Transpiler integration - make it the main way to create shaders, instead of having ugly templated shader that nobody understands
Besides Transpiler integration, a lot of those goals have been achieved and now effort needs to be put into writing tests and porting the packages that rely on GLAbstraction to work with the new API.
Expected Results: finishing the PR and making sure it works with dependant packages
Recommended skills: Requirement is a good understanding of OpenGL
Mentors: Simon Danisch
This project is about turning the current WebVisualize prototype into a fully featured webgl drawing API. To make things simple, we're using ThreeJS made accessible from within Julia with WebIO. The goal is to port most GLVisualize shaders so that we can offer exactly the same functionality. We want to use Transpiler to transpile the Julia shaders in Visualize.jl across platforms. This will enable us to generate webgl shaders and opengl shaders from the same Julia functions, which is crucial to keep maintenance low.
Expected Results: Turn the current prototype into a functioning package Recommended skills: Some OpenGL and Web (specifically ThreeJS) knowledge will be required. Mentors: Simon Danisch
The QML.jl package provides Julia bindings for Qt QML on Windows, OS X and Linux. In the current state, basic functionality is available, but there is room for improvement regarding integration with GLVisualize and plotting packages such as GR (see also issue 23) or Plots. Another area of work is supporting more elaborate data models.
Expected Results: Improvements to the QML.jl package along one of these lines.
Recommended Skills: Familiarity with both Julia and the QT framework.
Mentors: Bart Janssens
The VegaLite.jl package provides a Julia wrapper for vega-lite and vega. There are many areas that could be improved: 1) provide a more powerful vega API that is similar to the existing vega-lite API, 2) complete the vega-lite API (there are many corner cases that are not ideally handled right now), 3) make things work better for large datasets, 4) come up with a way to auto-convert/integrate the comprehensive vega-lite documentation into the VegaLite.jl documentation, 5) write more documentation, 6) increase test coverage or 7) add a simple non-grammar of graphics API.
Expected Results: Some subset of the list mentioned above.
Recommended Skills: Familiarity with Julia, vega-lite or vega, and Node.
Mentors: David Anthoff