1 files changed, 79 insertions, 79 deletions
diff --git a/docs/_source/introduction.txt b/docs/_source/introduction.txt
index 402deeb..d7b79f6 100644..100755
--- a/docs/_source/introduction.txt
+++ b/docs/_source/introduction.txt
@@ -1,79 +1,79 @@
-/*! \page pageintroduction Introduction
-
-Blast&tm; is an NVIDIA GameWorks&tm; destruction library.  It consists of a \ref pagellapi, a \ref pagehlapi (Blast&tm; Toolkit
-or BlastTk), and \ref pageextapi (Blast&tm; Extensions or BlastExt).  This layered API is designed to allow short ramp-up time for
-first usage (through the Ext and Tk APIs) while also allowing for customization and optimization by experienced users through the
-low-level API.
-
-This library is intended to replace APEX Destruction.  It is being developed with years of user feedback and experience, with the 
-goal of addressing shortcomings in performance, stability, and customizability of the APEX Destruction module.
-
-\section asset_structure Asset Structure
-
-Blast&tm; is currently designed to support rigid body, pre-fractured destruction.  Future versions may support runtime fracturing
-or deformation.
-
-The static data associated with a destructible is stored in an \{\em asset\}.  Assets are instanced into actors, which may
-be damaged and fractured.  When fractured, actors are broken into pieces called \{\em chunks\}.  Connected groups of chunks
-belong to new actors.  The grouping of chunks into actors is determined by the support graph in the asset.
-
-Chunks are defined hierarchically, so that when a chunk is fractured its child chunks are created.  The user may tag any
-chunk in this hierarchy as a \{\em support\} chunk.  This is covered in more detail in the \ref support_model section.  The user
-also supplies a description of the connections between support chunks.  A \{\em bond\} represents the surface joining neighboring
-chunks.  A bond is represented by a surface centroid, an average surface normal, and the surface area.  These quantities don't
-need to be exact for Blast&tm; to operate effectively.
-
-Multiple chunk hierarchies may exist in a single asset.  The <em>root chunks</em> (see \ref pagedefinitions) will be visible when the
-asset is initially instanced.  Subsequent fracturing has the effect of breaking the root chunks into their hierarchical descendants.
-
-\section support_model Support Model
-
-Blast&tm; requires that support chunks form an <em>exact cover</em> (see the definition of exact coverage in \ref pagedefinitions).
-The geometric interpretation of exact coverage is that the support chunks fill the space of the root (unfractured) chunk, without
-any volume being covered by more than one chunk.  A helper function is provided to modify a set of chunk descriptors so that they
-have exact coverage.  This function fills in missing coverage by assigning support to chunks at the highest place possible (closest
-to root) in the hierarchy, and redundant support is removed: if a chunk and one of its descendant chunks are both marked as support,
-the function will remove support from the descendant chunk.
-
-Support chunks that are joined by bonds will be grouped together in the same actor when fracturing occurs.  Bonds may be defined
-between any two support chunks, or between a support chunk and "the world."  There is no corresponding "world chunk," but the bond
-represents a connection between the chunk and its external environment.  All chunks with a support graph connected to the world
-will be put into the same actor.  An expected use case is to make this actor static (or kinematic).  Actors may be queried to
-determine if they are "world-bound."
-
-In order to take advantage of the chunk hieararchy to reduce the number of chunks which represent an actor physically and
-graphically, Blast&tm; calculates a list of <em>visible chunks</em> from the support chunks in an actor.  These may be the support
-chunks, or they may be ancestors of support chunks if all descendant support chunks are in the actor.
-
-Support chunks do not have to be leaves in the chunk hierarchy, nor do they have to be at the same depth in the hierarchy.  Children
-of support chunks will always be the sole chunk in their actor, since there are no bonds defined between them.  If an actor consists
-of a <em>subsupport chunk</em> (see \ref pagedefinitions), the visible chunk is the same chunk.  The same is true if an actor consists
-of a <em>single</em> support chunk.
-
-\section damage_model Damage Model
-
-Damage is defined as loss of an actor's material integrity.  This is modeled by a simple health value associated with the bonds and
-chunks in the support graph.  The user applies damage to an actor at a given location, with a maximum effect radius.  The resulting
-loss of bond and chunk health is determined by a user-defined <em>material function</em>.  In this way the user can customize the
-effect of damage based upon the bonds' properties such as normal and area, as well as distance from impact location.
-
-Damage is applied during the processing of a damage event buffer.  After all damage events are processed, bonds with non-positive
-healths are considered to be broken.  Blast&tm; performs island detection on the support graph to find all groups of support chunks
-that are connected by unbroken bonds, and any new islands found result in new actors.
-
-If an actor is composed of a single support or subsupport chunk with subsupport descendants, then there is no bond structure to model
-damage.  Instead, such a chunk is considered to have its own health value, which may be decreased by damage.  When such a lower-support
-(see \ref pagedefinitions) chunk's health is non-positive, its associated actor is deleted and replaced by actors that represent its child
-chunks, if any.
-
-The effect of damage on leaf chunks depends upon which API is used.  The low-level API does not delete leaf chunks.  It is up to the
-user to delete them, and manage their physical and graphical representation outside of Blast&tm; if so desired.
-
-\section backwards_compatibility Backwards Compatibility
-
-The Blast&tm; SDK provides the \ref pageimporter tool to allow APEX Destructible assets to be reused.  A Blast&tm; asset requires more information
-in its support graph than an APEX Destuctible asset does.  Whereas the latter only contains a list of chunk neighbors, the bonds used by Blast&tm;
-include a small amount of geometric information, as described in \ref asset_structure.
-
-<br>
-*/
+/*! \page pageintroduction Introduction
+
+Blast&tm; is an NVIDIA GameWorks&tm; destruction library.  It consists of a \ref pagellapi, a \ref pagehlapi (Blast&tm; Toolkit
+or BlastTk), and \ref pageextapi (Blast&tm; Extensions or BlastExt).  This layered API is designed to allow short ramp-up time for
+first usage (through the Ext and Tk APIs) while also allowing for customization and optimization by experienced users through the
+low-level API.
+
+This library is intended to replace APEX Destruction.  It is being developed with years of user feedback and experience, with the 
+goal of addressing shortcomings in performance, stability, and customizability of the APEX Destruction module.
+
+\section asset_structure Asset Structure
+
+Blast&tm; is currently designed to support rigid body, pre-fractured destruction.  Future versions may support runtime fracturing
+or deformation.
+
+The static data associated with a destructible is stored in an \{\em asset\}.  Assets are instanced into actors, which may
+be damaged and fractured.  When fractured, actors are broken into pieces called \{\em chunks\}.  Connected groups of chunks
+belong to new actors.  The grouping of chunks into actors is determined by the support graph in the asset.
+
+Chunks are defined hierarchically, so that when a chunk is fractured its child chunks are created.  The user may tag any
+chunk in this hierarchy as a \{\em support\} chunk.  This is covered in more detail in the \ref support_model section.  The user
+also supplies a description of the connections between support chunks.  A \{\em bond\} represents the surface joining neighboring
+chunks.  A bond is represented by a surface centroid, an average surface normal, and the surface area.  These quantities don't
+need to be exact for Blast&tm; to operate effectively.
+
+Multiple chunk hierarchies may exist in a single asset.  The <em>root chunks</em> (see \ref pagedefinitions) will be visible when the
+asset is initially instanced.  Subsequent fracturing has the effect of breaking the root chunks into their hierarchical descendants.
+
+\section support_model Support Model
+
+Blast&tm; requires that support chunks form an <em>exact cover</em> (see the definition of exact coverage in \ref pagedefinitions).
+The geometric interpretation of exact coverage is that the support chunks fill the space of the root (unfractured) chunk, without
+any volume being covered by more than one chunk.  A helper function is provided to modify a set of chunk descriptors so that they
+have exact coverage.  This function fills in missing coverage by assigning support to chunks at the highest place possible (closest
+to root) in the hierarchy, and redundant support is removed: if a chunk and one of its descendant chunks are both marked as support,
+the function will remove support from the descendant chunk.
+
+Support chunks that are joined by bonds will be grouped together in the same actor when fracturing occurs.  Bonds may be defined
+between any two support chunks, or between a support chunk and "the world."  There is no corresponding "world chunk," but the bond
+represents a connection between the chunk and its external environment.  All chunks with a support graph connected to the world
+will be put into the same actor.  An expected use case is to make this actor static (or kinematic).  Actors may be queried to
+determine if they are "world-bound."
+
+In order to take advantage of the chunk hieararchy to reduce the number of chunks which represent an actor physically and
+graphically, Blast&tm; calculates a list of <em>visible chunks</em> from the support chunks in an actor.  These may be the support
+chunks, or they may be ancestors of support chunks if all descendant support chunks are in the actor.
+
+Support chunks do not have to be leaves in the chunk hierarchy, nor do they have to be at the same depth in the hierarchy.  Children
+of support chunks will always be the sole chunk in their actor, since there are no bonds defined between them.  If an actor consists
+of a <em>subsupport chunk</em> (see \ref pagedefinitions), the visible chunk is the same chunk.  The same is true if an actor consists
+of a <em>single</em> support chunk.
+
+\section damage_model Damage Model
+
+Damage is defined as loss of an actor's material integrity.  This is modeled by a simple health value associated with the bonds and
+chunks in the support graph.  The user applies damage to an actor at a given location, with a maximum effect radius.  The resulting
+loss of bond and chunk health is determined by a user-defined <em>material function</em>.  In this way the user can customize the
+effect of damage based upon the bonds' properties such as normal and area, as well as distance from impact location.
+
+Damage is applied during the processing of a damage event buffer.  After all damage events are processed, bonds with non-positive
+healths are considered to be broken.  Blast&tm; performs island detection on the support graph to find all groups of support chunks
+that are connected by unbroken bonds, and any new islands found result in new actors.
+
+If an actor is composed of a single support or subsupport chunk with subsupport descendants, then there is no bond structure to model
+damage.  Instead, such a chunk is considered to have its own health value, which may be decreased by damage.  When such a lower-support
+(see \ref pagedefinitions) chunk's health is non-positive, its associated actor is deleted and replaced by actors that represent its child
+chunks, if any.
+
+The effect of damage on leaf chunks depends upon which API is used.  The low-level API does not delete leaf chunks.  It is up to the
+user to delete them, and manage their physical and graphical representation outside of Blast&tm; if so desired.
+
+\section backwards_compatibility Backwards Compatibility
+
+The Blast&tm; SDK provides the \ref pageimporter tool to allow APEX Destructible assets to be reused.  A Blast&tm; asset requires more information
+in its support graph than an APEX Destuctible asset does.  Whereas the latter only contains a list of chunk neighbors, the bonds used by Blast&tm;
+include a small amount of geometric information, as described in \ref asset_structure.
+
+<br>
+*/