I've been working on something similar.

https://github.com/fogleman/pg

Here are a couple of things I've created using it so far, beyond what's in the pg examples folder:

http://www.michaelfogleman.com/hirise/

http://www.michaelfogleman.com/gps/

it looks cool but it takes the control of the main loop, no ? The ability to integrate an OpenGL scene in another framework in critical.

I knew I liked vispy after I spent some time to write this Mandelbrot set example [1]. I only knew a little bit of OpenGL, and it took me less than a day to understand vispy's API and create it. This was also before the new scenegraph functionality was rolled out (the example is based on the core app and gloo modules).

The core development team is very receptive to issues and pull requests. They all also have experience building their own Python visualization libraries, so it's exciting to see how their ideas synthesize into vispy features.

[1] http://vispy.org/examples/demo/gloo/mandelbrot.html

Anyone know how this compares to Mayavi?

Is it targeting different use cases, or just higher performance, or ...?

Vispy dev here. Mayavi/VTK are mature, very powerful and feature-complete. Vispy is not even close to offer the same amount of functionality. But eventually, we hope it will.

The low-level OpenGL interfaces in Vispy are now relatively solid, and are the foundations of higher-level, more abstract graphical interfaces we are currently developing (similar to VTK and Mayavi). Our goal is to let scientists easily create fast interactive visualizations in 2D and 3D without any knowledge of OpenGL.

Here is a very early example of these higher-level interfaces: http://vispy.org/examples/basics/scene/surface_plot.html We also have started to work on an OpenGL backend for matplotlib.

Finally, a few remarks:

* Vispy focuses on performance and big datasets (with tens of millions of points or more) with minimal memory footprint (using NumPy)

* Vispy is pure Python and depends just on NumPy, basically. VTK is a heavy C++ library, sometimes complicated to install.

Mayavi is based on VTK, which is a C++ toolkit for data visualization. It's both an advantage and a drawback, depending on your needs. The good thing is that VTK is solid and if you're familiar with the concepts, it can be powerful, but it's also somewhat complex. On the other hand, the python (traits) wrapper around VTK that mayavi is built upon adds another layer of abstraction and changing things that aren't directly exposed by mayavi is difficult.

From a quick look, vispy seems to be built directly on OpenGL and numpy, so I think it will be easier to customize. But the devs will have to rewrite a lot of what VTK provides. It also aims at providing an integration in ipython notebook (with WebGL), which is awesome :)

A lot of time was spent fleshing out the core "gloo" module, which is an object-oriented abstraction of OpenGL. If you know OpenGL, you can create very high performance visualizations.

There is currently a lot of work on fleshing out the vispy.scene module, which will add more high-level interfaces for plotting data.

I was wondering the same. Mayavi seems more abstracted vs this is has more low-level opengl guts exposed

Vispy is what's been missing in the scientific python ecosystem, in my opinion. I've been watching the project closely for a good while, glad to see this release and will try it out as soon as possible.

There was an excellent VisPy talk at EuroSciPy, not sure if Enthought has already put the video on youtube. The team behind VisPy is excellent, and they are doing really good work of making OpenGL usable from a high level language.

Gloo looks like a superior alternative to the clunky pyopengl package.

Do you plan to distribute it separatly in the future?

That's something we've been considering, indeed. Especially given that we now ship our own OpenGL wrapper with ctypes.

In the meantime, you can just install vispy and import vispy.gloo: nothing else will be imported. The dependencies are the same (just NumPy).

FYI, although gloo's interface is now relatively stable, we're likely to change its internals very soon. This should lead to a cleaner, smaller, and more robust code base for gloo. There will be virtually no change for the user.