Updating to [email protected] and [email protected] with a new directory structure.

NvBlast folder is gone, files have been moved to top level directory.  README is changed to reflect this.

19 files changed, 2058 insertions, 0 deletions

diff --git a/docs/_source/apex_importer.txt b/docs/_source/apex_importer.txt
new file mode 100644
index 0000000..a0caef0
--- /dev/null
+++ b/docs/_source/apex_importer.txt
@@ -0,0 +1,78 @@
+/*! \page pageimporter ApexImporter
+
+ApexImporter is a tool for converting destructible assets from APEX Destruction format to Blast&tm; asset format.  Whereas APEX Destruction only needs a
+list of connected chunks, Blast&tm; has a Bond structure to describe chunk connections.  Each Bond describes the interface between two chunks, and needs
+the area, centroid, and average normal of this interface.  ApexImporter computes this data automatically.  Interface search can be done in several ways:
+- <b>Exact mode</b>: Importer tries to find triangles from two chunks which lay in common surface. If such triangles are found, their intersections are considered as the interface. Interface may not exist.
+- <b>Forced mode</b>: This mode based on search for midplane between two chunks and intersecting them with offsetted midplane to find interface parameters. Creates bonds even if chunks have no common surface.
+
+
+A bond is not created if area of interface is zero.  The interface centroid is computed as center of mass of all interface polygon points.  The interface normal is computed as an average of normals of all planes comprising the interface surface.
+
+Note - for Blast&tm; to operate with satisfactory fracturing behavior, it does not require exact area, centroid, and normal values for Bonds.
+
+Along with creating a Blast&tm; asset, ApexImporter creates an *.obj or *.fbx file with description of chunks render geometry.  Blast asset data can be saved to *.llasset, *.tkasset or *.bpxa format. BPXA asset contains collision geometry and can be used in \ref pagesampleassetviewer.
+
+\verbatim
+USAGE:
+
+		ApexImporter -f <infile> -n <output asset name>
+			     [--fbx] [--obj][--fbxascii] [--ue4] [--ll] [--tk]
+                             [--bpxa] [-d] [-m <0 - EXACT, 1 - FORCED>] 
+			     [-o <output directory>] [--] [--version] [-h]
+
+
+Where: 
+
+   -f <infile>,  --file <infile>
+     (required)  File to load
+
+   -n <output asset name>,  --outAssetName <output asset name>
+     (required)  Output asset name
+
+   --fbx
+     Output a FBX mesh to the output directory
+
+   --obj
+     Output a OBJ mesh to the output directory
+
+   --fbxascii
+     Output FBX as an ascii file (defaults to binary output)
+
+   --ue4
+     Output FBX with UE4 coordinate system
+
+   --ll
+     Output LL Blast asset to the output directory (ext: llasset)
+
+   --tk
+     Output TkAsset to the output directory (ext: tkasset)
+
+   --bpxa
+     Output ExtPxAsset to the output directory (ext: bpxa)
+
+   -d,  --debug
+     Print debug output
+
+   -m <0 - EXACT, 1 - FORCED>,  --mode <0 - EXACT, 1 - FORCED>,
+     Interface search mode
+
+   -o <output directory>,  --outputDir <output directory>
+     Result output directory. If is not specified, result will be saved to folder with input file.
+
+   --,  --ignore_rest
+     Ignores the rest of the labeled arguments following this flag.
+
+   --version
+     Displays version information and exits.
+
+   -h,  --help
+     Displays usage information and exits.
+
+\endverbatim
+
+<br>
+See \ref pagecopyrights for license information regarding third-party software used by ApexImporter.
+
+<br>
+*/
diff --git a/docs/_source/api_ext_users_guide.txt b/docs/_source/api_ext_users_guide.txt
new file mode 100644
index 0000000..04fbb53
--- /dev/null
+++ b/docs/_source/api_ext_users_guide.txt
@@ -0,0 +1,24 @@
+/*! \page pageextapi Extensions (NvBlastExt)
+
+These are the current Blast extensions:
+<br>
+<br>
+\subpage pageextauthoring
+<br>
+\subpage pageextapeximport
+<br>
+\subpage pageextserialization
+<br>
+\subpage pageextconverterll
+<br>
+\subpage pageextshaders
+<br>
+\subpage pageextphysx
+<br>
+<br>
+To use them, include the appropriate headers in include/extensions (each extension will describe which headers are necessary),
+and link to the desired NvBlastExt*{config}{arch} library in the lib folder.  Here, config is the usual DEBUG/CHECKED/PROFILE (or nothing for release),
+and {arch} distinguishes achitecture, if needed (such as _x86 or _x64).
+
+<br>
+*/
diff --git a/docs/_source/api_hl_users_guide.txt b/docs/_source/api_hl_users_guide.txt
new file mode 100644
index 0000000..99b2aa3
--- /dev/null
+++ b/docs/_source/api_hl_users_guide.txt
@@ -0,0 +1,706 @@
+/*! \page pagehlapi High Level (Toolkit) API (NvBlastTk)
+
+<b>Table of Contents</b>
+
+\subpage tkintroduction
+
+\subpage tk_class_hierarchy
+
+\subpage tk_include_and_library
+
+\subpage framework_init
+
+\subpage tkasset_creation
+
+\subpage tkasset_instancing
+
+\subpage tkgroups
+
+\subpage damage_in_tk
+
+\subpage tkjoints
+
+\subpage tkevents
+
+\subpage tktypes
+
+<br>
+\section tkintroduction Introduction to NvBlastTk
+
+The high-level API, NvBlastTk (Tk stands for "toolkit"), is intended to be a more powerful library and a much more convenient entry point
+into the use of Blast&tm;.  Like the low-level library, Tk is physics and graphics-agnostic.  Whereas the low-level API is C-style, Tk uses
+a C++ API.  Everything in Tk is in the namespace:
+
+\code
+Nv::Blast
+\endcode
+
+(the only exceptions are global-scope functions to create and access a framework singleton, see below).
+Every object in Tk is prefixed with 'Tk'.  For example, the Tk framework interface is:
+
+\code
+Nv::Blast::TkFramework
+\endcode
+
+<b>
+For the remainder of this page we will be in the Nv::Blast namespace, and will drop the explicit scope Nv::Blast:: from our names.
+</b>
+<br>
+<br>
+
+
+BlastTk adds:
+
+- An object class hierarchy (see \ref tk_class_hierarchy, below).
+- A global framework, <b>TkFramework</b> (a singleton).  This holds an allocator and error message callback, keeps track of <b>TkIdentifiable</b> objects and allows
+the user to query them based upon either GUID or <b>TkIdentifiable</b> subclass type, and also provides a number of functions to create the various objects in BlastTk.
+- Task management and processing groups (see <b>TkGroup</b>).
+- Event dispatching for actor families (see <b>TkFamily</b>).
+- Intra-actor and inter-actor joint management (see <b>TkJoint</b>).  Note, only joint descriptions are managed, since physical objects are not handled by BlastTk.
+- Various damage and material options for actors (<b>TkActor</b>).
+
+<br>
+\section tk_class_hierarchy NvBlastTk Class Hierarchy
+
+- There are three abstract interfaces, in an inheritance chain: <b>TkObject <- TkIdentifiable <- TkSerializable</b>.
+ - Lightweight objects are derived from <b>TkObject</b>.
+ - Objects which use a GUID and class identification are derieved from <b>TkIdentifiable</b>.
+ - Objects which support serialization are derived from <b>TkSerializable</b>.
+- <b>TkAsset</b> derives from <b>TkSerializable</b>.  This is mostly a wrapper for NvBlastAsset, however it also stores
+extra data associated with the asset such as a chunk map and internal joint descriptors.
+- <b>TkFamily</b> derives from <b>TkSerializable</b>.  One and only one of these objects is made when a <b>TkActor</b> is instanced
+from a <b>TkAsset</b>.  All actors that are created by splitting the family's original actor remain within the same family.  Actor and joint
+events are dispatched from the <b>TkFamily</b>.
+- <b>TkGroup</b> derives from <b>TkIdentifiable</b>.  Groups are processing units.  The user may create as many groups as they please, and add
+or remove actors as they please from groups.  The group will process damage applied to its actors, and split the actors into new actors when
+the actors fracture.  Groups use a user-defined task manager and can process actors in multiple threads simultaneously.
+- <b>TkActor</b> derives from <b>TkObject</b>.  It is mostly a wrapper for NvBlastActor, but it also provides a number of damage functions
+to the user.
+- <b>TkJoint</b> derives from <b>TkObject</b>.  Based upon <b>TkAsset</b> and <b>TkComposite</b> descriptors, a <b>TkJoint</b> may be internal
+to an actor (joining chunks within the same actor) or external (joining chunks between two actors).  As actors split, internal joints may become
+external.  The user gets notification whenever joints become external, or when actors joined by joints change or are deleted.
+
+<br>
+\section tk_include_and_library Linking and Header Files
+
+To use the BlastTk library, the application need only inlclude the header NvBlastTk.h, found in the <b>include/toolkit</b> folder, and link
+against the appropriate version of the NvBlastTk library.  Depending on the platform and configuration, various suffixes will be added to the library
+name.  The general naming scheme is
+
+NvBlastTk(config)(arch).(ext)
+
+(config) is DEBUG, CHECKED, OR PROFILE for the corresponding configurations.  For a release configuration there is no (config) suffix.
+
+(arch) is _x86 or _x64 for Windows 32- and 64-bit builds, respectively, and empty for non-Windows platforms.
+
+(ext) is .lib for static linking and .dll for dynamic linking on Windows.  On XBoxOne it is .lib, and on PS4 it is .a.
+
+
+<br>
+\section framework_init Creating the TkFramework
+
+As a reminder, in this document we assume we are in the Nv::Blast namespace:
+
+\code
+using Nv::Blast;
+\endcode
+
+In order to use NvBlastTk, one first has to create a TkFramework singleton.  This requires a descriptor which
+holds two callback classes defined by the user.  These classes are derived from the physx::PxErrorCallback and
+physx::PxAllocatorCallback interfaces, and define message handling and allocation/deallocation functions,
+respectively.  Assuming the user has already defined these objects with names gErrorCallback and gAllocatorCallback,
+the TkFramework descriptor is built as follows:
+
+\code
+TkFrameworkDesc desc;
+desc.errorCallback = &gErrorCallback;			// physx::PxErrorCallback-derived callback object
+desc.allocatorCallback = &gAllocatorCallback;	// physx::PxAllocatorCallback-derived callback object
+\endcode
+
+One then creates the framework:
+
+\code
+TkFramework* framework = NvBlastTkFrameworkCreate( desc );
+\endcode
+
+The framework is a global singleton, and may be accessed via:
+
+\code
+TkFramework* framework = NvBlastTkFrameworkGet();
+\endcode
+
+In the sections that follow, it is assumed that a framework has been created, and we have a pointer to it named 'framework' within scope.
+
+Finally, to release the framework, use
+
+\code
+framework->release();
+\endcode
+
+This will release all assets, families, actors, joints, and groups.
+
+<br>
+\section tkasset_creation Creating a TkAsset
+
+The TkAsset object is a high-level wrapper for the low-level NvBlastAsset (see \ref assets).  The descriptor used to create a TkAsset, a TkAssetDesc, is derived from
+NvBlastAssetDesc.  The base fields should be filled in as described in (\ref assets).  The new field is an optional array of flags to be associated with each bond in
+the base descriptor.  Currently the only flag is "BondJointed," and if set will cause an "internal joint" to be created in actors (TkActor type) created from the asset.
+See (\ref tkjoints) for more on joints in BlastTk.
+
+\code
+TkAssetDesc desc;
+
+myFunctionToFillInLowLevelAssetFields(desc);	// Fill in the low-level (NvBlastAssetDesc) fields as usual
+
+std::vector<uint8_t*> bondFlags(desc.bondCount, 0);	// Clear all flags
+
+// Set BondJointed flags corresponding to joints selected by the user (assumes a myBondIsJointedFunction to make this selection)
+for (uint32_t i = 0; i < desc.bondCount; ++i)
+{
+	if (myBondIsJointedFunction(i))	// User-authored
+	{
+		bondFlags[i] |= TkAssetDesc::BondJointed;
+	}
+}
+
+TkAsset* asset = framework->createAsset(desc);	// Create a new TkAsset
+\endcode
+
+The createAsset function used above creates a low-level NvBlastAsset from the base fields of the descriptor, and then adds internal joint descriptors based
+upon the bonds' centroids and attached chunks.  An alternative method to create a TkAsset allows the user to pass in a pre-existing NvBlastAsset, and a list
+of joint descriptors.  If the TkAsset is to have no internal joints, then the joint descriptors are not necessary and with an NvBlastAsset
+pointer <b>llAsset</b>, a TkAsset may be created simply by using
+
+\code
+TkAsset* asset = framework->createAsset(llAsset);
+\endcode
+
+By default, such a TkAsset will not "own" the llAsset.  When the TkAsset is released, the llAsset memory will be untouched.  You can pass ownership to the
+TkAsset using all of the default parameters of the createAsset function:
+
+\code
+TkAsset* asset = framework->createAsset(llAsset, nullptr, 0, true);
+\endcode
+
+The last parameter sets ownership.
+
+If one wants to author internal joints in a TkAsset using this second createAsset method, one must pass in a valid array of joint descriptors of type
+TkAssetJointDesc.  Each joint descriptor takes two positions and two node indices.  The positions are the joint's attachment positions in asset space, and
+the nodes indices are those of the graph nodes that correspond to support chunks.  These indices are not, in general, the same as the chunk indices.
+An example of initialization of the joint descriptors is given below.
+
+\code
+std::vector<TkAssetJointDesc> jointDescs(jointCount);	// Assume jointCount = the number of joints to add
+jointDescs[0].nodeIndices[0] = 0;	// Attach node 0 to node 1
+jointDescs[0].nodeIndices[1] = 1;
+jointDescs[0].attachPoistions[0] = physx::PxVec3( 1.0f, 2.0f, 3.0f );	// Attachment positions are often the same within an asset, but they don't have to be
+jointDescs[0].attachPoistions[1] = physx::PxVec3( 1.0f, 2.0f, 3.0f );
+// ... etc.
+
+TkAsset* asset = framework->createAsset(llAsset, jointDescs.data(), jointDescs.size());
+\endcode
+
+The code above assumes you know the support graph nodes to which you'd like to attach joints.  Often, the user only knows the corresponding chunk indices.
+Fortunately it's easy to map chunk indices to graph node indices.  In order to get the map, use the low-level function
+
+\code
+const uint32_t map = NvBlastAssetGetChunkToGraphNodeMap(llAsset, nullptr);
+\endcode
+
+This map is an array with an entry for every chunk index.  To get the graph node index for a chunk indexed <b>chunkIndex</b>, use
+
+\code
+uint32_t nodeIndex = map[chunkIndex];
+\endcode
+
+If the chunk indexed by <b>chunkIndex</b> does <em>not</em> correspond to a support chunk, then the mapped value will be UINT32_MAX, the invalid index.
+Otherwise, the mapped value will be a valid graph node index.
+
+Finally, to release a TkAsset, as with any TkObject-derived object, use the release() method:
+
+asset->release();
+
+<br>
+\section tkasset_instancing Instancing a TkAsset: Creation of a TkActor and a TkFamily
+
+Whereas with the Blast&tm; low-level (\ref pagellapi), one must explicitly create a family (NvBlastFamily) from an asset (NvBlastAsset) before creating
+the first actor (NvBlastActor) in the family, NvBlastTk creates a TkFamily automatically when an unfractured TkActor is instanced from a TkAsset using
+the framework's createActor function.  This family is accessible through the actor and any actor that is created from splitting it.  The family <em>not</em>
+released automatically when all actors within it have been released.  The user must use the TkObject::release() method to do so.  (Or wait until the
+framework is released.)  If a family is released that contains actors, the actors within will be released as well.
+
+The TkFamily has a special roll in NvBlastTk, holding user-supplied event listeners (TkEventListener).  All <em>internal</em> actor creation and destruction
+events are broadcast to listeners through split events (TkSplitEvent).  These signal when a fracturing operation has destroyed an actor and created
+child actors from it.  TkActor creation or release that occurs from an explicit API call do not produce events.  For example when creating a first unfractured
+instance of an asset using createAsset, or when calling the release() method on a TkActor.  TkJoint events are similarly broadcast to
+receivers (TkJointEvent).  These signal when the actors which are joined by the joints change, so that the user may update a corresponding physical joint.
+They also signal when a joint no longer attaches actors and is therefore unreferenced.  The user may invalidate or release the joint using the TkObject
+release() method when this occurs (more on joint ownership in \ref tkjoints).
+
+To create an unfractured TkActor instance from a TkAsset, one first fills in a descriptor (TkActorDesc) and passes it to the framework's createActor function.
+As with the TkAssetDesc, the TkActorDesc is derived from its low-level counterpart, the NvBlastActorDesc.  In addition the TkActorDesc holds a pointer to
+the TkAsset being instanced.  An example of TkActor creation is given below, given a TkAsset pointer <b>asset</b>.
+
+\code
+TkActorDesc desc;
+
+myFunctionToFillInLowLevelActorFields(desc);	// Fill in the low-level (NvBlastActorDesc) fields as usual
+
+desc.asset = asset;
+
+TkActor* actor = framework->createActor(desc);
+\endcode
+
+The TkFamily created with the actor above may be accessed through the actor's getFamily field:
+
+\code
+TkFamily& family = actor->getFamily();
+\endcode
+
+The returned value is a reference since a TkActor's family can never be NULL.  Actors resulting from the split of a "parent" actor will always belong to the
+parent's family.
+
+For most applications, the user will need to create a listener object to pass to every family created, in order to keep their physics and graphics representations
+in sync with the splitting of the TkActor.  For more on this, see \ref tkevents.
+
+<br>
+\section tkgroups Groups
+
+One feature of NvBlastTk is multithreading of damage processing.  The mechanism by which the toolkit does this is the group object, TkGroup.  Groups are created
+at the request of the user; the user may create as many groups as they like.  Actors may be added or removed from groups in any way the user wishes, with the only
+constraint being that a given actor may belong to no more than one group.  A group is a processing object, much like a scene in a physics simulation.  Indeed, a
+natural pattern would be to associate one group per physics scene, and synchronize the group processing with scene simulation.  Another pattern would be to subdivide
+the world into neighborhoods, and associate each neighborhood with a group.  A distributed game could take advantage of this structure to similarly distribute
+computation.
+
+When processing, a group spawns tasks to calculate the effects of all damage taken by the group's actors.  The group's sync function waits for all tasks to finish,
+and then has each family associated with its actors broadcast events to its listeners.
+
+Actors resulting from the split of a "parent" actor will be placed automatically into the group that the parent belonged to.  This is similar to the assigment of
+families from a split, except that unlike families, the user then has the option to move the new actors to other groups, or no group at all.
+
+Also similar to families, groups are not automatically released when the last actor is removed from it.  Unlike families, when a group is released, the actors which
+belong to the group are <em>not</em> released.  They will, however, be removed from the group before the release is complete.
+
+Because a group spawns tasks, for flexibility it requires a user-defined task manager.  This manager needs to implement the type physx::PxTaskManager interface.
+
+A typical usage is outlined below.  See \ref damage_in_tk for methods of applying damage to actors.
+
+\code
+// Create actors from descriptors desc1, desc2, ... etc., and attach a listener to each new family created
+TkActor* actor1 = framework->createActor(desc1);
+actor1->getFamily().addListener(gMyReceiver);		// gMyReceiver is a TkEventListener-derived object.  More on events in a subsequent section.
+TkActor* actor2 = framework->createActor(desc2);
+actor2->getFamily().addListener(gMyReceiver);
+TkActor* actor3 = framework->createActor(desc3);
+actor3->getFamily().addListener(gMyReceiver);
+// etc...
+
+// Let's create two groups.  First, create a group descriptor.  This may be used to create both groups.
+TkGroupDesc groupDesc;
+groupDesc.pxTaskManager = &gTaskManager;	// physx::PxTaskManager-derived object
+
+// Now create the groups
+TkGroup* group1 = framework->createGroup(groupDesc);
+TkGroup* group2 = framework->createGroup(groupDesc);
+
+// Add actor1 and actor2 to group1, and actor2 to group3...
+group1->addActor(actor1);
+group1->addActor(actor2);
+group2->addActor(actor3);
+// etc...
+
+// Now apply damage to all actors - *NOTE* damage is described in detail in the next section.
+// For now we will just assume a "myDamageFunction" to apply the damage.
+myDamageFunction(actor1);
+myDamageFunction(actor2);
+myDamageFunction(actor3);
+// etc...
+
+// Calling the groups' process functions will spawn tasks to process damage taken to the contained actors.
+group1->process();
+group2->process();
+
+// The user may insert code to be run asynchronously with group processing...
+
+// Call the groups' sync functions (with default block = true argument) to wait for processing to finish and fire off events.
+group1->sync();
+group2->sync();
+
+// When the groups are no longer needed, they may be released with the usual release method.
+group1->release();
+group2->release();
+\endcode
+
+<br>
+\section damage_in_tk Applying Damage to Actors and Families
+
+Damage in NvBlastTk uses the same damage program scheme as the low-level SDK (see \ref splitting).  One passes the program
+(NvBlastDamageProgram), damage descriptor (program-dependent), and material (also program-dependent) to a TkActor::damage
+function.  Ultimately, the damage descriptor and material data are all parameters used by the damage program.  The distinction
+is that the damage descriptor should describe properties of the thing doing the damage, while the material should
+describe properties of the actor (the thing being damaged).  The interpretation of this data is entirely up to the program's
+functions, however.
+
+For convenience, the user may set a default material in the actor's family.  This assumes, of course, that the material parameters
+for this default are compatible with the program being used to damage the family's actors.
+
+Examples of the three TkActor damage methods are given below.
+
+<br>
+\subsection multiple_damage Multiple Damage Descriptors using NvBlastProgramParams
+
+<b>N.B. - with this method of damage, the lifetime of the NvBlastProgramParams <em>must</em> extend at
+least until the TkGroup::sync call for the actor.</b>
+
+\code
+NvBlastDamageProgram program =
+{
+	myGraphShaderFunction,		// A function with the NvBlastGraphShaderFunction signature
+	mySubgraphShaderFunction	// A function with the NvBlastSubgraphShaderFunction signature
+};
+
+// The example struct "RadialDamageDesc" is modeled after NvBlastExtRadialDamageDesc in the NvBlastExtShaders extension
+RadialDamageDesc damageDescs[2];
+
+damageDescs[0].compressive = 10.0f;
+damageDescs[0].position[0] = 1.0f;
+damageDescs[0].position[1] = 2.0f;
+damageDescs[0].position[2] = 3.0f;
+damageDescs[0].minRadius = 0.0f;
+damageDescs[0].maxRadius = 1.0f;
+
+damageDescs[1].compressive = 100.0f;
+damageDescs[1].position[0] = 3.0f;
+damageDescs[1].position[1] = 4.0f;
+damageDescs[1].position[2] = 5.0f;
+damageDescs[1].minRadius = 0.0f;
+damageDescs[1].maxRadius = 5.0f;
+
+// The example material "Material" is modeled after NvBlastExtMaterial in the NvBlastExtShaders extension
+Material material;
+
+material.singleChunkThreshold = 1.0f;
+material.graphChunkThreshold = 1.0f;
+material.bondTangentialThreshold = 0.5f;
+material.bondNormalThreshold = 0.25f;
+material.damageAttenuation = 0.75f
+
+// Set the damage params struct
+NvBlastProgramParams params = { damageDescs, 2, &material };
+
+// Apply damage
+actor->damage(program, &params);	// params must be kept around until TkGroup::sync is called!
+\endcode
+
+<br>
+\subsection single_damage_desc_default_material Single Damage Descriptor with Default TkFamily Material
+
+This method of damage copies the damage descriptor into a buffer, so the user need <em>not</em> hold onto
+a copy after the damage function call.  Only one damage descriptor may be passed in at once.
+
+To use this method, the user must first set a default material in the actor's family.  For example:
+
+\code
+// The example material "Material" is modeled after NvBlastExtMaterial in the NvBlastExtShaders extension
+Material material;
+
+material.singleChunkThreshold = 1.0f;
+material.graphChunkThreshold = 1.0f;
+material.bondTangentialThreshold = 0.5f;
+material.bondNormalThreshold = 0.25f;
+material.damageAttenuation = 0.75f
+
+// Set the default material used by the material-less TkActor::damage call
+actor->getFamily().setMaterial(&material);
+\endcode
+
+<b>N.B. the lifetime of the material set <em>must</em> extend at least until the TkGroup::sync call for the actor.</b>
+
+Then to apply damage, use:
+
+\code
+NvBlastDamageProgram program =
+{
+	myGraphShaderFunction,		// A function with the NvBlastGraphShaderFunction signature
+	mySubgraphShaderFunction	// A function with the NvBlastSubgraphShaderFunction signature
+};
+
+// The example struct "RadialDamageDesc" is modeled after NvBlastExtRadialDamageDesc in the NvBlastExtShaders extension
+RadialDamageDesc damageDesc;
+
+damageDesc.compressive = 10.0f;
+damageDesc.position[0] = 1.0f;
+damageDesc.position[1] = 2.0f;
+damageDesc.position[2] = 3.0f;
+damageDesc.minRadius = 0.0f;
+damageDesc.maxRadius = 1.0f;
+
+// Apply damage
+actor->damage(program, &damageDesc, (uint32_t)sizeof(RadialDamageDesc));
+\endcode
+
+<br>
+\subsection single_damage_desc_with_material Single Damage Descriptor with Specified Material
+
+This method is just like the one above, except that the user has the opportunity to override the material used during damage.
+
+<b>N.B. - the lifetime of the material passed in <em>must</em> extend at least until the TkGroup::sync call for the actor.</b>
+
+This call is just like the one above with an extra material parameter:
+
+\code
+actor->damage(program, &damageDesc, (uint32_t)sizeof(RadialDamageDesc), &material);
+\endcode
+
+<br>
+\section tkjoints Joints
+
+Joints in NvBlastTk are abstract representations of physical joints.  When joints become active, change the actors they join,
+or become unreferenced (the actors they join disappear), the user will receive notification via a TkJointUpdateEvent
+(see \ref tkevents).
+
+Joints may be defined as a part of a TkAsset, in which case they are consisdered "internal" joints.  (See \ref tkasset_creation.)
+Since the first instance of a TkAsset is a single TkActor, internal joints are defined between chunks within the same actor.
+Therefore they are not active (there is no point in joining two locations in a single rigid body).  Upon splitting into multiple
+actors, however, an internal joint's chunks may now belong to two different TkActors.  When this happens, the user will receive a
+TkJointUpdateEvent of subtype TkJointUpdateEvent::External.  The event contains a pointer to the TkJoint, and from that the user
+has access to the information needed to create a physical joint between the rigid bodies that correspond to the joined TkActors.
+
+Joints may also be created externally at runtime, using the TkFramework::createJoint function.  A joint created this way must
+be between two different TkActors.  Because of this, the joint is immediately considered active, and so no TkJointUpdateEvent
+is generated from its creation.  The user should create a physical joint to correspond to the joint returned by createJoint.
+An externally created joint of this type has another distinguishing characteristic: it may join an actor to "the world," or
+"Newtonial Reference Frame" (NRF).  To do this, one TkFamily pointer in the joint descriptor is set to NULL.  Examples are
+given below.
+
+\code
+TkJointDesc desc;
+desc.families[0] = &actor0->getFamily();	// Assume we have a valid actor0 pointer
+desc.chunkIndices[0] = 1;	// This chunk *must* be a support chunk in the asset that created desc.families[0]
+desc.attachPositions[0] = physx::PxVec3(1.f, 2.f; 3.f);	// The attach position is in asset space
+desc.families[1] = &actor1->getFamily();	// Assume we have a valid actor1 pointer... note, actor0 and actor1 could have the same family
+desc.chunkIndices[1] = 10;	// This chunk *must* be a support chunk in the asset that created desc.families[1]
+desc.attachPositions[1] = physx::PxVec3(4.f, 5.f; 6.f);	// The attach position is in asset space
+
+// Create the external joint from the descriptor, which joins actor0 and actor1
+TkJoint* joint = framework->createJoint(desc);
+
+// Now join actor0 to the NRF
+// desc.families[0] already contains actor0's family
+desc.chunkIndices[0] = 2;	// Again, this chunk must be a support chunk in the asset that created desc.families[0]
+desc.attachPositions[0] = physx::PxVec3(0.f, 0.f; 0.f);	// The attach position is in asset space
+desc.families[1] = nullptr;	// Setting the family to NULL designates the world (NRF)
+// The value of desc.chunkIndices[1] is not used, since desc.families[1] is NULL
+desc.attachPositions[1] = physx::PxVec3(0.f, 0.f, 10.0f);	// Attach position in the world
+
+// Create the external joint which joins actor0 to the world
+TkJoint* jointNRF = framework->createJoint(desc);
+\endcode
+
+<br>
+\subsection releasing_joints Releasing Joints
+
+TkJoints are not released by Blast&tm;, except when the TkFramework is released.  Otherwise, the user is responsible for
+releasing TkJoints after they become unreferenced.  This is facilitated by the Unreferenced subtype of the TkJointUpdateEvent.  After
+receiving this event for joint, the user may choose to release, using the typical TkObject::release() method.
+
+\code
+joint->release();
+\endcode
+
+Note, this method can be called <em>at any time</em>, even before the joint is unreferenced.  When called, it will remove its
+references to its attached actors first, causing the joint to then become unreferenced.  For example, if the user wishes to break
+a physical joint in their simulation, they can then release the corresponding TkJoint.
+
+It should be mentioned, however, that joints created with an asset are allocated differently from external joints created using
+TkFramework::createJoint.  Internal joints created from the joint descriptors in a TkAsset are <em>block allocated</em> with every
+TkFamily that instances the asset.  Calling the release() method on those joints will remove any remaining references to them
+(as mentioned above), but will not perform any deallocation.  Only when the TkFamily itself is released will the internal joint
+memory for that family be released.  <b>This is true even if the internal joints become "external" from actor splitting.</b>  Joints
+that <em>become</em> external are still associated with a single family and their memory still resides with that family.
+
+On the other hand, joints that start out life external by way of the TkFramework::createJoint function have a separate allocation,
+and do not have memory tied to any TkFamily (even if both actors joined are in the same family).  Releasing a family holding one
+of the actors in such a "purely external" joint will trigger a TkJointUpdateEvent of subtype Unreferenced, however, signalling that
+the joint is ready for user release.
+
+<br>
+\section tkevents Events
+
+NvBlastTk uses events to communicate the results of actor splitting, joint updates from actor splitting, and fracture event buffers
+that can be used to synchronize fracturing between multiple clients.
+
+Events are broadcast to listeners which implement the TkEventListener interface.  Listeners are held by TkFamily objects.  During
+a TkGroup::sync call (see \ref tkgroups), relevant events are broadcast to the listeners in the families associated with the actors
+in the group.
+
+A typical user's receiver implementation might take on the form shown below.
+
+\code
+class MyActorAndJointListener : public TkEventListener
+{
+	// TkEventListener interface
+	void receive(const TkEvent* events, uint32_t eventCount) override
+	{
+		// Events are batched into an event buffer.  Loop over all events:
+		for (uint32_t i = 0; i < eventCount; ++i)
+		{
+			const TkEvent& event = events[i];
+
+			// See TkEvent documentation for event types
+			switch (event.type)
+			{
+			case TkSplitEvent::EVENT_TYPE:	// A TkActor has split into smaller actors
+			{
+				const TkSplitEvent* splitEvent = event.getPayload<TkSplitEvent>();	// Split event payload
+
+				// The parent actor may no longer be valid.  Instead, we receive the information it held
+				// which we need to update our app's representation (e.g. removal of the corresponding physics actor)
+				myRemoveActorFunction(splitEvent->parentData.family, splitEvent->parentData.index, splitEvent->parentData.userData);
+
+				// The split event contains an array of "child" actors that came from the parent.  These are valid
+				// TkActor pointers and may be used to create physics and graphics representations in our application
+				for (uint32_t j = 0; j < splitEvent->numChildren; ++j)
+				{
+					myCreateActorFunction(splitEvent->children[j]);
+				}
+			}
+			break;
+
+			case TkJointUpdateEvent::EVENT_TYPE:
+			{
+				const TkJointUpdateEvent* jointEvent = event.getPayload<TkJointUpdateEvent>();	// Joint update event payload
+
+				// Joint events have three subtypes, see which one we have
+				switch (jointEvent->subtype)
+				{
+				case TkJointUpdateEvent::External:
+					myCreateJointFunction(jointEvent->joint);	// An internal joint has been "exposed" (now joins two different actors).  Create a physics joint.
+					break;
+				case TkJointUpdateEvent::Changed:
+					myUpdatejointFunction(jointEvent->joint);	// A joint's actors have changed, so we need to update its corresponding physics joint.
+					break;
+				case TkJointUpdateEvent::Unreferenced:
+					myDestroyJointFunction(jointEvent->joint);	// This joint is no longer referenced, so we may delete the corresponding physics joint.
+					break;
+				}
+			}
+
+			// Unhandled:
+			case TkFractureCommands::EVENT_TYPE:
+			case TkFractureEvents::EVENT_TYPE:
+			default:
+			break;
+			}
+		}
+	}
+};
+\endcode
+
+Whenever a new TkActor is created by the user (via TkFramework::createActor, see \ref tkasset_instancing), its newly-made family should
+be given whatever listeners the user wishes to attach.  For example,
+
+\code
+TkActor* actor = framework->createActor(actorDesc);
+
+actor->getFamily().addListener(myListener);	//	myListener is an object which implements TkEventListener (see MyActorAndJointListener above, for example)
+\endcode
+
+Listeners may also be removed from families at any time.
+
+<br>
+\section tktypes Object and Type Identification
+
+NvBlastTk objects that are derived from TkIdentifiable (TkAsset, TkFamily, and TkGroup) support an object and class (type) identification
+system.  The TkIdentifiable interfaces setID and getID allow the user to set and access an NvBlastID for each object.  The NvBlastID
+is a 128-bit identifier.  TkIdentifiable objects are tracked by the TkFramework, which may be used to look up an object by its NvBlastID.
+
+Upon creation, TkIdentifiable objects are given a GUID, a unique NvBlastID.  The is welcome to change the object's guid at any time, with
+the restriction that the GUID cannot be all zero bytes.
+
+With an object's GUID, one may look up the object using the TkFramework function findObjectByID:
+
+\code
+TkIdentifiable* object = framework->findObjectByID(id);	// id = an NvBlastID GUID
+\endcode
+
+If the object is found, a non-NULL pointer will be returned.
+
+TkIdentifiable-derived classes also have a class identification system, the TkType interface.  From an individual object one may use the
+TkIdentifiable interface getType to access the class's TkType interface.  Alternatively, one may use the TkFramework getType function
+with TkTypeIndex::Enum argument.  For example, to get the TkType interface for the TkAsset class, use
+
+\code
+const TkType* assetType = framework->getType(TkTypeIndex::Asset);
+\endcode
+
+The type interface may be used:
+
+   - to access class-specific object lists in the framework,
+   - identify the class of a TkIdentifiable obtained through ID lookup or deserialization, or
+   - to obtain the class's name and format version number.
+
+For example, to access a list of all families:
+
+\code
+// Get the TkFamily type interface
+const TkType* familyType = framework->getType(TkTypeIndex::Family);
+
+// Get the family count to allocate a buffer
+const uint32_t familyCount = framework->getObjectCount(familyType);
+std::vector<TkIdentifiable*> families(familyCount);
+
+// Write the families to the buffer
+const uint32_t familiesFound = framework->getObjects(families.data(), familyCount, familyType);
+\endcode
+
+In the above code, the values of familyCount and familiesFound should be equal.  An alternative usage of TkFramework::getObjects allows the
+user to write to a (potentially) smaller buffer, iteratively.  For example:
+
+\code
+uint32_t familiesFound;
+uint32_t totalFamilyCount = 0;
+do
+{
+	// Write to a fixed-size buffer
+	TkIdentifiable* familyBuffer[16];
+	familiesFound = framework->getObjects(familyBuffer, 16, familyType, totalFamilyCount);
+	totalFamilyCount += familiesFound;
+
+	// Process the families found so far
+	myProcessFamiliesFunction(familyBuffer, familiesFound);
+} while (familiesFound == 16);
+\endcode
+
+To use the type interface to identify a class, perhaps after serialization or lookup by ID, one may do something like:
+
+\code
+\\ Assume we have a TkIdentifiable pointer called "object"
+
+// Get the type interfaces of interest
+const TkType* assetType = framework->getType(TkTypeIndex::Asset);
+const TkType* familyType = framework->getType(TkTypeIndex::Family);
+
+if (object->getType() == *assetType)
+{
+	TkAsset* asset = static_cast<TkAsset*>(object);
+
+	// Process the object as a TkAsset
+}
+if (object->getType() == *familyType)
+else
+{
+	TkFamily* family = static_cast<TkFamily*>(object);
+
+	// Process the object as a TkFamily
+}
+\endcode
+
+A TkIdentifiable-derived class may be queried for its name using the TkType interface, using TkType::getName().
+This function returns a const char pointer to a string.
+
+Finally, one may query the class for its current format version number using TkType::getVersion().
+
+<br>
+*/
diff --git a/docs/_source/api_ll_users_guide.txt b/docs/_source/api_ll_users_guide.txt
new file mode 100644
index 0000000..33d12db
--- /dev/null
+++ b/docs/_source/api_ll_users_guide.txt
@@ -0,0 +1,389 @@
+/*! \page pagellapi Low Level API (NvBlast)
+
+<b>Table of Contents</b>
+
+\subpage llintroduction
+
+\subpage include_and_library
+
+\subpage assets
+
+\subpage actors_and_families
+
+\subpage splitting
+
+<br>
+\section llintroduction Introduction
+
+The low-level API is the core of Blast&tm; destruction.  It is designed to be a minimal API that allows an experienced user to incorporate destruction
+into their application.  Summarizing what the low-level API has, or rather <em>doesn't</em> have:
+
+- There is no physics representation.  The low-level API is agnostic with respect to any physics engine, and furthermore does not have
+any notion of collision geometry.  The NvBlastActor is an abstraction which is intended to correspond to a rigid body.  However
+it is up to the user to make that connection.  The NvBlastActor references a list of visible chunk indices, which correspond to
+NvBlastChunk data in the asset.  The NvBlastChunk contains a userData field which can be used to associate collision
+geometry with the actor based upon the visible chunks.  The same is true for constraints created between actors.  Bonds contain a
+userData field that can be used to inform the user that actors should have joints created at a particular location.  After that it is up to the
+user to create the joint, and Blast&tm; does not manage them in any way.
+- There is no graphics representation.  Just as there is no notion of collision geometry, there is no notion of graphics geometry either.
+The NvBlastChunk userData field (see the item above) can be used to associate graphics geometry with the actor based upon the visible chunks.
+- There is no notion of threading.  The API is a collection of free functions for which is is up to the user to call from appropriate threads.
+Blast&tm; guarantees that it is safe to operate on different actors from different threads.
+- There is no global memory manager, message handler, etc.  Most functions take an optional message function pointer argument, in order to report
+warnings or errors.  Memory is managed by the user, and functions that build objects require an appropriately-sized memory block to be passed in.
+A corresponding utility function that calculates the memory requirements is always present alongside such functions.  Temporary storage needed by a
+function is always handled via user-supplied scratch space.  For scratch, there is always a corresponding "RequiredScratch" function
+or documentation which lets the user know how much scratch space is needed based upon the function arguments.
+- One form of serialization is simply handled as a memory copy.  Data associated with an asset or family (see \ref pagedefinitions) is
+available to the user, and may be copied and stored by the user.  There are corresponding data association functions which may be used to recreate
+assets and families.  Families contain a number of actors and so this form of deserialization recreates all actors in the family.
+These deserialization operations simply tie pointers in those objects to data within the given family.  The families come with format
+version numbers, and association will only occur when the version number matches the current version used by the SDK.
+- Single-actor serialization and deserialization is supported.  This is not as light-weight as family serialization, but may be a better serialization
+model for a particular application.  To deserialize a single actor, one must have a family to hold the actor, created from the appropriate
+asset.  If none exists already, the user may create an empty family.  After that, all actors that had been in that family may be deserialized
+into it one-at-a-time, in any order.
+- No data format coversion is done.  As mentioned above, data association will only occur with a current format version.  It is up to extension
+functions to perform data conversion.  (See \ref pageextserialization.)
+
+<br>
+\section include_and_library Linking and Header Files
+
+To use the low-level Blast&tm; SDK, the application need only inlclude the header NvBlast.h, found in the top-level <b>include</b> folder, and link
+against the appropriate version of the NvBlast library.  Depending on the platform and configuration, various suffixes will be added to the library
+name.  The general naming scheme is
+
+NvBlast(config)(arch).(ext)
+
+(config) is DEBUG, CHECKED, OR PROFILE for the corresponding configurations.  For a release configuration there is no (config) suffix.
+
+(arch) is _x86 or _x64 for Windows 32- and 64-bit builds, respectively, and empty for non-Windows platforms.
+
+(ext) is .lib for static linking and .dll for dynamic linking on Windows.  On XBoxOne it is .lib, and on PS4 it is .a.
+
+<br>
+\section assets Creating an Asset from a Descriptor (Authoring)
+
+The NvBlastAsset is an opaque type pointing to an object constructed by Blast&tm; in memory allocated by the user.
+To create an asset from a descriptor, use the function NvBlastAssetCreate.  See the function documentation for a
+description of its parameters.
+
+<b>N.B., there are strict rules for the ordering of chunks with an asset, and also conditions on the chunks marked as "support"
+(using the NvBlastChunkDesc::SupportFlag).  See the function documentation for these conditions.  NvBlastAssetCreate does
+<em>not</em> reorder chunks or modify support flags to meet these conditions.  If the conditions are not met, NvBlastAssetCreate
+fails and returns NULL.  However, Blast&tm; provides helper functions to reorder chunk descriptors and modify the support flags
+within those descriptors so that they are valid for asset creation.  The helper functions return a mapping from the original
+chunk ordering to the new chunk ordering, so that corresponding adjustments or mappings may be made for graphics and other data
+the user associates with chunks.</b>
+
+Example code is given below.
+
+\code
+std::vector<NvBlastChunkDesc> chunkDescs;
+chunkDescs.resize( chunkCount );	// chunkCount > 0
+
+chunkDescs[0].parentChunkIndex = UINT32_MAX;	// invalid index denotes a chunk hierarchy root
+chunkDescs[0].centroid[0] = 0.f;	// centroid position in asset-local space
+chunkDescs[0].centroid[1] = 0.f;
+chunkDescs[0].centroid[2] = 0.f;
+chunkDescs[0].volume = 1.f;	// Unit volume
+chunkDescs[0].flags = NvBlastChunkDesc::NoFlags;
+chunkDescs[0].ID = 0;	// User-supplied ID.  For example, this can be the index of the chunkDesc.
+						// The ID can be left undefined.
+
+chunkDescs[1].parentChunkIndex = 0;	// child of chunk described by chunkDescs[0]
+chunkDescs[1].centroid[0] = 2.f;	// centroid position in asset-local space
+chunkDescs[1].centroid[1] = 4.f;
+chunkDescs[1].centroid[2] = 6.f;
+chunkDescs[1].volume = 1.0;	// Unit volume
+chunkDescs[1].flags = NvBlastChunkDesc::SupportFlag; // This chunk should be represented in the support graph
+chunkDescs[1].ID = 1;
+
+// ... etc.
+
+std::vector<NvBlastBondDesc> bondDescs;
+bondDescs.resize( bondCount );	// bondCount > 0
+
+bondDescs[0].chunkIndices[0] = 1;	// chunkIndices refer to chunk descriptor indices for support chunks
+bondDescs[0].chunkIndices[1] = 2;
+bondDescs[0].bond.m_normal[0] = 1.f;	// normal in the +x direction
+bondDescs[0].bond.m_normal[1] = 0.f;
+bondDescs[0].bond.m_normal[2] = 0.f;
+bondDescs[0].bond.m_area = 1.0;	// unit area
+bondDescs[0].bond.m_centroid[0] = 1.f;	// centroid position in asset-local space
+bondDescs[0].bond.m_centroid[1] = 2.f;
+bondDescs[0].bond.m_centroid[2] = 3.f;
+bondDescs[0].m_userData = 0;	// this can be used to tell the user more information about this
+								// bond for example to create a joint when this bond breaks
+
+// ... etc.
+
+// Set the fields of the descriptor
+NvBlastAssetDesc assetDesc;
+assetDesc.chunkCount = chunkCount;
+assetDesc.chunkDescs = chunkDescs.data();
+assetDesc.bondCount = bondCount;
+assetDesc.bondDescs = bondDescs.data();
+
+// Now ensure the support coverage in the chunk descriptors is exact, and the chunks are correctly ordered
+std::vector<char> scratch( chunkCount * sizeof(NvBlastChunkDesc) );	// This is enough scratch for both NvBlastEnsureAssetExactSupportCoverage and NvBlastReorderAssetDescChunks
+NvBlastEnsureAssetExactSupportCoverage( chunkDescs.data(), chunkCount, scratch.data(), nullptr );
+std::vector<uint32_t> map(chunkCount);	// Will be filled with a map from the original chunk descriptor order to the new one
+NvBlastReorderAssetDescChunks( chunkDescs.data(), chunkDescs, bondDescs.data(), bondCount, map, scratch.data(), nullptr );
+
+// Create the asset
+scratch.resize( NvBlastGetRequiredScratchForCreateAsset( &assetDesc ) );	// Provide scratch memory for asset creation
+void* mem = malloc( NvBlastGetAssetMemorySize( &assetDesc ) );		// Allocate memory for the asset object
+NvBlastAsset* asset = NvBlastCreateAsset( mem, &assetDesc, scratch.data(), nullptr );	// the log function (last argument) is optional
+\endcode
+
+<br>
+It should be noted that the geometric information (centroid, volume, area, normal) in chunks and bonds is only used by damage
+shader functions (see \ref pageextshaders).  Depending on the shader, some, all, or none of the geometric information will be needed.
+The user may write damage shader functions that interpret this data in any way they wish.
+
+<br>
+\subsection asset_copying Cloning an Asset (Serialization and Deserialization)
+
+To clone an asset, or equivalently serialize and deserialize it (as long as the deserialized asset is being created on a host with the
+same data version and endianness), one only needs to copy the memory associated with the NvBlastAsset.  
+
+\code
+uint32_t assetSize = NvBlastAssetGetSize( data );
+
+NvBlastAsset* newAsset = (NvBlastAsset*)malloc(assetSize);	// NOTE: the memory buffer <em> must <\em> be 16-byte aligned!
+memcpy( newAsset, asset, assetSize );	// this data may be copied into a buffer, stored to a file, etc.
+\endcode
+
+N.B. the comment after the malloc call above.  NvBlastAsset memory must be 16-byte aligned.
+
+<br>
+\subsection asset_releasing Releasing an Asset
+
+Blast&tm low-level does no internal allocation; since the memory is allocated by the user, one simply has to free the memory they've
+allocated.  The asset pointer returned by NvBlastCreateAsset has the same numerical value as the mem block passed in (if the function
+is successful, or NULL otherwise).  So releasing an asset done as follows:
+
+\code
+free( asset );
+\endcode
+
+<br>
+\section actors_and_families Creating Actors and Families
+
+Actors live within a family created from asset data.  To create an actor, one must first create a family.  This family is used by the initial actor created from
+the asset, as well as all of the descendent actors created by recursively fracturing the initial actor.  Like assets, family allocation is done by the user.
+
+To create a family, use:
+
+\code
+// Allocate memory for the family object - this depends on the asset being represented by the family.
+void* mem = malloc( NvBlastAssetGetFamilyMemorySize( &asset ) );
+
+NvBlastFamily* family = NvBlastAssetCreateFamily( mem, &asset, nullptr );
+\endcode
+
+When an actor is first created from an asset, it represents the root of the chunk hierarchy, that is the unfractured object.  To create this actor, use:
+
+\code
+// Set the fields of the descriptor
+NvBlastActorDesc actorDesc;
+actorDesc.asset = asset;	// point to a valid asset
+actorDesc.initialBondHealth = 1.0f;  // this health value will be given to all bonds
+actorDesc.initialChunkHealth = 1.0f; // this health value will be given to all lower-support chunks
+
+// Provide scratch memory
+std::vector<char> scratch( NvBlastFamilyGetRequiredScratchForCreateFirstActor( &actorDesc ) );
+
+// Create the first actor
+NvBlastActor* actor = NvBlastFamilyCreateFirstActor( family, &actorDesc, scratch.data(), nullptr );	// ready to be associated with physics and graphics by the user
+\endcode
+
+<br>
+\subsection actor_copying Copying Actors (Serialization and Deserialization)
+
+There are two forms of serialization: family serialization and single actor serialization.  Family serialization is extremely fast as it only requires a single
+memory copy.  All actors in the family may be saved, loaded, or copied at once in this way.
+
+<br>
+\subsection family_serialization Family Serialization
+
+To serialize a family, use the family pointer which may be retrieved
+from any active actor in the family if needed, using the NvBlastActorGetFamily function:
+
+\code
+const NvBlastFamily* family = NvBlastActorGetFamily( &actor, nullptr );
+\endcode
+
+Then the size of the family may be obtained using:
+
+\code
+size_t size = NvBlastFamilyGetSize( family, nullptr );
+\endcode
+
+Now this memory may be copied, saved to disk, etc.  To clone the family, for example, we can duplicate the memory:
+
+\code
+std::vector<char> buffer( size );
+NvBlastFamily* family2 = reinterpret_cast<NvBlastFamily*>( buffer.data() );
+memcpy( family2, family, size );
+\endcode
+
+<B>N.B.</B> If this data has been serialized from an external source, the family will not contain a valid reference to its associated asset.
+The user <em>must</em> set the family's asset.  The family does however contain the asset's GUID, to help the user match the correct asset
+to the family.  So one way of restoring the asset to the family follows:
+
+\code
+const NvBlastGUID guid = NvBlastFamilyGetAssetGUID( family2, nullptr );
+// ... here the user must retrieve the asset using the GUID or by some other means
+NvBlastFamilySetAsset( family2, asset, nullptr );
+\endcode
+
+The data in family2 will contain the same actors as the original family.  To access them, use:
+
+\code
+uint32_t actorCount = NvBlastFamilyGetActorCount( family2, nullptr );
+std::vector<NvBlastActor*> actors( actorCount );
+uint32_t actorsWritten = NvBlastFamilyGetActors( actors.data(), actorCount, family2, nullptr );
+\endcode
+
+In the code above, actorsWritten should equal actorCount.
+
+<br>
+\subsection single_actor_serialization Single Actor Serialization
+
+To perform single-actor serialization, first find the buffer size required to store the serialization data:
+
+\code
+size_t bufferSize = NvBlastActorGetSerializationSize( actor, nullptr );
+\endcode
+
+If you want to use an upper bound which will be large enough for any actor in a family, you may use:
+
+\code
+size_t bufferSize = NvBlastAssetGetActorSerializationSizeUpperBound( asset, nullptr );
+\endcode
+
+Then create a buffer of that size and use NvBlastActorSerialize to write to the buffer:
+
+\code
+std::vector<char> buffer( bufferSize );
+size_t bytesWritten = NvBlastActorSerialize( buffer, bufferSize, actor, nullptr );
+\endcode
+
+To deserialize the buffer, an appropriate family must be created.  It must not already hold a copy of the actor.  It must be formed
+using the correct asset (the one that originally created the actor):
+
+\code
+NvBlastFamily* family = NvBlastAssetCreateFamily( asset, malloc, nullptr );
+\endcode
+
+Then deserialize into the family:
+
+\code
+NvBlastActor* newActor = NvBlastFamilyDeserializeActor( family, buffer.data(), nullptr );
+\endcode
+
+If newActor is not NULL, then the actor was successfully deserialized.
+
+<br>
+\section actor_deactivating Deactivating an Actor
+
+Actors may not be released in the usual sense of deallocation.  This is because actors' memory is stored as a block within the owning family.  The
+memory is only released when the family is released.  However, one may deactivate an actor using NvBlastActorDeactivate.
+This clears the actor's chunk lists and marks it as invalid, effectively disassociating it from the family.  The user should consider this actor
+to be destroyed.
+
+\code
+bool success = NvBlastActorDeactivate( actor );	// actor should always be a pointer, as it is an opaque type
+\endcode
+
+<br>
+\subsection family_releasing Releasing a family
+
+As mentioned above, releasing an actor does not actually do any deallocation; it simply invalidates the actor within its family.
+To actually deallocate memory, you must deallocate the family.  Note, this will invalidate all actors in the family.  This is
+a fast way to delete all actors that were created from repeated fracturing of a single instance.  As with NvBlastAsse, memory is
+allocated by the user, so to release the family simply free that memory:
+
+\code
+free( family );
+\endcode
+
+The family will <em>not</em> be automatically released when all actors within it are invalidated using NvBlastActorDeactivate.  However, the user may keep track
+of the number of active actors in a family using
+
+\code
+uint32_t actorCount = NvBlastFamilyGetActorCount( family, nullptr );
+\endcode
+
+The result of the call above, actually a reference count for the family, is accurate even if actors are created and deleted from different threads.
+
+
+<br>
+\section splitting Damage and Fracturing
+
+Damaging and fracturing is a staged process. 
+In a first step, a \ref NvBlastDamageProgram creates lists of Bonds and Chunks to damage - so called Fracture Commands.
+The lists are created from input specific to the NvBlastDamageProgram.<br>
+NvBlastDamagePrograms are composed of a \ref NvBlastGraphShaderFunction and a
+\ref NvBlastSubgraphShaderFunction operating on support graphs (support chunks and bonds) and disconnected subsupport chunks respectively.
+An implementer can freely define the shader functions and paramters.
+Different functions can have the effect of emulating different physical materials.<br>
+Blast&tm; provides example implementations of such functions in \ref pageextshaders, see also NvBlastExtDamageShaders.h.
+The NvBlastDamageProgram is used through \ref NvBlastActorGenerateFracture that will provide the necessary internal data for the NvBlastActor being processed.
+The shader functions see the internal data as \ref NvBlastGraphShaderActor and \ref NvBlastSubgraphShaderActor respectively.
+
+The second stage is carried out with \ref NvBlastActorApplyFracture. This function takes the previously generated Fracture Commands and applies them to the NvBlastActor.
+The result of every applied command is reported as a respective Fracture Event if requested.
+
+Fracture Commands and Fracture Events both are represented by \ref NvBlastFractureBuffers.
+The splitting of the actor into child actors is not done until the third stage, \ref NvBlastActorSplit, is called.
+Fractures may be repeatedly applied to an actor before splitting.
+
+The \ref NvBlastActorGenerateFracture, \ref NvBlastActorApplyFracture and \ref NvBlastActorSplit functions are profiled in Profile configurations.
+This is done through a pointer to a NvBlastTimers struct passed into the functions.
+If this pointer is not NULL, then timing values will be accumulated in the referenced struct.
+
+The following example illustrates the process:
+
+\code
+// Step one: Generate Fracture Commands
+
+// Damage programs (shader functions), material properties and damage description relate to each other.
+// Together they define how actors will break by generating the desired set of Fracture Commands for Bonds and Chunks.
+NvBlastDamageProgram damageProgram = { GraphShader, SubgraphShader };
+NvBlastProgramParams programParams = { damageDescs, damageDescCount, materialProperties };
+
+// Generating the set of Fracture Commands does not modify the NvBlastActor.
+NvBlastActorGenerateFracture(fractureCommands, actor, damageProgram, &programParams, logFn, &timers);
+
+
+// Step two: Apply Fracture Commands
+
+// Applying Fracture Commands does modify the state of the NvBlastActor.
+// The Fracture Events report the resulting state of each Bond or Chunk involved.
+// Chunks fractured hard enough will also fracture their children, creating Fracture Events for each.
+NvBlastActorApplyFracture(fractureEvents, actor, fractureCommands, logFn, &timers);
+
+
+// Step three: Splitting
+
+// The Actor may be split into all its smallest pieces.
+uint32_t maxNewActorCount = NvBlastActorSplitMaxActorCount(actor);
+std::vector<NvBlastActor*> newActors(maxNewActorCount);
+
+// Make this memory available to NvBlastSplitEvent.
+NvBlastActorSplitEvent splitEvent;
+splitEvent.newActors = newActors.data();
+
+// Some temporary memory is necessary as well.
+std::vector<char> scratch(NvBlastActorGetRequiredScratchForSplit(actor));
+
+// New actors created are reported in splitEvent.newActors.
+// If newActorCount != 0, then the old actor is deleted and is reported in splitEvent.deletedActor.
+size_t newActorCount = NvBlastActorSplit(&splitEvent, actor, maxNewActorCount, scratch.data(), logFn, &timers);
+\endcode
+
+<br>
+*/
diff --git a/docs/_source/api_users_guide.txt b/docs/_source/api_users_guide.txt
new file mode 100644
index 0000000..f8ea9e9
--- /dev/null
+++ b/docs/_source/api_users_guide.txt
@@ -0,0 +1,22 @@
+/*! \page pageusersguide User's Guide
+
+Blast&tm; User's Guide
+
+\subpage pageintroduction
+
+\subpage pagellapi
+
+\subpage pagehlapi
+
+\subpage pageextapi
+
+\subpage pagetools
+
+\subpage pagesamples
+
+\subpage pagedefinitions
+
+\subpage pagecopyrights
+
+<br>
+*/
diff --git a/docs/_source/authoring_tool.txt b/docs/_source/authoring_tool.txt
new file mode 100644
index 0000000..602aa97
--- /dev/null
+++ b/docs/_source/authoring_tool.txt
@@ -0,0 +1,92 @@
+/*! \page pageauthoring AuthoringTool
+
+The application <b>AuthoringTool</b> is a command-line asset authoring utility.  It reads a file containing a single graphics mesh
+(currently .fbx and .obj format are supported in this tool), and fractures it according to the parameters given in the command line.
+User can configure output of tool. It can save render mesh geometry to .fbx or .obj file. 
+
+Additionally user can set how Blast data should be saved:
+
+	1) BPXA-asset which incorporates Blast data and collision geometry for physics engine. 
+
+	2) LL-asset which is Low Level asset data
+
+	3) Tk-asset which is Toolkit asset data
+
+BPXA and .obj files may be consumed by the \ref pagesampleassetviewer.
+
+
+\verbatim
+
+USAGE:
+
+   AuthoringTool  <infile> <output asset name> [--ovar <by default 0.0>] [--avar <by default 0.0>] [--slices <by default 1 1 1>] [--radius <by default 1.0>]
+                                      	       [--clusters <by default 5>][--cells <by default 5>] [--mode <v - voronoi, c - clustered voronoi, s - slicing.>] 
+											   [--block] [--proto]
+                                       	       [--fbx] [--obj] [--fbxascii]
+                                               [--ue4] [--ll] [--tk] [--bpxa]
+                                               [--outputDir <by default directory of the input file>] [--]
+                                               [--version] [-h]  
+
+
+Where:
+
+   Blast data output mode:
+
+  	 --bpxa output BPXA asset
+   	 --tk   output Toolkit asset
+  	 --ll   output Low Level asset
+
+   Blast data serialization mode:
+   
+	 --block - Serialize Blast asset as continuous block of memory	 
+	 --proto - Serialize Blast asset with CapnProto
+	 
+   Render mesh geometry output mode:
+
+	--fbx Output render mesh to .fbx file
+	--obj Output render mesh to .obj file
+	
+		   
+   --ue4 Enable output FBX with UE4 coordinate system	
+	
+   --ovar <by default 0.0>
+     Slicing offset variation
+
+   --avar <by default 0.0>
+     Slicing angle variation
+
+   --slices <by default 1 1 1>
+     Number of slices per direction
+
+   --clusters <by default 5>
+     Uniform Voronoi cluster count
+
+   --cells <by default 5>
+     Voronoi cells count
+
+   --mode <v - voronoi, c - clustered voronoi, s - slicing.>
+     Fracturing mode
+   
+   --radius <by default 0.5> 
+	 Cluster radius for clustered Voronoi fracturing mode.
+
+   --outputDir <output directory>
+	 Result output directory. If is not specified, result will be saved to folder with input file.
+
+
+   --,  --ignore_rest
+     Ignores the rest of the labeled arguments following this flag.
+
+   --version
+     Displays version information and exits.
+
+   -h,  --help
+     Displays usage information and exits.
+
+\endverbatim
+
+<br>
+See \ref pagecopyrights for license information regarding third-party software used by ApexImporter.
+
+<br>
+*/
diff --git a/docs/_source/copyrights.txt b/docs/_source/copyrights.txt
new file mode 100644
index 0000000..b3d38c3
--- /dev/null
+++ b/docs/_source/copyrights.txt
@@ -0,0 +1,33 @@
+/*! \page pagecopyrights Copyrights
+
+\section tinyobjloader TinyObjLoader
+
+Blast&tm; \ref pagesamples and the tool \ref pageimporter use TinyObjLoader by Syoyo Fudita.  This is licensed under the 2-clause BSD, given below.
+
+\verbatim
+Copyright (c) 2012-2015, Syoyo Fujita
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+\endverbatim
+
+<br>
+*/
diff --git a/docs/_source/data_converter.txt b/docs/_source/data_converter.txt
new file mode 100644
index 0000000..a197483
--- /dev/null
+++ b/docs/_source/data_converter.txt
@@ -0,0 +1,42 @@
+/*! \page pageconverter DataConverter
+
+\verbatim
+
+USAGE:
+
+   DataConverter  -i <infile> -o <outfile> [-v <outversion>] [--]
+                         [--version] [-h]
+
+Where:
+
+   -i <infile>,  --infile <infile>
+     (required)  Input binary file.
+
+   -o <outfile>,  --outfile <outfile>
+     (required)  Output binary file.
+
+   -v <outversion>,  --outversion <outversion>
+     Output binary block version. Pass -1 or ignore this parameter to
+     convert to latest version.
+
+   --,  --ignore_rest
+     Ignores the rest of the labeled arguments following this flag.
+
+   --version
+     Displays version information and exits.
+
+   -h,  --help
+     Displays usage information and exits.
+
+\endverbatim
+
+Blast&tm; low-level and Tk libraries will only load data in the most current format.  If your data is in an older format, you may use the \ref pageextconverterll API to convert to the current format.
+
+DataConverter.exe is a utility to convert Blast&tm; data from an older format into the current format.  The data must be stored in a binary-format file
+with filename given as the <infile> parameter.  It uses the \ref pageextconverterll API to perform the conversion.
+
+Currently, DataConverter only works on the low-level data formats for an asset (NvBlastAsset) and family (NvBlastFamily).  The .blast files used by
+SampleAssetViewer (see \ref pagesamples) may be converted using this tool.
+
+<br>
+*/
diff --git a/docs/_source/definitions.txt b/docs/_source/definitions.txt
new file mode 100644
index 0000000..f95e5a8
--- /dev/null
+++ b/docs/_source/definitions.txt
@@ -0,0 +1,14 @@
+/*! \page pagedefinitions Definitions
+
+- <b>exact coverage</b>: the condition that a walk from any leaf chunk to its ancestor root chunk will always encounter exactly one support chunk
+- <b>family</b>: the memory allocated when an asset is instanced into its initial set of actors, and all descendent actors formed from fracturing the initial set, recursively
+- <b>root chunk</b>: a chunk with no parent
+- <b>leaf chunk</b>: a chunk with no children
+- <b>lower-support chunk</b>: a chunk that is either a support or subsupport chunk
+- <b>subsupport chunk</b>: a chunk that is descended from a support chunk
+- <b>supersupport chunk</b>: a chunk that is the ancestor of a support chunk
+- <b>support chunk</b>: a chunk that is represented in the support graph
+- <b>upper-support chunk</b>: a chunk that is either a support or supersupport chunk
+
+<br>
+*/
diff --git a/docs/_source/ext_authoring.txt b/docs/_source/ext_authoring.txt
new file mode 100644
index 0000000..9b9cbf9
--- /dev/null
+++ b/docs/_source/ext_authoring.txt
@@ -0,0 +1,41 @@
+/*! \page pageextauthoring Asset Authoring (NvBlastExtAuthoring)
+
+Blast extensions provide tools for creation Blast asset from provided geometry mesh.
+
+There are three tools for creation Blast asset.
+
+First one is FractureTool which is used for fracturing input mesh. It supports Voronoi fracturing method and slicing.
+Internal surface of output chunks can be tesselated and noise can be applied to it. 
+Slicing method supports slicing with noisy slicing surface, which makes possible creation of jagged slicing line. Noisy slicing is switched on by 
+setting non-zero noise amplitude in slicing parameters.
+
+Nv::Blast::FractureTool supports two types of output:
+
+1) Array of triangles - tool fills provided array with triangles of chunk, ID of chunk should be provided.
+
+2) Buffered output - tool fills provided array with vertices, and another array of arrays with indices. Indices form triplets of vertices of triangle.
+
+Nv::Blast::ConvexMeshBuilder is tool for creation collision geometry for physics engine. It recieves mesh vertices, and returns convex hull of that vertices. If creation of convex hull fails,
+tool creates collision geometry as a bounding box of provided vertices.
+
+Tool provides method to trim convex hulls against each other. It can be used along with noisy slicing to avoid "explosive" behavior due to penetration of neighboor collision hulls into each other.
+As a drawback penetration of render meshes into each other is possible due to trimmed collision geometry. 
+
+
+Nv::Blast::BlastBondGenerator tool for creation Blast Bond descriptors from provided geometry data. 
+It has separate method which is optimized for working FractureTool. 
+\code
+	int32_t Nv::Blast::BlastBondGenerator::buildDescFromInternalFracture(FractureTool* tool, const std::vector<bool>& chunkIsSupport, std::vector<NvBlastBondDesc>& resultBondDescs, std::vector<NvBlastChunkDesc>& resultChunkDescriptors);
+\endcode
+
+Other methods can work with prefractured mesh created in Third party tool, and can be used for converting prefractured models to Blast assets.
+
+Nv::Blast::BlastBondGenerator supports two modes of NvBlastBond data generation:
+
+1) Exact - in this mode exact common surface between chunks is found and considered as interface between them. Exact normal, area and centroid are computed.
+
+2) Average - this mode uses approximations of interface, and can be used for gathering NvBlastBond data for assets, where chunks penetrate each other, e.g. chunks with noise.
+
+
+<br>
+*/
diff --git a/docs/_source/ext_converterll.txt b/docs/_source/ext_converterll.txt
new file mode 100644
index 0000000..e00a97a
--- /dev/null
+++ b/docs/_source/ext_converterll.txt
@@ -0,0 +1,38 @@
+/*! \page pageextconverterll Data Format Conversion Extension (NvBlastExtConverterLL)
+
+The low-level converter extension is a utility to convert NvBlastAsset and NvBlastFamily data from one format to another.
+
+The format version of an asset may be obtained using the function
+
+\code
+uint32_t assetVersion = NvBlastAssetGetFormatVersion(asset, logFn);
+\endcode
+
+and likewise the format version of a family may be obtained using the function
+
+\code
+uint32_t familyVersion = NvBlastAssetGetFormatVersion(family, logFn);
+\endcode
+
+If the format version does not match the SDK's current version for one of these objects, the data may not be used
+with the current SDK.  The NvBlastExtConverterLL extension will apply a chain of conversion functions to transform
+an asset or family from its stored version to any other version, provided that such a chain exists.
+
+To apply it, simply use the function convertDataBlock.  For example, given an asset pointer,
+
+\code
+vector<char> inBlock, outBlock;
+
+inBlock.resize( NvBlastAssetGetSize(asset), logFn );
+memcpy( inBlock.data(), asset, NvBlastAssetGetSize(asset) );
+
+if ( convertDataBlock(outBlock, inBlock) )
+{
+	NvBlastAsset* convertedAsset = outBlock.data();
+
+	// Use convertedAsset here
+}
+\endcode
+
+<br>
+*/
diff --git a/docs/_source/ext_import.txt b/docs/_source/ext_import.txt
new file mode 100644
index 0000000..40eafcc
--- /dev/null
+++ b/docs/_source/ext_import.txt
@@ -0,0 +1,22 @@
+/*! \page pageextapeximport Apex Import (NvBlastExtApexImport)
+
+Blast extensions provide Nv::Blast::ApexImporter::ApexImportTool, which can be used for converting APEX Destructible assets into Blast assets.
+
+This tool supports two bond generation modes and can be configured by providing: 
+\code
+struct ApexImporterConfig
+{
+	enum InterfaceSearchMode { EXACT, FORCED, MODE_COUNT };
+	InterfaceSearchMode infSearchMode;
+}
+\endcode
+
+1) EXACT - Importer tries to find triangles from two chunks which lay in common surface. If such triangles are found, their intersections are considered as the interface.
+
+2) FORCED - Bond creation is forced no matter how far chunks from each other. Interface parameters are approximated.
+
+Nv::Blast::ApexImporter::ApexImportTool can be itinialized by providing ApexSDK and ModuleDestructible, or they can be created internally.
+
+If ApexSDK and ModuleDestructible were provided, they are not freed when Nv::Blast::ApexImporter::~ApexImportTool() is called.
+<br>
+*/
diff --git a/docs/_source/ext_materials.txt b/docs/_source/ext_materials.txt
new file mode 100644
index 0000000..8a31e52
--- /dev/null
+++ b/docs/_source/ext_materials.txt
@@ -0,0 +1,41 @@
+/*! \page pageextshaders Damage Shaders (NvBlastExtShaders)
+
+Blast Extensions provide basic implementations of programs generating fracture commands, the first step in breaking a Blast&tm; Actor, see \ref splitting.
+These programs come as two shader functions (callbacks) for Actors with a support graph and Actors with just one chunk respectively.
+The NvBlastDamageProgram containing both shaders can be used for low-level directly (NvBlastActorGenerateFracture) or for TkActor's damage and fracture functions.
+
+\code
+	NvBlastDamageProgram damageProgram = { NvBlastExtShearGraphShader, NvBlastExtShearSubgraphShader };
+\endcode
+
+The appropriate shader will be called for an Actor being processed, along with the necessary Actor's geometry and program parameters. 
+The parameters (NvBlastProgramParams) are set to contain
+
+1. Material, something that describes an Actor properties (e.g. mass, stiffness, fragility) which are not expected to be changed often.
+	
+2. Damage description, something that describes a particular damage event (e.g. position, radius and force of explosion).
+
+\code
+	NvBlastExtMaterial material = { singleChunkThreshold, graphChunkThreshold, bondTangentialThreshold, bondNormalThreshold, damageAttenuation };
+	NvBlastExtRadialDamageDesc damageDesc = { compressive, posX, posY, posZ, minR, maxR };
+\endcode
+
+When used with TkActor::damage() functions, TkActor will cache the necessary data for deferred processing through TkGroup. This includes accumulating damage requests for
+the same material and program parameter combination. A default material can be set for a TkFamily that all its Actors uses.
+
+\code
+	tkGroup->addActor(*tkActor);
+	tkActor->damage(damageProgram, damageDesc0, sizeof(NvBlastExtRadialDamageDesc), &material);
+	tkActor->damage(damageProgram, damageDesc1, sizeof(NvBlastExtRadialDamageDesc), &material);
+	tkGroup->process();
+	tkGroup->sync();
+\endcode
+
+In contrast, the user is responsible for providing all the damage descriptions persisting through the low-level NvBlastActorGenerateFracture call when not using the Tk layer.
+
+\code
+	NvBlastProgramParams programParams = { damageDescs, 2, &material };
+	NvBlastActorGenerateFracture(commandBuffers, actor, damageProgram, &programParams, nullptr, nullptr);
+\endcode
+
+*/
diff --git a/docs/_source/ext_physx.txt b/docs/_source/ext_physx.txt
new file mode 100644
index 0000000..70a8e2e
--- /dev/null
+++ b/docs/_source/ext_physx.txt
@@ -0,0 +1,244 @@
+/*! \page pageextphysx PhysX Extensions
+
+NvBlastExtPhysX contains extensions for easier use of Blast Toolkit with the PhysX SDK.
+There are 3 of them:
+- <b>ExtPxManager</b>: Manager to keep Blast Actors in sync with PhysX actors.
+- <b>ExtImpactDamageManager</b>: Manager to collect and apply impact damage caused by collision in PhysX Scene.
+- <b>ExtStressSolver</b>: Stress Solver to propagate stress through support graph and apply it as damage to Blast actors.
+
+This library also contains an extension for synchronizing Blast state:
+- <b>ExtSync</b> - Utility for writing Blast state to a buffer, to be read by a client.  This may be used for networking, for example.
+
+
+<br>
+\section ExtPxManager
+
+<b>Physics Manager</b> - is a reference implementation for keeping Blast Actors synced with PhysX actors. It's main job is to listen
+for TkFamily events and update \a PxScene (by adding and removing PxActors) accordingly.
+
+In order to use it create ExtPxManager:
+
+\code
+ExtPxManager* pxManager = ExtPxManager::create(m_physics, m_tkFramework);
+\endcode
+
+For every \a TkAsset prepare \a ExtPxAsset. Which contains \a TkAsset + collection of physics geometry for every chunk. Every chunk can contain any number of subchunks.
+Where each subchunk is basically PxConvexMeshGeometry with transform. Also every chunk can be marked as static (\a isStatic flag). 
+If actor contains at least one static chunks in it's support graph it makes an actor kinematic (static), otherwise it's dynamic.
+Having zero subchunks makes chunk invisible in physics scene, it can be used for example to represent 'earth' as a special invisible static chunk and connect all near earth chunks to it.
+
+
+To create a \a ExtPxFamily from an \a ExtPxAsset:
+
+\code 
+ExtPxFamilyDesc familyDesc;
+familyDesc.pxAsset = pxAsset;
+familyDesc.group = tkGroup;
+familyDesc.actorDesc.initialBondHealths = nullptr;
+familyDesc.actorDesc.initialSupportChunkHealths = nullptr;
+familyDesc.actorDesc.uniformInitialBondHealth = BOND_HEALTH_MAX;
+familyDesc.actorDesc.uniformInitialLowerSupportChunkHealth = 1.0f;
+ExtPxFamily* family = pxManager->createFamily(desc);
+\endcode
+
+You can subscribe to family events in order to sync graphics (or anything else) with physics:
+
+\code
+family->subscribe(listener);
+\endcode
+
+Listener will be notified with all physics actors added and removed.
+
+And finally spawn the family in some world position (the first actor/actors will be created and event will be fired to the listener):
+
+\code 
+
+ExtPxSpawnSettings spawnSettings = {
+	&pxScene,
+	defaultPxMaterial,
+	RIGIDBODY_DENSITY
+};
+
+family->spawn(PxTransform(0, 0, 0), spawnSettings);
+\endcode
+
+You can get families actor's either from listening to events or by calling getActors(). 
+Every \a ExtPxActor matches 1 <-> 1 with TkActor (which matches \a NvBlastActor accordingly).
+
+\code
+ExtPxActor* actor = ....; 
+physx::PxRigidDynamic rigidDynamic = actor->getPxActor(); // 
+\endcode
+
+ExtPxActor remains internally unchanged through it's life time.
+Use \a ExtPxActor \a getChunkIndices() and  \a getPxActor() to update graphics representation. Sample code:
+
+\code
+	const uint32_t* chunkIndices;
+	size_t chunkIndexCount;
+	actor.getChunkIndices(chunkIndices, chunkIndexCount);
+	for (uint32_t i = 0; i < chunkIndexCount; i++)
+	{
+		uint32_t chunkIndex = chunkIndices[i];
+		for (Renderable* r : m_chunks[chunkIndex].renderables)
+		{
+			r->setTransform(actor.getPxActor()->getGlobalPose() * pxAsset.chunks[chunkIndex].convexes[0].transform);
+		}
+	}
+\endcode
+
+In order to use joints set joint create function with \a ExtPxManager::setCreateJointFunction(...). It will be called when new TkJoint's are
+being created. All the joint updates and remove will be handled by manager internally.
+
+<br>
+\section ExtImpactDamageManager
+
+<b>Impact Damage Manager</b> - is a reference implementation for fast and easy impact damage support. It's built on top of ExtPxManager.
+
+In order to use it create it:
+
+\code
+ExtImpactDamageManager* impactManager = ExtImpactDamageManager::create(pxManager);
+\endcode
+
+Call it's onContact method on every \a PxSimulationEventCallback \a onContact()
+
+\code
+	class EventCallback : public PxSimulationEventCallback
+	{
+	public:
+		EventCallback(ExtImpactDamageManager* manager) : m_manager(manager) {}
+
+		virtual void onContact(const PxContactPairHeader& pairHeader, const PxContactPair* pairs, uint32_t nbPairs)
+		{
+			m_manager->onContact(pairHeader, pairs, nbPairs);
+		}
+
+	private:
+		ExtImpactDamageManager*		m_manager;
+	};
+\endcode
+
+Call \a applyDamage() when you want the buffered damage to be applied:
+
+\code
+impactManager->applyDamage();
+\endcode
+
+Also important to enable contact notification with custom filter shader for PxScene. \a ImpactDamageManager has a reference filter shader 
+implementation which can be used for that:
+
+\code
+PxSceneDesc sceneDesc;
+sceneDesc.filterShader = ExtImpactDamageManager::FilterShader;
+\endcode
+
+<br>
+\section ExtStressSolver
+
+<b>Stress Solver</b> - is a reference implementation of stress propagation using Blast support graph. 
+
+\subsection Features Features
+- Supports both static and dynamic actors
+- Propagates both linear and angular momentum
+- Graph complexity selection (reduces support graph to smaller size trade off speed and quality)
+- Apply stress damage on Blast Actor
+- Debug Render
+
+\subsection Usage Usage
+
+In order to use it instance stress solver by providing \a ExtPxFamily:
+
+\code
+ExtStressSolver* stressSolver = ExtStressSolver::create(family);
+\endcode
+
+And then call update() every frame:
+
+\code
+bool doDamage = true; // if you want to actually apply stress and damage actors
+stressSolver->update(doDamage);
+\endcode
+
+By default it will apply scene gravity on static actors and centrifugal force on dynamic actors.
+Also applyImpulse(...) can be called for additional stress to apply:
+
+\code
+stressSolver->applyImpulse(actor, position, force);
+\endcode
+
+It fully utilizes the fact that it knows initial support graph structure and does maximum of processing 
+in \a create(...) method calls. After that all actors split calls are synced internally quite fast and only the actual
+stress propagation takes most of computational time. 
+Computational time is linearly proprtional to \a bondIterationsPerFrame setting. To fine tune look for balance 
+between \a bondIterationsPerFrame and \a graphReductionLevel . The more bond iterations
+are set the more precise computation will be. The smaller graph allows to make higher fidelity computations witihing 
+the same bond iterations per frame (same time spent), but actual cracks (damaged bonds) will be more sparsed as the result.
+
+
+<br>
+\section ExtSync
+
+<b>Synchronization Extension (NvBlastExtSync)</b> - is a reference implementation for synchronizing Blast state. 
+
+The idea is that you can use it to write synchronization events to the buffer (on server for example) and then apply this buffer on
+a client. TkFamily ID should be properly set for that.
+
+3 types of events are supported:
+
+- <b>ExtSyncEventType::Fracture</b>: Fracture event. Contains fracture commands information on particular TkFamily. Applied incrementally. Relatively small.
+- <b>ExtSyncEventType::FamilySync</b>: Family sync event. Contains all necessary information to fully sync TkFamily state.
+- <b>ExtSyncEventType::Physics</b>: Physics sync event. Contains all necessary information to fully sync ExtPxFamily state.
+
+In order to use it create ExtSync:
+
+\code
+ExtSync* sync = ExtSync::create();
+\endcode
+
+Then let ExtSync insatnce listen to family fracture commands and write them to internal buffer:
+
+\code
+TkFamily* family = ...;
+family->addListener(*sync);
+
+// fracture family
+// ....
+\endcode
+
+You can fully record TkFamily state or ExtPxFamily state at any moment by calling:
+
+\code
+sync->syncFamily(tkFamily);
+// or
+sync->syncFamily(pxFamily);
+\endcode
+
+Now you can take sync buffer:
+
+\code
+const ExtSyncEvent*const* buffer;
+uint32_t size;
+sync->acquireSyncBuffer(buffer, size);
+
+m_savedBuffer.resize(size);
+for (uint32_t i = 0; i < size; ++i)
+{
+	m_savedBuffer[i] = buffer[i]->clone();
+}
+
+sync->releaseSyncBuffer();
+\endcode
+
+On the client you can then apply this buffer:
+
+\code
+sync->applySyncBuffer(tkFramework, m_savedBuffer.data(), m_savedBuffer.size(), group, pxManager);
+\endcode
+
+ExtPxManager is required only if sync buffer contains ExtSyncEventType::Physics events.
+
+
+<br>
+
+*/
diff --git a/docs/_source/ext_serialization.txt b/docs/_source/ext_serialization.txt
new file mode 100644
index 0000000..cae31a2
--- /dev/null
+++ b/docs/_source/ext_serialization.txt
@@ -0,0 +1,6 @@
+/*! \page pageextserialization Serialization (NvBlastExtSerialization)
+
+TBD
+
+<br>
+*/
diff --git a/docs/_source/introduction.txt b/docs/_source/introduction.txt
new file mode 100644
index 0000000..e9fca5f
--- /dev/null
+++ b/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>
+*/
diff --git a/docs/_source/sample_asset_viewer.txt b/docs/_source/sample_asset_viewer.txt
new file mode 100644
index 0000000..dd8b64c
--- /dev/null
+++ b/docs/_source/sample_asset_viewer.txt
@@ -0,0 +1,154 @@
+/*! \page pagesampleassetviewer SampleAssetViewer
+
+The windows-specific <b>bin</b> subfolders contain the application SampleAssetViewer.exe.
+
+This application can load model file sets (.blast, .obj, .collision) that are generated by the \ref pageimporter or \ref pageauthoring tools.
+
+\section assetviewer_file_load Loading a Destructible Model
+
+To load a specific file set, make sure the .blast, .obj, and .collision files all have the same name (except for extension).  Then use the commandline options
+
+\verbatim
+-t PATHNAME -n ASSETNAME -p X Y Z -r AX AY AZ ANGLE
+\endverbatim
+
+Here, PATHNAME is the path to the directory containing the three (.blast, .obj, .collision) files.  ASSETNAME is the common name of those files.
+(X, Y, Z) is the translation to give to the actor that is created.  (AX, AY, AZ, ANGLE) is the rotation axis and angle (in degrees) to apply to the actor.
+
+\section assetviewer_multifile_load Loading Multiple Destructible Models
+
+To load multiple destructible models, use a config file.  The viewer reads .xml config files, which you can select using the command line argument
+
+\verbatim
+-x FILENAME
+\endverbatim
+
+Running the application with no commandline arguments, the viewer will load <b>samples/resources/configs/assets.xml</b> by default.  This file references
+the models in the subdirectories of <b>samples/resources/models</b>.
+
+\section using_assetviewer Using SampleAssetViewer
+
+Upon startup, the viewer will instance its first asset in its assets list.  Using the default assets.xml, this is a brick will.
+
+The menu is displayed using an overlay on the left side of the screen.  It is divided into many submenus, which are described below.
+
+In any scene, you may press <b>'F'</b> to fire a box into the scene in the direction the camer is pointing.
+
+You may also press <b>SPACE</b> to toggle between damage and drag mode.  (The mode is shown at the top of the screen.)  In drag mode, dynamic objects can be manipulated by
+placing the mouse cursor over them, and using <b>Left Mouse / Drag</b> to pull on the object.  In damage mode, <b>left-clicking</b> a destructible actor will apply damage to it.
+
+You may select between three different damage tools using the <b>1, 2, and 3</b> keys.  Each will color the damage sphere (shown at the mouse hit location) a different color:
+
+- (1) White - falloff damage.  Damage is applied everywhere within the sphere.
+- (2) Blue - cutter damage.  Damage is applied only near the surface of the sphere.
+- (3) Green - hierarchical damage.  Damage is passed down the chunk hierarchy with every damage application, sometimes leading to smaller chunks from an initial damage application.
+
+You may change the size of the damage sphere using the center mouse wheel, or the \ref viewer_damage_tool menu (see below).
+
+Right mouse button-drag to rotate the camera, and move using W, S, A, and D for forward, back, left, and right, respectively.  Q and E move the camera down and up, relative to the current orientation.
+
+Pressing 'R' will reset the scene.  Pressing 'P' toggles physical simulation.
+
+\section viewermenuitems Menu Items
+
+\subsection viewer_scene Scene
+
+Here you can select which assets to add to the scene, set the material damage properties, and enable a stress solver.
+
+In Replace mode (the default, set by radio button), selecting assets in the Assets list will remove all destructible actors from the scene and insert the selected one.
+In Append mode (the other radio button), selecting a new asset will insert its actor into the scene while keeping the others as well.
+
+You may also select actors in the Scene Actors list,  and remove (or reload) the actor using the buttons below the list.  Reloading an actor will restore it to its
+unfractured state.
+
+Note, in addition to destructible actors, the Scene Actors list shows the boxes that were fired into the scene using the 'F' key.  You may remove those using this
+UI as well.
+
+The Blast Material properties are used by the various damage tools available.
+
+- singleChunkThreadhold = the damage a single lower-support chunk must take in order to fracture
+- graphChunkThreshold = the damage a support chunk must take in order to fracture
+- bondNormalThreshold = the damage a bond must take using compressive (e.g. radial damage) in order to break
+- bondTangentialThreshold = the damage a bond must take using shear (e.g. from directional damage) in order to break
+- damageAttenuation = how fast damage falls off in the materal from an impact location
+
+A stress solver may be enabled by selcting the Stress Solver Enabled checkbox.  When enabled you will be presented with several options.  
+NOTE: you must then select the Stress Damage Enabled checkbox in order to allow stress to do damage to the actors in the scene.
+Bond Iterations Per Frame - is max amount of bonds allowed to be processed in one frame. The more this value the better quality of stress solver, but the time taken by it is increased linearly. You can 
+check this timing in \a Stats submenu. Using this value stress solver takes fixed amount of CPU time on asset of any size. So the more asset complex (the more bonds it has) the less total iterations (on all bonds) are made. 
+Use graph reduction level param to simplify stress graph for large assets. You can look at stress graph using by using \a Debug Render submenu.
+Stress linear and angular factors are corresponded for amount of damage to be applied on bonds from linear and angular momentum of stress on every bond.
+
+Replay control section allows to control recording and replaying Blast events. It demonstrates the usage of ExtSync extension. You may start/stop recording of blast events (damage, split). 
+If you toggle to sync initial actors once recording starts full blast state is saved.
+
+\subsection viewer_blast Blast
+
+Here you may disable or enable impact damage, using the Impact Damage checkbox (on by default).
+
+The Fragility setting is a multiplier that turns impact forces into damage amounts.
+
+You can toggle to pass impact damage to stress solver instead of just applying it with simple damage shader. Impact impulse will be passed to stress graph and damage will be applied
+accordingly to stress solver settings mentioned above.
+
+When dragging static actors (with mouse dragging tool) stress impulse is also applied on stress graph. Use Dragging To Stress Factor to tune the amount.
+
+You can limit rigid body count with next setting, all the actors created above this count will be ignored.
+
+\subsection viewer_damage_tool Damage Tool
+
+Here you may set the effect of the damage caused by the damage tool (left mouse click)
+
+- Compressive Damage = the amount of damage that will be applied to bonds using the normal component
+- Explosive Impulse = the radial impulse given to the fractured pieces
+- Damage Radius = the size of the damage tool (also settable using the mouse wheel)
+- Damage Profile = the damage function to use (equivalent to pressing the '1', '2', or '3' keys, see the section \ref using_assetviewer)
+
+\subsection viewer_stats Stats
+
+Here you will find various timers, counts, and sizes.  A running graph shows the frame time in ms.
+
+The "Last X" times shown at the end of this list record the time spent during the last damage or split calls.  These are broken down
+into sections, each contributing to the parent time.  "Child" function times are denoted by indentation.
+
+\subsection viewer_application Application
+
+Here you may pause the physics simulation (the same as pressing 'P') and reload shaders.
+
+\subsection viewer_debugrender Debug Render
+
+Here you may select wireframe rendering, which is useful for the various debug render options given.
+
+You may select the debug render options from the Blast Debug Render Mode dropdown.  Note: pressing 'I' will cycle through this menu:
+
+- Disabled = no debug rendering
+- Health Graph = draws bonds with color based upon bond health.  Green = full health, red = low health.
+- Centroids = draws a line segment starting at each bond centroid, pointing in the direction of the bond normal.  Also draws a square
+centered at the bond centroid, with the area of the bond.
+- Health Graph + Centroids = the two options above, combined.
+- Stress Graph = draws bonds with color based upon stress values.  Green = low stress, red = high stress.
+- Stress Graph + Nodes Impulse = same as Stress Graph plus a line segment indicating the impulse applied to each graph node.  The length of the segment is scaled by the Blast Debug Render Scale control.
+The green segments show the linear impulse, the red segments the rotational impulse.
+- Stress Graph + Bonds Impulse = same as Stress Graph plus a line segment indicating the impulse applied to each bond.  The length of the segment is scaled by the Blast Debug Render Scale control.
+The green segments show the linear impulse, the red segments the rotational impulse.
+
+\subsection viewer_physx PhysX
+
+This menu controls PhysX simulation parameters.  Here you may choose to use fixed time steps (off by default), and set the time step (if Use Fixed Timestep is checked) with the Fixed Timestep control.
+
+If a suitable GPU is available, GPU Physics may be enabled using the Use GPU Physics control.
+
+\subsection viewer_renderer Renderer
+
+Here you may change the lighting, shadow, and ambient occlusion (HBAO) options.
+
+\subsection viewer_hints_help Hints / Help
+
+Gives selected keyboard shortcuts.
+
+
+<br>
+See \ref pagecopyrights for license information regarding third-party software used by the samples.
+
+<br>
+*/
diff --git a/docs/_source/samples.txt b/docs/_source/samples.txt
new file mode 100644
index 0000000..56180e9
--- /dev/null
+++ b/docs/_source/samples.txt
@@ -0,0 +1,8 @@
+/*! \page pagesamples Samples
+
+The samples folder contains:
+
+\subpage pagesampleassetviewer
+
+<br>
+*/
diff --git a/docs/_source/tools.txt b/docs/_source/tools.txt
new file mode 100644
index 0000000..ffb3fc3
--- /dev/null
+++ b/docs/_source/tools.txt
@@ -0,0 +1,31 @@
+/*! \page pagetools Tools
+
+
+<br>
+See \ref pagecopyrights for license information regarding third-party software used by the tools.
+
+<br>
+
+\section importer Apex Importer
+
+Import Apex assets into Blast format.
+
+\subpage pageimporter
+
+
+\section converter Data Converter
+
+Convert serialized data from an old format to the current format.
+
+\subpage pageconverter
+
+
+\section authoring Authoring Tool
+
+Command line authoring tool.
+
+\subpage pageauthoring
+
+
+<br>
+*/