PHYSX NEWS PHYSX SDK
PROJECTS TABLE
GPU PHYSX
GAMES INFO
PHYSX
ARTICLES
PHYSX WIKI FORUM
РУССКИЙ ENGLISH


:: Back to news index ::

NVIDIA APEX 1.1 is available, GPU Rigid Bodies feature included

with 14 comments

NVIDIA has released APEX SDK 1.1 (Build 112), next version of NVIDIA APEX – scalable dynamics framework, oriented on complex physical simulations.

Update: APEX 1.2 is available

In comparison to APEX 1.0 Beta, new version includes many bugfixes, several additions to underlying framework and various new features, like ability to calculate rigid body physics on GPU.

APEX 1.1 contains only Destruction and Clothing modules, and is still based on PhysX SDK 2.8.4.6 – first version with PhysX 3 support is going to be APEX 1.2 (that is supposed to be released in a few months).

We must also note that APEX 1.1 requires corresponding authoring tools – PhysXLab 1.1 and 2.71 DCC plug-ins.

NVIDIA APEX SDK 1.1 is available for download at Developer Support Center.

If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.

Release Notes:

APEX DESTRUCTION 1.1

New Features

  • GPU Rigid Bodies: the NxModuleDestructible has settings to enable calculation of Rigid Body physics on GPU.

Highly anticipated feature. While using same assets and same settings, GPU Rigid Bodies are showing significantly higher performance – 70 fps for 5000+ rigid body chunks on single GTX 580 vs 10 fps on Core i7 2600K.

One-way interaction with dynamic CPU actors is also supported (via transfer of momentum). GPU accelerated rigid body physics requires NVIDIA driver 270.81 or later, PhysX 2.8.4 RC6 or later and a CUDA capable GPU.

  • Chunk instancing: (when authored to instance) correponding chunks between different destructible actors will be rendered using an instance buffer. This is advantageous if there are many destructible actors which reference the same asset.
  • Chunk tiling: (when authored to tile) matching chunks created from cutout fracturing will be instanced within the same actor, as well as other destructible actors which reference the same asset. This can drastically reduce the memory size of the asset.
  • NxDestructibleActor:
    • LOD setting sets the maximum chunk depth which can be fractured, implementing forcePhysicalLOD interface.
    • getChunkLinearVelocity and getChunkAngularVelocity API in the actor.
    • Per-actor materials in the actor descriptor.
    • Can specify a separate render mesh for static chunks which gets drawn in a single draw call, using the renderStaticChunksSeparately field in the actor descriptor
    • Can set a separate set of static materials used by the static mesh if renderStaticChunksSeparately is set.
    • minimumFractureDepth added to destructible parameters, to limit the size of the pieces that can be broken free.
    • Implements applyTransformation interface to geometrically transform an asset.
  • Fracture event callback now consolidates chunk information to reduce the number of fracture events reported.
  • NxActor (chunk island) FIFO can now be sorted by “benefit” (takes into account screen size and age of the chunk), so that less-beneficial chunks are removed first.
  • NxShape count limit can be set in addition to NxActor count.

Improvements

  • Chunk creation can be amortized over many frames.
  • Fracture processing can be amortized over many frames.
  • Conforms to new LOD system.
  • Removed the per-chunk thread locks, for better performance and resource usage.
  • SimpleDestruction has multiple sample scenes, loaded using the keys 1-7.

Bug Fixes

  • Damage reports are no longer issued when a destructible is set free using setDynamic().
  • Several crash bugs fixed.

Authoring Improvements

  • Ability to have multiple collision hulls per chunk.
  • Can cancel the fracture operation.
  • “Trim face hulls” option in cutout fracturing.
  • Ability to use multiple UV channels and color channels from FBX meshes
  • cookChunks does not use the internal ExplicitHierarchicalMesh any longer, only information passed in from the descriptor.

APEX CLOTHING 1.1

New Features

  • Per-Actor scaling. Each actor can have an individual scale and simulates properly.
  • Asynchronous cooking. When several actors with different per-actor scale are created, cooking will be delayed if another actor already started cooking. While waiting, actors will not be simulated.
  • Manual substepping: A PhysX scene that will run multiple substeps is now handled properly by clothing. Interpolated simulation meshes will be generated for each individual substep to remove simulation artifacts caused by substepping.
  • Teleport without reset: Clothing Actors can now be teleported without all the vertices being reset to the animated positions. This will only lead to good results if only the pose of the actor and not the state of the animation is changed.
  • Frozen state: Clothing can be frozen in a given state and will cease simulation. It can then be woken again in the same state. This contrasts the regular way where re-enabled clothing starts from the animated state instead.
  • Velocity Callback: A user callback that allows to read and write the velocity values of every simulated vertex. Can be used to play sound depending on certain changes in velocity or to implement i.e. a wind effect.
  • Support for morph targets (also known as blendshapes): At actor creation a set of vertex displacements can be used to modify the mesh.
  • Platform Tags: Each graphical LOD can have a list of strings attached. When converting the .apx/.apb files to a given platform, LODs that don’t match a certain pattern can be removed based on this.This allows for reducing asset size by removing LODs that are unsuited for a particular platform.
  • Correct Simulation Normals: Vertices that are on the border of the simulated and non-simulated part of the physical mesh can have wrongly calculated normals. This setting will try to correct for that.
  • Adaptive Target Frequency: Reduces the high frequency jittering that happens due to slightly varying timesteps.
  • Pressure: Closed cloth meshes can be filled with pressure.
  • Vertex Velocity Clamp: Adds a maximum velocity in all 6 major axis and clamps all velocities to those.

Improvements

  • Switching of graphical LoDs has been improved in respect to copying position and velocity from the old to the new simulation mesh.

Removed

  • Legacy serialization is gone. Any old .aca file cannot be loaded anymore. They need to be converted to .apx/.apb using the 1.0 ParamTool instead.
  • Some API marked as deprecated has been deleted such as NxClothingActor::setFlags().
  • Removed separate NxClothingMaterialLibrary (.acml files) as an asset type. Materials are now integrated into the Clothing Asset file directly.
  • Parallel physics mesh skinning and parallel mesh-mesh skinning. The frame delay that was introduced by this feature made it useless to most applications.

APEX FRAMEWORK

NxParameterized

  • New method Interface::clone.
  • Handles which are constructed from const Interfaces do not allow to change those Interfaces via setParamXxx.
  • Generic reference visitor NxParameterized::getReferences.
  • Streamed non-inplace binary deserialization.
  • Fixed handling of defaultValue in structs.
  • Fixed detection of hint types.
  • Automated versioning of legacy classes.
  • Customizable order of legacy objects upgrade instead of fixed bottom-up.
  • Custom alignments of struct fields.
  • ParamTool can now print summary of file contents.

Serialization

  • ParamTool does not support legacy asset formats anymore.
  • Changed some error codes.

Render Mesh Asset

  • setOverrideMaterial was added to allow switching of material directly at runtime.
  • Debug rendering vor vertex normals and tangents.

Use of Cuda 4.1

  • Necessary for supporting latest hardware.

P.S. We expect APEX 1.1 integration with UE3/UDK to be available in February 2012 release.

Written by Zogrim

February 15th, 2012 at 1:24 am

Posted in PhysX SDK, PhysX Tools

Tagged with , , , ,

14 Responses to 'NVIDIA APEX 1.1 is available, GPU Rigid Bodies feature included'

Subscribe to comments with RSS

  1. Highly anticipated feature. While using same assets and same settings, GPU Rigid Bodies are showing significantly higher performance – 70 fps for 5000+ rigid body chunks on single GTX 580 vs 10 fps on Core i7 2600K.”

    only 70fps on GTX 580!??? lol but I got min 181 fps at same setting while rigid body chunks are stopping after dropped running XP x86 SP3 with AMD X6 1055T@stock and GTX 480-285.58WHQL+PhysX sw 09.11.1107. because maybe XP x86 is much faster than Win 7 x64. :D

      

    nuninho1980

    15 Feb 12 at 7:58 pm

  2. nuninho1980: lol but I got min 181 fps at same setting

    Are you sure you’re using same settings ?

    Result was for SampleDestruction with “-hallmark -numActors=7″ parameters, not default scene in sample (which is using only 3 actors – 400 fps on GTX 580)

      

    Zogrim

    15 Feb 12 at 8:20 pm

  3. Zogrim: Are you sure you’re using same settings ?

    Result was for SampleDestruction with “-hallmark -numActors=7″ parameters, no default scene in sample (which is using only 3 actors – 400 fps on GTX 580)

    I ran this sample to default scene. I will try. ;)

      

    nuninho1980

    15 Feb 12 at 8:22 pm

  4. nuninho1980: I will try.

    I got min 58 fps (note: ignore min 48 fps due to stutter.) at “-hallmark -numActors=7″. and min 98 fps at “-hallmark -numActors=3″. Bin64 (Win 7 x64) is a bit faster than Bin32 (XP x86). :) but did you get 400 fps at “-hallmark -numActors=3″ on GTX 580!????

      

    nuninho1980

    16 Feb 12 at 5:44 pm

  5. nuninho1980: but did you get 400 fps at “-hallmark -numActors=3″ on GTX 580!????

    That was in initial scene of Sample (same one you’ve had 181 fps, as far as I undertood)

    After a closer look – it seems to have same number of actors as “-hallmark -numActors=3″, but runs faster. Maybe simulation settings are different, or different substeps are used, or whatever

      

    Zogrim

    16 Feb 12 at 7:16 pm

  6. Zogrim: That was in initial scene of Sample (same one you’ve had 181 fps, as far as I undertood)After a closer look – it seems to have same number of actors as “-hallmark -numActors=3″, but runs faster. Maybe simulation settings are different, or different substeps are used, or whatever

    I have 295.51beta+new PhysX sw 09.12.0203 and CPU AMD X6 1055T running Win 7 x64 – I got 58fps (91% GPU usage) at 7 actors and 98fps (90%). but does my CPU, GFX driver or other have issue?

      

    nuninho1980

    16 Feb 12 at 8:50 pm

  7. aah! sorry, 98fps at 3 actors.

      

    nuninho1980

    16 Feb 12 at 8:52 pm

  8. nuninho1980: I got 58fps (91% GPU usage) at 7 actors and 98fps at 3 actors (90%).

    Looks fine :)

      

    Zogrim

    16 Feb 12 at 8:57 pm

  9. Zogrim: Looks fine

    ;) I got 194fps on win7 x64 (181fps on XP) at initial scene.
    I think that you get 240fps at initial scene on GTX 580, ok?

      

    nuninho1980

    16 Feb 12 at 9:13 pm

  10. nuninho1980: I think that you get 240fps at initial scene on GTX 580, ok?

    Screenshot with fps is a few posts above.
    Below this point the discussion is closed.

      

    Zogrim

    16 Feb 12 at 9:25 pm

  11. Zogrim: Screenshot with fps is a few posts above.Below this point the discussion is closed.

    Sorry, I already saw your screenshot. Unfortunately, I can’t get insane performance at initial scene.
    Thank you.

      

    nuninho1980

    16 Feb 12 at 11:03 pm

  12. Have posted this on Nvidia forums..
    you know answer for some of this?
    1.Hi I’m a PhysX registered developer where I have access to physx Android builds and seems
    from both PhysX 3.2 release notes and searching web that some content (games) has shipped on IOS (ipad,iphone) with Physx usage.. so question are Physx Ios builds avaiable publicily? if not how to obtain it? or are avaiable to source code licensees (paid) only?

    2. Downloading Physx builds in licensee agreement I can see says something about CUDA accelerated physics on Win and Macos platforms so question is:
    There are plans for Physx GPU MacosX enabled builds (after all CUDA support is there)?
    if not why not? source licensees have that option?

    3. Now that APEX 1.1 is out makes me ask if there are plans for APEX builds for MacOS X.. better enable GPU support for MacOS and we will have even GPU rigid bodies on MacOS!!

      

    oscar

    20 Feb 12 at 1:50 pm

  13. oscar
    #1. Most PhysX games for iOS are based on Unity engine, and they have their own port. There is also special iOS version for mobile UE3/UDK. And some selected developers have access too.

    There is no public iOS build, and I would recommend to send a request to: PhysXLicensing@nvidia.com

    The last responce was: “We are working on a free binary iOS SDK but it is not ready yet”
    (Link)

    #2 and #3. There is no GPU acceleration on Mac OS currently, afaik, and I don’t know if/when it is going to be available.

      

    Zogrim

    20 Feb 12 at 2:33 pm

  14. Hey do you know where the settings for grb is inside of NxModuleDestructible.h ????? I cannot find it anywhere.

      

    digitaldemolition

    21 Oct 12 at 6:29 am


Leave a Reply

*
Copyright © 2009-2014. PhysXInfo.com | About PhysXInfo.com project | Privacy Policy
PhysX is trademark of NVIDIA Corporation