1 files changed, 73 insertions, 0 deletions
diff --git a/NvBlast/docs/_source/introduction.txt b/NvBlast/docs/_source/introduction.txt
new file mode 100644
index 0000000..e9fca5f
--- /dev/null
+++ b/NvBlast/docs/_source/introduction.txt
@@ -0,0 +1,73 @@
+/*! \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).
+However, it is quite forgiving with respect to user input when creating an asset.  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.  Upon
+asset creation, missing coverage will be filled in by Blast&tm;, by assigning support to chunks at the highest place possible (closest
+to root) in the hierarchy.  If support is redundant, that is a chunk and one of its descendant chunks are both marked as support
+by the user, then Blast&tm; 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.  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 is no bond defined between them.  If an actor consists of
+of a <em>subsupport chunk</em> (see \ref pagedefinitions), the visible chunk is the same 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 from 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>
+*/