In APEX 1.2 every module had its own legacy module. For example, if an application uses APEX clothing and destruction, in APEX 1.2 the application would need to load both APEX_Clothing_Legacy and APEX_Destructible_Legacy.

However, assets created with APEX 1.1 or 1.2 should “just work” with APEX 1.3. The application must load the legacy module, which contains all the code that allows APEX to automatically upgrade assets to the latest version.

The rendering of destructibles and cloth can now be managed by a new object that is independent of the actors themselves. By default you will not see a change, but you may detach this object from the actors, meaning that the render data will not get deleted when the actors are deleted. You may delete the renderable when you’re done with it.

This is useful for multi-threaded renderers which may have the render data queued up even after the destructible or clothing actor is deleted in the main thread.

Speaking of Destruction, so called Behaviour Groups functionality was added to authoring pipeline.

Some common parameters, such as damage threshold, damage spread, density, etc., are now contained in “Behavior Groups“. Every chunk references a behavior group by index, allowing the user to customize behaviors for different chunks within single asset.

In addition, an updated Damage Spread system was introduced.

damageToRadius is no longer used for point and radius damage. Instead, new DamageSpreadFunction struct is used, which contains a minimumRadius, radiusMultiplier, and falloffExponent. It works as follows:

When damage is applied, it comes with a radius, which is zero for a point damage. That damage radius is multiplied by radiusMultiplier, and then added to minimumRadius – resulting value becomes what is called “maximumRadius”. Then, when applying the damage, every chunk up to minumumRadius takes the full damage, and chunks past the maximumRadius take zero damage. How the damage falls off between the minimumRadius and maximumRadius is determined by falloffExponent.

Finally, Destruction module now features a first iteration of the Real-Time Fracturing system.

This allows the fracture to occur in a more natural and detalized way, accordingly to the impact point and applied force. In APEX 1.3, only glass fracturing pattern is supported.

APEX Clothing module is now based on Improved Clothing Solver, introduced in PhysX SDK 3.3.0

Clothing assets now support self-collision, inter-colision between several different cloth actors (feature, not available in SDK 2.8 branch) and offer a limited ability to collide with scene objects.

In 1.3 version of the APEX Particles, several particle-related sub-modules (APEX_BasicFS, APEX_BasicIOS, APEX_Emitter, etc ) were merged into one APEX_Particles module. This greatly reduces the number of APEX DLLs that need to be shipped with a game and the amount of code necessary to load the modules.

New Effects Package entities can combine a collection of related Particle / Turbulence assets and actors which can be instantiated as a single actor and manipulated in real time.

A single EffectPackage might contain a number of emitters, a turbulence grid, a forcefield, a heat source, and some field samplers. Each of these effects can have different timing characteristics, such as a duration and loop counters. Each effect can have a parent relative transform so that when the root actor moves all children actors are revised accordingly.

APEX EffectPackage assets are authored using the ParticleEffectTool (PET). Also, EffectPackage actor can have a set of level of detail (LOD) optimizations applied to it

APEX SDK 1.3: Release Notes

APEX Framework 1.3

General

The legacy modules are all combined in one module, APEX_Legacy.

The particle modules are all combined in one module, APEX_Particles (with the exception of Turbulence).

The Wind module was removed.

The NxUserRenderBoneBufferDesc::maxBones member will now reflect the actual max bones specified in NxUserRenderResourceManager::getMaxBonesForMaterial().

APEX’s output stream will automatically be sent to PVD when the application is connected to PVD.

The outputStream member of the NxApexSDKDesc has been removed when using PhysX 3.x. APEX will automatically use the same output stream as PhysX.

APEX Destruction 1.3

New features

Render proxies for destructibles.

New damage detection (can be reverted to legacy behavior) – exact chunk collision volumes used for hit testing (point and radius damage). This gives better consistency when applying damage to destructibles at different LODs.

New damage spread.

Damage vertex coloring. This allows for some nice effects using multiple-texture shaders.

Damage depth limit: You can specify how many hierarchy depths deep fracturing may occur, relative to the chunk that takes the damage.

Better chunk deletion probability behavior. Debris chunks may be deleted with a user-supplied probability. Now the probability distribution is scaled by the damage taken by each chunk, and normalized. The result is that more chunks disappear near the damage point.

Limited real-time fracturing. Chunks with no child chunks can be real-time fractured now. In 1.3, only a glass fracture pattern is available.

A physical stress solver is available when using PhysX 3.3. Stresses are updated as a destructible structure is fractured, and when they exceed a user-specified limit, fracturing will occur at the highest stress points automatically.

More robust fracturing in PhysXLab. BSPs are stored and fractured at a normalized scale, with the output mesh scaled back to the appropriate world coordinates. The result is that many inexplicable errors (BSPs which looked perfect were generating holes and extra triangles) are now gone.

Scatter meshes – instanced meshes, randomly scattered about the surface of fractured chunks, rotated and scaled with respect to the surface normal within a range specified by the user.

Graphical noise on chunk faces with Voronoi fracturing.

Known Issues

Issue with improper reference counting when using setSkinnedOverrideMaterial, which could lead to APEX trying to release a resource that hasn’t been requested. Use setResource on the material to manually increment its reference count as a workaround.

If asyncFetchResults is false, the application must have more than one worker thread to avoid the possiblity of deadlock.

The RecomputeSubmeshes and RecomputeVertices visualization flags are not functional.

APEX Particles / Turbulence 1.3

New Features

Particle and field sampler modules including IOFX, Emitter, BasicIOS, ParticleIOS, and BasicFS have been merged into one “Particles” module. TurbulenceFS is still a separate module.

APEX now supports Effect Packages, a collection of particle-related assets that can be instantiated together in an applications. APEX provides the Particle Effect Tool for authoring.

APEX now requires Sprite and Instance Buffers implementations to specify their layout (NxRenderSpriteLayoutElement and NxRenderInstanceLayoutElement) by using semantic/format specification defined in corresponding enumerations.

Added Noise and Vortex Field Samplers in the BasicFS module (now in Particles module).

APEX Emitter Actor now provides an optional user emitter position validation callback (NxApexEmitterActor::setApexEmitterValidateCallback) used to allow the application to prevent particles from being emitted in invalid locations (for instance, on the other side of a wall).