diff options
| author | Anton Novoselov <[email protected]> | 2017-08-01 12:53:38 +0300 |
|---|---|---|
| committer | Anton Novoselov <[email protected]> | 2017-08-01 12:53:38 +0300 |
| commit | 236f03c0b9a4982328ed1201978f7f69d192d9b2 (patch) | |
| tree | e486f2fa39dba203563895541e92c60ed3e25759 /docs/api_docs/files/pagellapi.html | |
| parent | Added screens to welcome page (diff) | |
| download | blast-236f03c0b9a4982328ed1201978f7f69d192d9b2.tar.xz blast-236f03c0b9a4982328ed1201978f7f69d192d9b2.zip | |
Blast 1.1 release (windows / linux)
see docs/release_notes.txt for details
Diffstat (limited to 'docs/api_docs/files/pagellapi.html')
| -rw-r--r-- | docs/api_docs/files/pagellapi.html | 256 |
1 files changed, 131 insertions, 125 deletions
diff --git a/docs/api_docs/files/pagellapi.html b/docs/api_docs/files/pagellapi.html index 1748161..3b3c19d 100644 --- a/docs/api_docs/files/pagellapi.html +++ b/docs/api_docs/files/pagellapi.html @@ -1,6 +1,6 @@ <html> <head> - <title>NVIDIA(R) Blast(R) SDK 1.0 API Reference: Low Level API (NvBlast)</title> + <title>NVIDIA(R) Blast(R) SDK 1.1 API Reference: Low Level API (NvBlast)</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <LINK HREF="NVIDIA.css" REL="stylesheet" TYPE="text/css"> </head> @@ -29,25 +29,26 @@ <br> <h2><a class="anchor" name="llintroduction"> Introduction</a></h2> -The low-level API is the core of Blast™ 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:<p> +The low-level API is the core of Blast™ 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, and <em>doesn't</em> have:<p> <ul> -<li>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 <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a> is an abstraction which is intended to correspond to a rigid body. However it is up to the user to make that connection. The <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a> references a list of visible chunk indices, which correspond to <a class="el" href="struct_nv_blast_chunk.html">NvBlastChunk</a> data in the asset. The <a class="el" href="struct_nv_blast_chunk.html">NvBlastChunk</a> 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™ does not manage them in any way.</li><li>There is no graphics representation. Just as there is no notion of collision geometry, there is no notion of graphics geometry either. The <a class="el" href="struct_nv_blast_chunk.html">NvBlastChunk</a> userData field (see the item above) can be used to associate graphics geometry with the actor based upon the visible chunks.</li><li>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™ guarantees that it is safe to operate on different actors from different threads.</li><li>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.</li><li>One form of serialization is simply handled as a memory copy. Data associated with an asset or family (see <a class="el" href="pagedefinitions.html">Definitions</a>) 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.</li><li>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.</li><li>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 <a class="el" href="pageextserialization.html">Serialization (NvBlastExtSerialization)</a>.)</li></ul> +<li>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 <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a> is an abstraction which is intended to correspond to a rigid body. However it is up to the user to implement that connection. The <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a> references a list of visible chunk indices, which correspond to <a class="el" href="struct_nv_blast_chunk.html">NvBlastChunk</a> data in the asset. The <a class="el" href="struct_nv_blast_chunk.html">NvBlastChunk</a> 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, but it is up to the user to create and manage physical joints between two actors.</li><li>There is no graphics representation. Just as there is no notion of collision geometry, there is also no notion of graphics geometry. The <a class="el" href="struct_nv_blast_chunk.html">NvBlastChunk</a> userData field (see the item above) can be used to associate graphics geometry with the actor based upon the visible chunks.</li><li>There is no notion of threading. The API is a collection of free functions which the user may call from appropriate threads. Blast™ guarantees that it is safe to operate on different actors from different threads.</li><li>There is no global memory manager, message handler, etc. All low-level API 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.</li><li>Backwards-compatible, versioned, device-independent serialization is not handled by Blast™. There <em>is<<em></em> > however a Blast™ extension which does, see <a class="el" href="pageextserialization.html">Serialization (NvBlastExtSerialization)</a>. However, a simple form of serialization may be performed on assets and familes (see <a class="el" href="pagedefinitions.html">Definitions</a>) via simple memory copy. The data associated with these objects is available to the user, and may be copied and stored by the user. There are Simply casting a pointer to such a block of memory to the correct object type will produce a usable object for Blast™. (The only restriction is that the block must be 16-byte aligned.) Families contain a number of actors and so this form of deserialization recreates all actors in the family. This form of serialization may be used between two devices which have the same endianness, and contain Blast™ SDKs which use the same object format.</em></li><li><em>Single-actor serialization and deserialization is, however, 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.</em></li></ul> <p> -<br> - <h2><a class="anchor" name="include_and_library"> +<em><br> + </em><h2><a class="anchor" name="include_and_library"> Linking and Header Files</a></h2> -To use the low-level Blast™ SDK, the application need only inlclude the header <a class="el" href="_nv_blast_8h.html">NvBlast.h</a>, 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<p> -NvBlast(config)(arch).(ext)<p> -(config) is DEBUG, CHECKED, OR PROFILE for the corresponding configurations. For a release configuration there is no (config) suffix.<p> -(arch) is _x86 or _x64 for Windows 32- and 64-bit builds, respectively, and empty for non-Windows platforms.<p> -(ext) is .lib for static linking and .dll for dynamic linking on Windows. On XBoxOne it is .lib, and on PS4 it is .a.<p> -<br> - <h2><a class="anchor" name="assets"> +<em> To use the low-level Blast™ SDK, the application need only inlclude the header <a class="el" href="_nv_blast_8h.html">NvBlast.h</a>, 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</em><p> +<em>NvBlast(config)(arch).(ext)</em><p> +<em>(config) is DEBUG, CHECKED, OR PROFILE for the corresponding configurations. For a release configuration there is no (config) suffix.</em><p> +<em>(arch) is _x86 or _x64 for Windows 32- and 64-bit builds, respectively, and empty for non-Windows platforms.</em><p> +<em>(ext) is .lib for static linking and .dll for dynamic linking on Windows. On XBoxOne it is .lib, and on PS4 it is .a.</em><p> +<em><br> + </em><h2><a class="anchor" name="assets"> Creating an Asset from a Descriptor (Authoring)</a></h2> -The <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a> is an opaque type pointing to an object constructed by Blast™ 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.<p> -<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 <a class="el" href="struct_nv_blast_chunk_desc.html#c5f6208f745fd4269c4a9b098297bf1b912c6007e1f18bab5eca228701183b3c">NvBlastChunkDesc::SupportFlag</a>). 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™ 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><p> -Example code is given below.<p> -<div class="fragment"><pre class="fragment">std::vector<NvBlastChunkDesc> chunkDescs; +<em> The <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a> is an opaque type pointing to an object constructed by Blast™ 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.</em><p> +<em><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 <a class="el" href="struct_nv_blast_chunk_desc.html#c5f6208f745fd4269c4a9b098297bf1b912c6007e1f18bab5eca228701183b3c">NvBlastChunkDesc::SupportFlag</a>). 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™ 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></em><p> +<em>Example code is given below. Throughout, we assume the user has defined a logging function called <b>logFn</b>, with the signature of NvBlastLog. In all cases, the log function is optional, and NULL may be passed in its place.</em><p> +<em><div class="fragment"><pre class="fragment"><span class="comment">// Create chunk descriptors</span> +std::vector<NvBlastChunkDesc> chunkDescs; chunkDescs.resize( chunkCount ); <span class="comment">// chunkCount > 0</span> chunkDescs[0].parentChunkIndex = UINT32_MAX; <span class="comment">// invalid index denotes a chunk hierarchy root</span> @@ -67,8 +68,9 @@ chunkDescs[1].volume = 1.0; <span class="comment">// Unit volume</span> chunkDescs[1].flags = <a class="code" href="struct_nv_blast_chunk_desc.html#c5f6208f745fd4269c4a9b098297bf1b912c6007e1f18bab5eca228701183b3c">NvBlastChunkDesc::SupportFlag</a>; <span class="comment">// This chunk should be represented in the support graph</span> chunkDescs[1].ID = 1; -<span class="comment">// ... etc.</span> +<span class="comment">// ... etc. for all chunks</span> +<span class="comment">// Create bond descriptors</span> std::vector<NvBlastBondDesc> bondDescs; bondDescs.resize( bondCount ); <span class="comment">// bondCount > 0</span> @@ -84,7 +86,11 @@ bondDescs[0].bond.m_centroid[2] = 3.f; bondDescs[0].m_userData = 0; <span class="comment">// this can be used to tell the user more information about this</span> <span class="comment">// bond for example to create a joint when this bond breaks</span> -<span class="comment">// ... etc.</span> +bondDescs[1].chunkIndices[0] = 1; +bondDescs[1].chunkIndices[1] = ~0; <span class="comment">// ~0 (UINT32_MAX) is the "invalid index." This creates a world bond</span> +<span class="comment">// ... etc. for bondDescs[1], all other fields are filled in as usual</span> + +<span class="comment">// ... etc. for all bonds</span> <span class="comment">// Set the fields of the descriptor</span> <a class="code" href="struct_nv_blast_asset_desc.html">NvBlastAssetDesc</a> assetDesc; @@ -95,45 +101,45 @@ assetDesc.<a class="code" href="struct_nv_blast_asset_desc.html#f9ee95aba486c075 <span class="comment">// Now ensure the support coverage in the chunk descriptors is exact, and the chunks are correctly ordered</span> std::vector<char> scratch( chunkCount * <span class="keyword">sizeof</span>(<a class="code" href="struct_nv_blast_chunk_desc.html">NvBlastChunkDesc</a>) ); <span class="comment">// This is enough scratch for both NvBlastEnsureAssetExactSupportCoverage and NvBlastReorderAssetDescChunks</span> -<a class="code" href="_nv_blast_8h.html#fd09f53fb71a1fb33053eebf1610367b">NvBlastEnsureAssetExactSupportCoverage</a>( chunkDescs.data(), chunkCount, scratch.data(), nullptr ); +<a class="code" href="_nv_blast_8h.html#fd09f53fb71a1fb33053eebf1610367b">NvBlastEnsureAssetExactSupportCoverage</a>( chunkDescs.data(), chunkCount, scratch.data(), logFn ); std::vector<uint32_t> map(chunkCount); <span class="comment">// Will be filled with a map from the original chunk descriptor order to the new one</span> -<a class="code" href="_nv_blast_8h.html#c61d3b9346765324a627b73803290373">NvBlastReorderAssetDescChunks</a>( chunkDescs.data(), chunkDescs, bondDescs.data(), bondCount, map, scratch.data(), nullptr ); +<a class="code" href="_nv_blast_8h.html#773ddce30d6fdeebf0a770dcc5fc1305">NvBlastReorderAssetDescChunks</a>( chunkDescs.data(), chunkCount, bondDescs.data(), bondCount, map, <span class="keyword">true</span>, scratch.data(), logFn ); <span class="comment">// Create the asset</span> scratch.resize( <a class="code" href="_nv_blast_8h.html#7517e528d4862b5e09853140bd4a2e46">NvBlastGetRequiredScratchForCreateAsset</a>( &assetDesc ) ); <span class="comment">// Provide scratch memory for asset creation</span> <span class="keywordtype">void</span>* mem = malloc( <a class="code" href="_nv_blast_8h.html#6b27b9cc240bef3481cbfa23f7051060">NvBlastGetAssetMemorySize</a>( &assetDesc ) ); <span class="comment">// Allocate memory for the asset object</span> -<a class="code" href="struct_nv_blast_asset.html">NvBlastAsset</a>* asset = <a class="code" href="_nv_blast_8h.html#8455859eec0e23e95aa5bbf7c4fd1e14">NvBlastCreateAsset</a>( mem, &assetDesc, scratch.data(), nullptr ); <span class="comment">// the log function (last argument) is optional</span> -</pre></div><p> -<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 <a class="el" href="pageextshaders.html">Damage Shaders (NvBlastExtShaders)</a>). 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.<p> -<br> - <h3><a class="anchor" name="asset_copying"> -Cloning an Asset (Serialization and Deserialization)</a></h3> -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 <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a>.<p> -<div class="fragment"><pre class="fragment">uint32_t assetSize = <a class="code" href="_nv_blast_8h.html#d7ee1d97ad6e4f048eab694249fa2594">NvBlastAssetGetSize</a>( data ); +<a class="code" href="struct_nv_blast_asset.html">NvBlastAsset</a>* asset = <a class="code" href="_nv_blast_8h.html#8455859eec0e23e95aa5bbf7c4fd1e14">NvBlastCreateAsset</a>( mem, &assetDesc, scratch.data(), logFn ); +</pre></div></em><p> +<em><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 <a class="el" href="pageextshaders.html">Damage Shaders (NvBlastExtShaders)</a>). 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.</em><p> +<em><br> + </em><h3><a class="anchor" name="asset_copying"> +Cloning an Asset</a></h3> +<em> To clone an asset, one only needs to copy the memory associated with the <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a>.</em><p> +<em><div class="fragment"><pre class="fragment">uint32_t assetSize = <a class="code" href="_nv_blast_8h.html#d7ee1d97ad6e4f048eab694249fa2594">NvBlastAssetGetSize</a>( asset ); -<a class="code" href="struct_nv_blast_asset.html">NvBlastAsset</a>* newAsset = (<a class="code" href="struct_nv_blast_asset.html">NvBlastAsset</a>*)malloc(assetSize); <span class="comment">// NOTE: the memory buffer <em> must <\em> be 16-byte aligned!</span> +<a class="code" href="struct_nv_blast_asset.html">NvBlastAsset</a>* newAsset = (<a class="code" href="struct_nv_blast_asset.html">NvBlastAsset</a>*)malloc(assetSize); <span class="comment">// NOTE: the memory buffer MUST be 16-byte aligned!</span> memcpy( newAsset, asset, assetSize ); <span class="comment">// this data may be copied into a buffer, stored to a file, etc.</span> -</pre></div><p> -N.B. the comment after the malloc call above. <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a> memory must be 16-byte aligned.<p> -<br> - <h3><a class="anchor" name="asset_releasing"> +</pre></div></em><p> +<em>N.B. the comment after the malloc call above. <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a> memory <b>must</b> be 16-byte aligned.</em><p> +<em><br> + </em><h3><a class="anchor" name="asset_releasing"> Releasing an Asset</a></h3> -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:<p> -<div class="fragment"><pre class="fragment">free( asset ); -</pre></div><p> -<br> - <h2><a class="anchor" name="actors_and_families"> +<em> 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 with memory allocate by <b>malloc</b> is simply done with a call to <b>free</b>:</em><p> +<em><div class="fragment"><pre class="fragment">free( asset ); +</pre></div></em><p> +<em><br> + </em><h2><a class="anchor" name="actors_and_families"> Creating Actors and Families</a></h2> -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.<p> -To create a family, use:<p> -<div class="fragment"><pre class="fragment"><span class="comment">// Allocate memory for the family object - this depends on the asset being represented by the family.</span> -<span class="keywordtype">void</span>* mem = malloc( <a class="code" href="_nv_blast_8h.html#b933a279e63545023464292bf7d562a1">NvBlastAssetGetFamilyMemorySize</a>( &asset ) ); +<em> 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. As with assets, family allocation is done by the user.</em><p> +<em>To create a family, use:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="comment">// Allocate memory for the family object - this depends on the asset being represented by the family.</span> +<span class="keywordtype">void</span>* mem = malloc( <a class="code" href="_nv_blast_8h.html#b933a279e63545023464292bf7d562a1">NvBlastAssetGetFamilyMemorySize</a>( asset, logFn ) ); -<a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family = <a class="code" href="_nv_blast_8h.html#868a59bb905879503d5e9a034cff247e">NvBlastAssetCreateFamily</a>( mem, &asset, <span class="keyword">nullptr</span> ); -</pre></div><p> -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:<p> -<div class="fragment"><pre class="fragment"><span class="comment">// Set the fields of the descriptor</span> +<a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family = <a class="code" href="_nv_blast_8h.html#868a59bb905879503d5e9a034cff247e">NvBlastAssetCreateFamily</a>( mem, asset, logFn ); +</pre></div></em><p> +<em>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:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="comment">// Set the fields of the descriptor</span> <a class="code" href="struct_nv_blast_actor_desc.html">NvBlastActorDesc</a> actorDesc; actorDesc.asset = asset; <span class="comment">// point to a valid asset</span> actorDesc.initialBondHealth = 1.0f; <span class="comment">// this health value will be given to all bonds</span> @@ -143,84 +149,84 @@ actorDesc.initialChunkHealth = 1.0f; <span class="comment">// this health value std::vector<char> scratch( <a class="code" href="_nv_blast_8h.html#730a6ea95065b53b9d9b65bde8cbb336">NvBlastFamilyGetRequiredScratchForCreateFirstActor</a>( &actorDesc ) ); <span class="comment">// Create the first actor</span> -<a class="code" href="struct_nv_blast_actor.html">NvBlastActor</a>* actor = <a class="code" href="_nv_blast_8h.html#6d774be820fc1ff7df4d2241df1db220">NvBlastFamilyCreateFirstActor</a>( family, &actorDesc, scratch.data(), nullptr ); <span class="comment">// ready to be associated with physics and graphics by the user</span> -</pre></div><p> -<br> - <h3><a class="anchor" name="actor_copying"> +<a class="code" href="struct_nv_blast_actor.html">NvBlastActor</a>* actor = <a class="code" href="_nv_blast_8h.html#6d774be820fc1ff7df4d2241df1db220">NvBlastFamilyCreateFirstActor</a>( family, &actorDesc, scratch.data(), logFn ); <span class="comment">// ready to be associated with physics and graphics by the user</span> +</pre></div></em><p> +<em><br> + </em><h3><a class="anchor" name="actor_copying"> Copying Actors (Serialization and Deserialization)</a></h3> -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.<p> -<br> - <h3><a class="anchor" name="family_serialization"> -Family Serialization</a></h3> -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:<p> -<div class="fragment"><pre class="fragment"><span class="keyword">const</span> <a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family = <a class="code" href="_nv_blast_8h.html#2d59048197fbddd4ba1ec575eef91b4d">NvBlastActorGetFamily</a>( &actor, <span class="keyword">nullptr</span> ); -</pre></div><p> -Then the size of the family may be obtained using:<p> -<div class="fragment"><pre class="fragment"><span class="keywordtype">size_t</span> size = <a class="code" href="_nv_blast_8h.html#f2316e686029f931812a3ddf11de6547">NvBlastFamilyGetSize</a>( family, <span class="keyword">nullptr</span> ); -</pre></div><p> -Now this memory may be copied, saved to disk, etc. To clone the family, for example, we can duplicate the memory:<p> -<div class="fragment"><pre class="fragment">std::vector<char> buffer( size ); +<em> There are two ways to copy NvBlastActors: cloning an <a class="el" href="struct_nv_blast_family.html">NvBlastFamily</a>, and single-actor serialization. Cloning an <a class="el" href="struct_nv_blast_family.html">NvBlastFamily</a> 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.</em><p> +<em><br> + </em><h3><a class="anchor" name="family_serialization"> +Cloning a Family</a></h3> +<em> To clone a family, use the family pointer which may be retrieved from any active actor in the family if needed, using the NvBlastActorGetFamily function:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keyword">const</span> <a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family = <a class="code" href="_nv_blast_8h.html#2d59048197fbddd4ba1ec575eef91b4d">NvBlastActorGetFamily</a>( &actor, logFn ); +</pre></div></em><p> +<em>Then the size of the family may be obtained using:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keywordtype">size_t</span> size = <a class="code" href="_nv_blast_8h.html#f2316e686029f931812a3ddf11de6547">NvBlastFamilyGetSize</a>( family, logFn ); +</pre></div></em><p> +<em>Now this memory may be copied, saved to disk, etc. To clone the family, for example, we can duplicate the memory:</em><p> +<em><div class="fragment"><pre class="fragment">std::vector<char> buffer( size ); <a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family2 = <span class="keyword">reinterpret_cast<</span><a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>*<span class="keyword">></span>( buffer.data() ); memcpy( family2, family, size ); -</pre></div><p> -<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:<p> -<div class="fragment"><pre class="fragment"><span class="keyword">const</span> NvBlastGUID guid = NvBlastFamilyGetAssetGUID( family2, <span class="keyword">nullptr</span> ); +</pre></div></em><p> +<em><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 ID, to help the user match the correct asset to the family. So one way of restoring the asset to the family follows:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keyword">const</span> NvBlastGUID guid = <a class="code" href="_nv_blast_8h.html#fa406b4fc35520001060b529ec95e820">NvBlastFamilyGetAssetID</a>( family2, logFn ); <span class="comment">// ... here the user must retrieve the asset using the GUID or by some other means</span> -<a class="code" href="_nv_blast_8h.html#fa4b1c5e96650587b8daabb5ab86d2f1">NvBlastFamilySetAsset</a>( family2, asset, <span class="keyword">nullptr</span> ); -</pre></div><p> -The data in family2 will contain the same actors as the original family. To access them, use:<p> -<div class="fragment"><pre class="fragment">uint32_t actorCount = <a class="code" href="_nv_blast_8h.html#88fd777ba36d4ad6c6d7a7913810c24d">NvBlastFamilyGetActorCount</a>( family2, <span class="keyword">nullptr</span> ); +<a class="code" href="_nv_blast_8h.html#fa4b1c5e96650587b8daabb5ab86d2f1">NvBlastFamilySetAsset</a>( family2, asset, logFn ); +</pre></div></em><p> +<em>The data in family2 will contain the same actors as the original family. To access them, use:</em><p> +<em><div class="fragment"><pre class="fragment">uint32_t actorCount = <a class="code" href="_nv_blast_8h.html#88fd777ba36d4ad6c6d7a7913810c24d">NvBlastFamilyGetActorCount</a>( family2, logFn ); std::vector<NvBlastActor*> actors( actorCount ); -uint32_t actorsWritten = <a class="code" href="_nv_blast_8h.html#eb9144660cd1dbdb4dc23720a3e542de">NvBlastFamilyGetActors</a>( actors.data(), actorCount, family2, nullptr ); -</pre></div><p> -In the code above, actorsWritten should equal actorCount.<p> -<br> - <h3><a class="anchor" name="single_actor_serialization"> +uint32_t actorsWritten = <a class="code" href="_nv_blast_8h.html#eb9144660cd1dbdb4dc23720a3e542de">NvBlastFamilyGetActors</a>( actors.data(), actorCount, family2, logFn ); +</pre></div></em><p> +<em>In the code above, actorsWritten should equal actorCount.</em><p> +<em><br> + </em><h3><a class="anchor" name="single_actor_serialization"> Single Actor Serialization</a></h3> -To perform single-actor serialization, first find the buffer size required to store the serialization data:<p> -<div class="fragment"><pre class="fragment"><span class="keywordtype">size_t</span> bufferSize = <a class="code" href="_nv_blast_8h.html#8a9c103d9113d83a21a004bbbcad7beb">NvBlastActorGetSerializationSize</a>( actor, <span class="keyword">nullptr</span> ); -</pre></div><p> -If you want to use an upper bound which will be large enough for any actor in a family, you may use:<p> -<div class="fragment"><pre class="fragment"><span class="keywordtype">size_t</span> bufferSize = <a class="code" href="_nv_blast_8h.html#2539b7a2f244a8f0c45d7020d1dfad63">NvBlastAssetGetActorSerializationSizeUpperBound</a>( asset, <span class="keyword">nullptr</span> ); -</pre></div><p> -Then create a buffer of that size and use NvBlastActorSerialize to write to the buffer:<p> -<div class="fragment"><pre class="fragment">std::vector<char> buffer( bufferSize ); -<span class="keywordtype">size_t</span> bytesWritten = <a class="code" href="_nv_blast_8h.html#cab7d192ec7ac6d3a095a6b0646375fe">NvBlastActorSerialize</a>( buffer, bufferSize, actor, <span class="keyword">nullptr</span> ); -</pre></div><p> -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):<p> -<div class="fragment"><pre class="fragment"><a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family = <a class="code" href="_nv_blast_8h.html#868a59bb905879503d5e9a034cff247e">NvBlastAssetCreateFamily</a>( asset, malloc, <span class="keyword">nullptr</span> ); -</pre></div><p> -Then deserialize into the family:<p> -<div class="fragment"><pre class="fragment"><a class="code" href="struct_nv_blast_actor.html">NvBlastActor</a>* newActor = <a class="code" href="_nv_blast_8h.html#38e8e96d5b62bf19dc3135603ed38240">NvBlastFamilyDeserializeActor</a>( family, buffer.data(), nullptr ); -</pre></div><p> -If newActor is not NULL, then the actor was successfully deserialized.<p> -<br> - <h2><a class="anchor" name="actor_deactivating"> +<em> To perform single-actor serialization, first find the buffer size required to store the serialization data:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keywordtype">size_t</span> bufferSize = <a class="code" href="_nv_blast_8h.html#8a9c103d9113d83a21a004bbbcad7beb">NvBlastActorGetSerializationSize</a>( actor, logFn ); +</pre></div></em><p> +<em>If you want to use an upper bound which will be large enough for any actor in a family, you may use:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keywordtype">size_t</span> bufferSize = <a class="code" href="_nv_blast_8h.html#2539b7a2f244a8f0c45d7020d1dfad63">NvBlastAssetGetActorSerializationSizeUpperBound</a>( asset, logFn ); +</pre></div></em><p> +<em>Then create a buffer of that size and use NvBlastActorSerialize to write to the buffer:</em><p> +<em><div class="fragment"><pre class="fragment">std::vector<char> buffer( bufferSize ); +<span class="keywordtype">size_t</span> bytesWritten = <a class="code" href="_nv_blast_8h.html#cab7d192ec7ac6d3a095a6b0646375fe">NvBlastActorSerialize</a>( buffer, bufferSize, actor, logFn ); +</pre></div></em><p> +<em>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):</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keywordtype">void</span>* mem = malloc( <a class="code" href="_nv_blast_8h.html#b933a279e63545023464292bf7d562a1">NvBlastAssetGetFamilyMemorySize</a>( asset, logFn ) ); +<a class="code" href="struct_nv_blast_family.html">NvBlastFamily</a>* family = <a class="code" href="_nv_blast_8h.html#868a59bb905879503d5e9a034cff247e">NvBlastAssetCreateFamily</a>( mem, asset, logFn ); +</pre></div></em><p> +<em>Then deserialize into the family:</em><p> +<em><div class="fragment"><pre class="fragment"><a class="code" href="struct_nv_blast_actor.html">NvBlastActor</a>* newActor = <a class="code" href="_nv_blast_8h.html#38e8e96d5b62bf19dc3135603ed38240">NvBlastFamilyDeserializeActor</a>( family, buffer.data(), logFn ); +</pre></div></em><p> +<em>If newActor is not NULL, then the actor was successfully deserialized.</em><p> +<em><br> + </em><h2><a class="anchor" name="actor_deactivating"> Deactivating an Actor</a></h2> -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.<p> -<div class="fragment"><pre class="fragment"><span class="keywordtype">bool</span> success = <a class="code" href="_nv_blast_8h.html#d7b368ffbf45a130d7b116530b81a77e">NvBlastActorDeactivate</a>( actor ); <span class="comment">// actor should always be a pointer, as it is an opaque type</span> -</pre></div><p> -<br> - <h3><a class="anchor" name="family_releasing"> +<em> 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.</em><p> +<em><div class="fragment"><pre class="fragment"><span class="keywordtype">bool</span> success = <a class="code" href="_nv_blast_8h.html#d7b368ffbf45a130d7b116530b81a77e">NvBlastActorDeactivate</a>( actor, logFn ); +</pre></div></em><p> +<em><br> + </em><h3><a class="anchor" name="family_releasing"> Releasing a family</a></h3> -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:<p> -<div class="fragment"><pre class="fragment">free( family ); -</pre></div><p> -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<p> -<div class="fragment"><pre class="fragment">uint32_t actorCount = <a class="code" href="_nv_blast_8h.html#88fd777ba36d4ad6c6d7a7913810c24d">NvBlastFamilyGetActorCount</a>( family, <span class="keyword">nullptr</span> ); -</pre></div><p> -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.<p> -<br> - <h2><a class="anchor" name="splitting"> +<em> 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 <a class="el" href="struct_nv_blast_asset.html">NvBlastAsset</a>, memory is allocated by the user, so to release a family with memory allocated by <b>malloc</b>, simply free that memory with <b>free</b>:</em><p> +<em><div class="fragment"><pre class="fragment">free( family ); +</pre></div></em><p> +<em>The family will <em>not</em> be automatically released when all actors within it are invalidated using NvBlastActorDeactivate. However, the user may query the number of active actors in a family using</em><p> +<em><div class="fragment"><pre class="fragment">uint32_t actorCount = <a class="code" href="_nv_blast_8h.html#88fd777ba36d4ad6c6d7a7913810c24d">NvBlastFamilyGetActorCount</a>( family, logFn ); +</pre></div></em><p> +<em><br> + </em><h2><a class="anchor" name="splitting"> Damage and Fracturing</a></h2> -Damaging and fracturing is a staged process. In a first step, a <a class="el" href="struct_nv_blast_damage_program.html">NvBlastDamageProgram</a> creates lists of Bonds and Chunks to damage - so called Fracture Commands. The lists are created from input specific to the <a class="el" href="struct_nv_blast_damage_program.html">NvBlastDamageProgram</a>.<br> - NvBlastDamagePrograms are composed of a <a class="el" href="_nv_blast_types_8h.html#f1fde0d45c48f0575e67f1df5860f940">NvBlastGraphShaderFunction</a> and a <a class="el" href="_nv_blast_types_8h.html#33a8ca70a1399b8b42a968c93f89ff50">NvBlastSubgraphShaderFunction</a> 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™ provides example implementations of such functions in <a class="el" href="pageextshaders.html">Damage Shaders (NvBlastExtShaders)</a>, see also <a class="el" href="_nv_blast_ext_damage_shaders_8h.html">NvBlastExtDamageShaders.h</a>. The <a class="el" href="struct_nv_blast_damage_program.html">NvBlastDamageProgram</a> is used through <a class="el" href="_nv_blast_8h.html#6a40c4286de500e8545babfb9c517789">NvBlastActorGenerateFracture</a> that will provide the necessary internal data for the <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a> being processed. The shader functions see the internal data as <a class="el" href="struct_nv_blast_graph_shader_actor.html">NvBlastGraphShaderActor</a> and <a class="el" href="struct_nv_blast_subgraph_shader_actor.html">NvBlastSubgraphShaderActor</a> respectively.<p> -The second stage is carried out with <a class="el" href="_nv_blast_8h.html#6a3d0ae6f5c5efb65699140897adb8c0">NvBlastActorApplyFracture</a>. This function takes the previously generated Fracture Commands and applies them to the <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a>. The result of every applied command is reported as a respective Fracture Event if requested.<p> -Fracture Commands and Fracture Events both are represented by <a class="el" href="struct_nv_blast_fracture_buffers.html">NvBlastFractureBuffers</a>. The splitting of the actor into child actors is not done until the third stage, <a class="el" href="_nv_blast_8h.html#dc280b2a624d76981c87fb5f068d5106">NvBlastActorSplit</a>, is called. Fractures may be repeatedly applied to an actor before splitting.<p> -The <a class="el" href="_nv_blast_8h.html#6a40c4286de500e8545babfb9c517789">NvBlastActorGenerateFracture</a>, <a class="el" href="_nv_blast_8h.html#6a3d0ae6f5c5efb65699140897adb8c0">NvBlastActorApplyFracture</a> and <a class="el" href="_nv_blast_8h.html#dc280b2a624d76981c87fb5f068d5106">NvBlastActorSplit</a> functions are profiled in Profile configurations. This is done through a pointer to a <a class="el" href="struct_nv_blast_timers.html">NvBlastTimers</a> struct passed into the functions. If this pointer is not NULL, then timing values will be accumulated in the referenced struct.<p> -The following example illustrates the process:<p> -<div class="fragment"><pre class="fragment"><span class="comment">// Step one: Generate Fracture Commands</span> +<em> Damaging and fracturing is a staged process. In a first step, a <a class="el" href="struct_nv_blast_damage_program.html">NvBlastDamageProgram</a> creates lists of Bonds and Chunks to damage - so called Fracture Commands. The lists are created from input specific to the <a class="el" href="struct_nv_blast_damage_program.html">NvBlastDamageProgram</a>.<br> + NvBlastDamagePrograms are composed of a <a class="el" href="_nv_blast_types_8h.html#f1fde0d45c48f0575e67f1df5860f940">NvBlastGraphShaderFunction</a> and a <a class="el" href="_nv_blast_types_8h.html#33a8ca70a1399b8b42a968c93f89ff50">NvBlastSubgraphShaderFunction</a> operating on support graphs (support chunks and bonds) and disconnected subsupport chunks respectively. An implementer can freely define the shader functions and parameters. Different functions can have the effect of emulating different physical materials.<br> + Blast™ provides reference implementations of such functions in <a class="el" href="pageextshaders.html">Damage Shaders (NvBlastExtShaders)</a>, see also <a class="el" href="_nv_blast_ext_damage_shaders_8h.html">NvBlastExtDamageShaders.h</a>. The <a class="el" href="struct_nv_blast_damage_program.html">NvBlastDamageProgram</a> is used through <a class="el" href="_nv_blast_8h.html#6a40c4286de500e8545babfb9c517789">NvBlastActorGenerateFracture</a> that will provide the necessary internal data for the <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a> being processed. The shader functions see the internal data as <a class="el" href="struct_nv_blast_graph_shader_actor.html">NvBlastGraphShaderActor</a> and <a class="el" href="struct_nv_blast_subgraph_shader_actor.html">NvBlastSubgraphShaderActor</a> respectively.</em><p> +<em>The second stage is carried out with <a class="el" href="_nv_blast_8h.html#6a3d0ae6f5c5efb65699140897adb8c0">NvBlastActorApplyFracture</a>. This function takes the previously generated Fracture Commands and applies them to the <a class="el" href="struct_nv_blast_actor.html">NvBlastActor</a>. The result of every applied command is reported as a respective Fracture Event if requested.</em><p> +<em>Fracture Commands and Fracture Events both are represented by <a class="el" href="struct_nv_blast_fracture_buffers.html">NvBlastFractureBuffers</a>. The splitting of the actor into child actors is not done until the third stage, <a class="el" href="_nv_blast_8h.html#dc280b2a624d76981c87fb5f068d5106">NvBlastActorSplit</a>, is called. Fractures may be repeatedly applied to an actor before splitting.</em><p> +<em>The <a class="el" href="_nv_blast_8h.html#6a40c4286de500e8545babfb9c517789">NvBlastActorGenerateFracture</a>, <a class="el" href="_nv_blast_8h.html#6a3d0ae6f5c5efb65699140897adb8c0">NvBlastActorApplyFracture</a> and <a class="el" href="_nv_blast_8h.html#dc280b2a624d76981c87fb5f068d5106">NvBlastActorSplit</a> functions are profiled in Profile configurations. This is done through a pointer to a <a class="el" href="struct_nv_blast_timers.html">NvBlastTimers</a> struct passed into the functions. If this pointer is not NULL, then timing values will be accumulated in the referenced struct.</em><p> +<em>The following example illustrates the process:</em><p> +<em><div class="fragment"><pre class="fragment"><span class="comment">// Step one: Generate Fracture Commands</span> <span class="comment">// Damage programs (shader functions), material properties and damage description relate to each other.</span> <span class="comment">// Together they define how actors will break by generating the desired set of Fracture Commands for Bonds and Chunks.</span> @@ -228,7 +234,7 @@ The following example illustrates the process:<p> <a class="code" href="struct_nv_blast_program_params.html">NvBlastProgramParams</a> programParams = { damageDescs, damageDescCount, materialProperties }; <span class="comment">// Generating the set of Fracture Commands does not modify the NvBlastActor.</span> -<a class="code" href="_nv_blast_8h.html#6a40c4286de500e8545babfb9c517789">NvBlastActorGenerateFracture</a>(fractureCommands, actor, damageProgram, &programParams, logFn, &timers); +<a class="code" href="_nv_blast_8h.html#6a40c4286de500e8545babfb9c517789">NvBlastActorGenerateFracture</a>( fractureCommands, actor, damageProgram, &programParams, logFn, &timers ); <span class="comment">// Step two: Apply Fracture Commands</span> @@ -236,28 +242,28 @@ The following example illustrates the process:<p> <span class="comment">// Applying Fracture Commands does modify the state of the NvBlastActor.</span> <span class="comment">// The Fracture Events report the resulting state of each Bond or Chunk involved.</span> <span class="comment">// Chunks fractured hard enough will also fracture their children, creating Fracture Events for each.</span> -<a class="code" href="_nv_blast_8h.html#6a3d0ae6f5c5efb65699140897adb8c0">NvBlastActorApplyFracture</a>(fractureEvents, actor, fractureCommands, logFn, &timers); +<a class="code" href="_nv_blast_8h.html#6a3d0ae6f5c5efb65699140897adb8c0">NvBlastActorApplyFracture</a>( fractureEvents, actor, fractureCommands, logFn, &timers ); <span class="comment">// Step three: Splitting</span> <span class="comment">// The Actor may be split into all its smallest pieces.</span> -uint32_t maxNewActorCount = NvBlastActorSplitMaxActorCount(actor); -std::vector<NvBlastActor*> newActors(maxNewActorCount); +uint32_t maxNewActorCount = <a class="code" href="_nv_blast_8h.html#c82609eb93afc9a8ab7011f2eb8f9a23">NvBlastAssetGetChunkCount</a>( asset, logFn ); <span class="comment">// In the worst case, one NvBlastActor may be created for every chunk in the asset</span> +std::vector<NvBlastActor*> newActors( maxNewActorCount ); <span class="comment">// Make this memory available to NvBlastSplitEvent.</span> <a class="code" href="struct_nv_blast_actor_split_event.html">NvBlastActorSplitEvent</a> splitEvent; splitEvent.<a class="code" href="struct_nv_blast_actor_split_event.html#68a98a5294eeab3684151324d6aa87a7" title="list of created actors">newActors</a> = newActors.data(); <span class="comment">// Some temporary memory is necessary as well.</span> -std::vector<char> scratch(<a class="code" href="_nv_blast_8h.html#8ecf1456b8fb626a4384fb82265a802d">NvBlastActorGetRequiredScratchForSplit</a>(actor)); +std::vector<char> scratch( <a class="code" href="_nv_blast_8h.html#8ecf1456b8fb626a4384fb82265a802d">NvBlastActorGetRequiredScratchForSplit</a>( actor, logFn ) ); <span class="comment">// New actors created are reported in splitEvent.newActors.</span> <span class="comment">// If newActorCount != 0, then the old actor is deleted and is reported in splitEvent.deletedActor.</span> -<span class="keywordtype">size_t</span> newActorCount = <a class="code" href="_nv_blast_8h.html#dc280b2a624d76981c87fb5f068d5106">NvBlastActorSplit</a>(&splitEvent, actor, maxNewActorCount, scratch.data(), logFn, &timers); -</pre></div><p> -<br> - </div> +<span class="keywordtype">size_t</span> newActorCount = <a class="code" href="_nv_blast_8h.html#dc280b2a624d76981c87fb5f068d5106">NvBlastActorSplit</a>( &splitEvent, actor, maxNewActorCount, scratch.data(), logFn, &timers ); +</pre></div></em><p> +<em><br> + </em></div> <!-- start footer part --> <div class="footer"> Copyright © 2015-2017 NVIDIA Corporation, 2701 San Tomas Expressway, Santa Clara, CA 95050 U.S.A. All rights reserved. <a href="http://www.nvidia.com ">www.nvidia.com</a> |