/*! \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>
*/
