DOC: Fix documentation

Docs/source/Collision_Handling.rst

@@ -7,16 +7,13 @@ Collision handling methods directly consume collision data which is produced by
 
 Collision handling happens between a pair of objects. Given this pair the handling has a side. We can either handle the collision for object A, object B, or both at the same time/AB.
 
-With this you will see 3 strategies then:
+With this you will see three strategies then:
 
 ::
 
     imstkNew<CustomSPHCollisionHandlerOneSided> handler(sphObj1, Side::A, collisionData);
-
     imstkNew<CustomSPHCollisionHandlerOneSided> handler(sphObj1, Side::A, collisionData);
-
     imstkNew<CustomSPHCollisionHandlerOneSided> handler(sphObj2, Side::B, collisionData);
-
     imstkNew<CustomSPHCollisionHandlerTwoSided> handler(sphObj1, sphObj2, collisionData);
 
 Generally, having one sided collision handlers is better for modularity, but sometimes it is required to consider both models.

Docs/source/Controllers.rst

@@ -48,7 +48,7 @@ Lets take a look at subclasses of each
 
 Here we can override each of the functions of a MouseControl and implement things we want. Similarly, we can do the same for KeyboardControl.
 
-TrackingDeviceControls are a bit different though. They must be added to the scene. See the :code`LaparoscopicToolController` class which is a subclass of :code`TrackingDeviceControl`.
+TrackingDeviceControls are a bit different though. They must be added to the scene. See the :code:`LaparoscopicToolController` class which is a subclass of :code:`TrackingDeviceControl`.
 
 ::
 

Docs/source/Geometry.rst

@@ -115,7 +115,7 @@ For example, you can punch and move a hole or grow a capsule in a signed distanc
     compGeom->addImplicitGeometry(planeGeom, CompositeImplicitGeometry::GeometryBoolType::Union);
     compGeom->addImplicitGeometry(sphereGeom, CompositeImplicitGeometry::GeometryBoolType::Difference);
 
-.. image:: media/CompositeGeo.png
+.. image:: media/compositeGeo.png
     :width: 600
     :alt: Alternative text
     :align: center

Docs/source/Mesh_IO.rst

@@ -53,7 +53,7 @@ MeshIO
 
 Example of file with multiple parts and materials:
 
-.. image:: media/meshIO.png
+.. image:: media/MeshIO.png
   :width: 400
   :alt: Alternative text
   :align: center

Docs/source/Scene.rst

@@ -165,7 +165,7 @@ These interactions are meant to keep the API simple. Internally they are quite p
 Interactions Internals
 ----------------------
 
-What the scene interactions in iMSTK provide is intermediate callback between two differing SceneObjects. That is, SceneObjects that have DynamicalModels such as Pbd, Fem, SPH, ... May have a complex pipeline, or set of steps. Certain interactions require intermediate callback that occurs between two steps of these models.
+What the scene interactions in iMSTK provide is intermediate callback between two differing SceneObjects. That is, SceneObjects that have DynamicalModels such as Pbd, Fem, SPH may have a complex pipeline, or set of steps. Certain interactions require intermediate callback that occurs between two steps of these models.
 
 For example take the following steps of PBD:
 
@@ -196,8 +196,7 @@ One might wonder why not just define these steps within the Pbd original set of
     solve collision constraints
     do steps 3 of all pbd objects
 
-The above is certainly easy if you're system relies only on Pbd. But we don't just have Pbd. We also have 
-SPH, Fem, Levelsets, ... Each with their own respective pipelines. Each with their own places that would be appropriate to do collision (interactions are also not just for collision), some models even have multiple potential spots for collision. With PBD you can clearly see if you want to do collision you need two steps inserted in two spots. Explicitly providing all these permutations of pipelines among objects is next to impossible.
+The above is certainly easy if you're system relies only on Pbd. But we don't just have Pbd. We also have SPH, Fem, Levelsets each with their own respective pipelines. Each with their own places that would be appropriate to do collision (interactions are also not just for collision), some models even have multiple potential spots for collision. With PBD you can clearly see if you want to do collision you need two steps inserted in two spots. Explicitly providing all these permutations of pipelines among objects is next to impossible.
 
 See the below possible explicit SPH and PBD interaction. This is not implemented, but shows how many possible pipeline permutations could happen. This is not the only approach to have PBD and SPH interaction. This particular one has us going back and correcting pressures after collision.
 

Docs/source/SimManager_Modules.rst

@@ -4,7 +4,7 @@ SimulationManager & Modules
 SimulationManager: Usage
 ========================
 
-iMSTK defines a set of Modules. Modules define something that can be init'd, update'd, and uninit'd. These can be used standalone. The 3 major modules given by iMSTK are:
+iMSTK defines a set of Modules. Modules define something that can be initialized, updated, and uninitialized. These can be used standalone. The three major modules given by iMSTK are:
 
 - VTKViewer
 - SceneManager
@@ -29,7 +29,7 @@ ModuleDriver is an abstract class which starts and stops a collection of Modules
     driver->start();
 
 
-Commonly you will also find it useful to start the scene in a paused state.
+Commonly, you will also find it useful to start the scene in a paused state.
 
 ::
 

Docs/source/documentation.rst

@@ -59,12 +59,6 @@ Once the superbuild is complete, you may notice that (a) all of iMSTK's dependen
 
 Note that one can create and maintain multiple builds from the same source. For example, as is typical to interactive applications testing typically is performed with the Release build while debugging using the Debug build. Additionally, it is usually recommended to separate the build and source directories for cleaner development and maintenance esp. with git-based workflows.
 
-**Offscreen Rendering**
-
-Offscreen OSMesa/CPU rendering is supported for Linux/MacOSx. This allows one
-to build iMSTK without a screen or GPU. Useful for servers. This can be enabled
-in the build by using the :code:`iMSTK_USE_VTK_OSMESA` flag to ON.
-
 Running Examples
 ----------------
 The default CMake configuration builds the examples as part of the inner build.
@@ -105,6 +99,12 @@ The examples that demonstrate the features and the usage of iMSTK API
 can be optionally build. Set :code:`BUILD_EXAMPLES` to ON the examples needs to
 be built.
 
+**Offscreen Rendering**
+
+Offscreen OSMesa/CPU rendering is supported for Linux/MacOSx. This allows one
+to build iMSTK without a screen or GPU. Useful for servers. This can be enabled
+in the build by using the :code:`iMSTK_USE_VTK_OSMESA` flag to ON.
+
 **Audio Support**
 
 iMSTK has the ability to play audio streams at runtime. In order to