Basic VTK visualisation widget for Raysect scenegraphs

[mattngc]

Raysect really needs some kind of interactive visualisation GUI. A lot of our less experienced users struggle to visualise the scenes in their head and often make basic errors with the transformation matrices. A lot of this could be solved quickly by having a simple GUI for visualisation a Raysect scene. Ideally it would allow you to:

• eyeball the primitives to check they are in approximately the expected positions.
• click on primitives to inspect their material properties (no editing of properties).
• click on triangles in primitives and meshes to extract basic geometric information.

In future one could add basic interactivity, such as updating transforms and having those properties carry through to the Raysect scenegraph. For anything more advanced, a more advanced engine such as blender may be more appropriate.

This might also enable inherited widgets providing more specific functionality, such as inspecting bundles of ray paths, etc.

[mattngc]

After careful review I believe Mayavi is the most appropriate lightweight(ish) module for scenegraph visualisation in Raysect. It will allow visualisation of scenes with matplotlib style commands.

Most of the tools we need are already there or relatively straight forward. The biggest obstacle is the need for more advanced triangular mesh utilities. The most important ones are:

• triangle-triangle intersection
• vertex welding
• mesh subdivision

I've done some experiments in a private repository already, https://github.com/mattngc/raysect_mayavi. I will start copying over the relevant code into isolated branches and raise tickets as appropriate.

[mattngc]

We also need some code to generate an equivalent Mesh for every Raysect primitive. Most are fairly simple, by far the most complicated is the Mesh CSG operator. These will be tracked in separate tickets.

[mattngc]

@CnlPepper, if you check out f0703c6 you should be able to run the CSG visualisation demos yourself. I've added all the utility functions on separate branches so we can test and merge them separately.

[mattngc]

I suggest we start with #277 and #278 as both are fairly atomic and reasonably easy to implement.