the initial plan

[j-fu]

I want to do my Winter21/22 Scientific Computing lecture based on this, so I probably will have this
in late summer 2021. Any acceleration depends on volunteers.

I now prefer plotly over canvas for the 1D plots.

Basic APIs are vector/matrix based. GeometryBasics based stuff on top of that if needed.

Isoline/isosurface/slice code is available from GridVisualize.jl

• join plotly and vtk APIs

• 1D API/Plotly

  • plot(x,y, kwargs...)
  • semilogx(x,y, kwargs...) (via x/y scale kwarg)
  • semilogy(x,y, kwargs...) (via x/y scale kwarg)
  • loglog(x,y, kwargs...) (via x/y scale kwarg)

• 2D API/vtk.js: Combination of PyPlot-like contour and contourf

  • contour(x,y,f, kwargs...) based on tricontour
  • tricontour(xy,tri,f; kwargs...)
  • colorbar via canvas
  • trimesh(xy,tri;kwargs...)
  • quiver2d(xy, v)

• 3D API/vtk.js

  • contour(x,y,z,f; kwargs...) based on tetcontour
  • tetcontour(xyz,tet,f; kwargs...)
  • tetmesh(xyz,tet; kwargs)
  • colorbar via canvas
  • quiver3d(xyz, v)

• nice to have

  • surface(x,y,f, kwargs...), trisurface(xy,tri,f, kwargs...) via vtk.js
  • Compatibility with GridVisualize
  • Several plots in a row
  • PNG/SVG download
  • Streamline plots

EDIT: updated 2021-06-03, 2021-06-22, 2021-08-18, 2021-10-14

[juliohm]

Is there any way to plot Meshes.jl objects directly with PlutoVista.jl or the scope of the project is tied to a specific mesh package?

[j-fu]

My intention is not to tie this to any particular mesh structure. I think it is difficult to reconcile all kinds of ideas about how to store meshes into one standard. I envision something like a "GridRosetta.jl" to mange this.

Currently this packages is used as one of the backends for GridVisualize.jl with ExtendableGrids.jl as mesh data structure wich I maintain together with @chmerdon. There, all data and incidences are stored as (dense or sparse) matrices. This way things come out of Triangle and TetGen as well.

As far as I understend, Meshes.jl stores coordinates as vectors of points, these can be viewed as matrices via reinterpret . May be a similar approach is possible with triangle or tetrahedron connectivities. So I think you can create the data for plotting via this interface on the fly with barely no cost.

Based on this, my long time intention is to use Requires.jl either here, but, preferrably, in GridVisualize to add addtional API components which can take in other mesh types. However I have no resources for doing this by myself, but would be happy to take in corresponding PRs and modify things to make this work.

[juliohm]

Thank you @j-fu , appreciate the clarifications.

[juliohm]

@j-fu any reason to not use Plotly for 3D mesh visualization? I am asking because I am evaluating alternatives to Makie.jl and Plotly seems quite popular in other areas. I wonder why you decided to choose vtk.js instead for 3D?

[j-fu]

Due to previous experience in C++ vtk, see https://j-fu.github.io/VTKView.jl/dev/vizcon2/ vtk is closer to me.

With vtk.js I get the performance I wanted for moving cutplanes and isosurfaces via sliders.

I tried 2d trisurf (ak triplot) in plotly, and so far had the impression that the performance is not that good, but this is not a final conclusion.

In the moment I am touching up the plotly backend for 2D (heatmap + isolines), and it starts to become reasonable
(and, well, it has hover...). Would tag this in the next couple of days.

So it is not unreasonable to continue trying for 3D plotly. vtk shows which performance should be achieved, and besides of missing antialiasing, the rendering quality is quite good. All isosurface calculation is done in Julia with the marching tetrahedra code I wrote in GridVisualize.

It is important to be sure that webgl is used.

At the level of PlutoVistaPlot one can say backend=:plotly to switch to plotly, and therefore it is easy to develop and test a tetcontour version for plotly.

It also would be possible to switch defaults at some moment without changing the API.

[j-fu]

As for Makie, I am in contact with @SimonDanisch , he has big plans, including reduction of compile times and WGLMakie in Pluto. GridVisualize.jl has a Makie backend with the same features as here which (once compiled) performs very well. So outside of Pluto this is definitively worth to be considered, and may be we will se WGLMakie (based on three.js) beating vtk and plotly. Therefore GridVisualize for me is the API to go, as it is designed to take whatever backend is the best.