Duh! I forgot to add all my new docs to the repo. I am a fool. Fixing…

… now.

doc/source/api_ref/core/index.rst

@@ -0,0 +1,12 @@
+
+============
+Raypier.Core
+============
+
+.. toctree::
+
+	ctracer
+	cmaterials
+	cfaces
+	cfields
+	tracer

doc/source/api_ref/faces.rst

@@ -0,0 +1,8 @@
+
+=============
+raypier.faces
+=============
+
+
+.. automodule:: raypier.faces
+	:members:

doc/source/api_ref/materials.rst

@@ -0,0 +1,7 @@
+
+=================
+raypier.materials
+=================
+
+.. automodule:: raypier.materials
+	:members:

doc/source/api_ref/shapes.rst

@@ -0,0 +1,8 @@
+
+==============
+raypier.shapes
+==============
+
+
+.. automodule:: raypier.shapes
+	:members:

doc/source/examples/michelson_interferometer_example.rst

@@ -0,0 +1,21 @@
+========================
+Michelson Interferometer
+========================
+
+We can create a Michelson interferometer from a non-polarising beam-splitter and two mirrors. The second mirror 
+has a spherical surface to generate a spherical wavefront at the detector-plane. The intensity distribution 
+shows the classic Newton's Rings type pattern.
+
+.. literalinclude:: /../../examples/michelson_interferometer_example.py
+
+The rendered model looks as follows:
+
+.. image:: ../images/michelson_example_model.png
+
+In this case, the E-field evaluation plane is large enough that we can see the intensity profile directly in the model. 
+However, viewing it in a :py:class:`IntensitySurfaceView` is more convenient.
+
+.. image:: ../images/michelson_example_irradience.png
+
+
+

doc/source/exploring_the_gui.rst

@@ -0,0 +1,44 @@
+=================
+Exploring the GUI
+=================
+
+Raypier is based on the Traits/TraitsUI framework. The Traits library provides a notification framework and improved type-declaration.
+TraitsUI is a GUI framework that extends Traits to make developing custom GUIs fast and easy. The UI for *any* traited object
+can be invoked with a call to my_object.configure_traits(). Typically, I recommend you define your base optical model in a 
+script where an instance of RayTraceModel is created, then launch ui GUI with a call to the model's configure_traits() method. Lets see 
+this in action. Running the michelson_interferometer_example.py script, you should see the following window
+
+.. image:: images/gui_example.png
+
+The main window is divided into 4 main regions. At the upper left, we have the main 3D model view. <left-click>-drag to rotate the view,
+<middle-click>-drag to pan and <right-click>-drag to zoom. You can also zoom using the mouse-wheel.
+
+The upper right panel shows the model tree, with sub-groups for each of the model components types. Selecting any one model component
+object displays the properties-view for that object in the lower-right panel.
+
+Double-clicking any object in the tree-view will open another properties-view window. This is useful for when you want to have the properties
+of multiple objects open at once (N.B. this doesn't yet work for the *image view* and *surface view* objects. I plan to lift this
+restriction later on).
+
+For example, here's the properties view for the *Mirror 1* object:
+
+.. image:: images/property_window.png
+
+All property windows edit their objects "live". The model will re-calculate itself automatically whenever anything changes, so you can explore 
+how the ray-tracing results change as you move/adjust objects.
+
+The bottom-left region contains two tabs: a python console and the Constraints view. There is no constraints in the example shown.
+
+Within scope of the python terminal window, the model object is bound to the name *self*. While the rest of the model components 
+can be accessed from this reference, another way to access objects is to simply drag and drop items from the tree-view into the
+terminal window. These will be added to the local namespace of the terminal using either the name of the object (as given in the tree), 
+or, if the name is not a valid python name (e.g. it contains spaces) it will simply be called "dragged". 
+
+At the top of the main window there is a menu-bar with two menus. The *File...* menu lets you save/load models in YAML format. However,
+I strongly advise against using this as a means of persisting models. The internals of Raypier are under active development and 
+I don't give any guarantees that the YAML format is stable. I prefer to create my models as python scripts. This way, if the API
+changes, one can update the code to restore the model function. Whereas, if a class-name or API changes, a YAML file will
+simply refuse to load.
+
+Model components can be added from the "Insert..." menu. The delete  or rename components, use the context-sensitive menu in the 
+Tree View (<right-click> on a tree item). 

doc/source/ray_collections.rst

@@ -0,0 +1,49 @@
+
+=============================
+RayCollection and Ray Objects
+=============================
+
+The most important object in Raypier is the RayCollection. This is (as you might guess from the name) a 1D array of Ray objects.
+
+The Ray object (:py:class:`raypier.core.ctracer.Ray`) represents a single ray, and wraps an underlying C-structure. The single 
+Ray object exists as a convenience for python scripting. The actual ray-tracing operation operates only RayCollection objects.
+
+:py:class:`Ray` objects have the following attributes:
+
+* origin - A 3-vector (tuple) of floats giving the start-point for the ray
+* direction - A 3-vector giving the direction of the ray. This is always normalised to unit length
+* E_vector - A 3-vector defining the polarisation-axes. This vector is unit-length and orthogonal to the `direction` vector
+* normal - A 3-vector giving the unit-length surface normal of the face from which the ray originated. May be undefined for rays 
+  which have not originated from a face intersection
+* refractive_index - a complex value giving the refractive index of the material through which the ray has propagated
+* E1_amp - the complex electric field amplitude for polarisations parallel to the E_vector axis
+* E2_amp - the complex electric field amplitude for the polarisation orthogonal to the E_vector axis
+* length - the geometric length of the ray from it's start-point to its termination at an intersecting face (or may be
+  set to the `max length` of the ray, it no intersection has occured
+* phase - An additional phase-factor that may be introduced  by face interactions. Currently, only used to hold the
+  "grating phase" arising from diffraction-grating surfaces.
+* accumulated_path - the total *optical* path length accumulated from the parent ray plus (parent length * real part of 
+  refractive index)
+* wavelength_idx - a index into the wavelength list (held by both the RayCollection and/or source object)
+* parent_idx - the index of the parent-ray in the parent RayCollection object
+* end_face_idx - the index into the Global Face List of the face at which the ray terminates (i.e. intersects). The Global Face
+  List can be accessed on the `all_faces` atrtibure of the :py:class:`RayTraceModel` object.
+* ray_type_idx - a bitfield indicating is the ray is a reflected or transmitted ray. Other ray-types may be defined in future
+
+Rays have some additional read-only properties defined:
+
+* power - the sum of squares of the E1_amp and E2_amp components
+* amplitude - the square-root of the power
+* jones_vector - Returns a 2-tuple (alpha, beta) representing the Jones Vector describing the polarisation state of the ray.
+  See _https://en.wikipedia.org/wiki/Jones_calculus#Jones_vector
+* E_left - Returns the complex electric field amplitude for the left circular polarisation state
+* E_right - Returns the complex electric field amplitude for the right circular polarisation state
+* ellipticity - Returns the ratio of the power in the right-hand polarisation state to the left-hand polarisation state
+  I.e. A value of +1 indicates 100% right-circular polarisation, 0 indicates linear polarisation, -1 indicates 100% left
+  polarisation.
+* major_minor_axes - Returns a 2-tuple of unit-length vectors describing the major and minor polarisation axes
+
+RayCollection objects have substantially the same attributes/properties as the Ray object, except that each property
+returns a numpy array containing the values for all rays in the collection. 
+
+RayCollection objects are iterable (yielding single Rays) and subscriptable. 

doc/source/ray_sources.rst

@@ -0,0 +1,13 @@
+===========
+Ray Sources
+===========
+
+Ray sources generate the input rays for the model. The Ray-source objects also hold the results of the trace, in the 
+:py:attr:`traced_rays` attribute, as a list of :py:class:`RayCollection` objects. Each item in this list represents one "generation"
+of rays. 
+
+Ray source classes are subclasses of :py:class:`raypier.sources.BaseRaySource`. Besides generating the :py:attr:`input_rays` (a :py:class:`RayCollection`
+instance) attribute as the input to the model, and holding the trace results in the :py:attr:`traced_rays` member, the source
+objects also control the visualisation of the rays. The following visualisation-related attributes are available.
+
+