Unfortunately, UDN documentation was not yet updated, and some flaws were found in this release - for example, APEX GPU Rigid Body libraries are missing from the February distribution. Not to mention, that not all APEX 1.1 features have made it into UDK.
UPDATE: March UDK is released. Issues with missing GRB libraries were resolved.
UPDATE #2: November 2012 release of UDK adds APEX 1.2.1 support
Let’s take a look on some of the new features in APEX 1.1 integration we were able to discover:
APEX DESTRUCTION 1.1:
For additional data on Destruction Module please refer to UDN page
- GPU Rigid Bodies (GRB). One of the most interesting features of 1.1 release is new ability to calculate rigid body physics on CUDA-capable GPUs, thus achieveing performance improvement in scenes with many destructible actors and simulated chunks, while using exact same assets and settings as for CPU physics.
----- Following is valid only for February 2012 UDK
As we have mentioned, current GRB implementation is missing vital libraries and also has some bugs: you can either wait until March UDK release or try it out now (for your own risk) – using our .dll package (36 mb).
Copy “GRB_1_x86.dll” and “pxtask_cuda_x86.dll” to “UDK\Binaries\Win32\” folder.
Copy “GRB_1_x64.dll” and “pxtask_cuda_x64.dll” to “UDK\Binaries\Win64\” folder.
---- Previous is only valid for February 2012 UDK
Now, to enable GRBs you need to set following parameters in “Engine\Config\BaseEngine.ini” file:
You may also want to tweak following settings:
ApexDestructionMaxChunkIslandCount – maximum number of simulated chunks.
ApexDestructionMaxShapeCount – each chunk could have multiple shapes, so you can limit those too.
ApexGRBGPUMemSceneSize – GPU memory allocated to store scene data (shapes, actors).
ApexGRBGPUMemTempDataSize – GPU memory allocated to store contacts and collision data.
Please note that GPU acceleration: #1 Is only working for Destructible assets, not regular UDK physics actors. #2 Is not effective in scenes with small amount of physical objects. #3 Supports only one-way interaction with CPU rigid bodies.
It is recommended to install latest GPU driver.
- New Sort by Benefit option defines how chunks are removed from the scene when resource budget is reached. Benefits calculation is based on screen size (which, itself, depends on size of the chunk/island and distance from the camera) and age of the chunk, not just relative lifetime, as before.
It is enabled by default:
Thus, enabling this option will prevent undesirable situations, when, for example, chunks dissapear in front of you as something gets destroyed in the background. New system will also preserve large chunk inslands and delete smaller insignificant chunks in the first place.
- Ability to have multiple collision hulls per chunk for better representation of objects with concave geometry.
PhysXLab 1.1 performs convex decomposition automatically, while complexity of physical mesh can be controlled by “Collision Quality” settings under “Asset” tab.
Increased collision quality can also help to avoid interpenetrations between chunks, but will consume more resources. But if your chunks are perfectly convex (for example, if Voronoi shattering is used), you can safely reduce quality to 1 or 2, in order to improve performance.
- Chunks instancing and tiling. Matching chunks created from cutout fracturing can be instanced within the same actor, as well as other destructible actors which reference the same asset – to speed up rendering.
Instancing option (it is located under “Graphics” tab) must be set during authoring process.
APEX CLOTHING 1.1:
For additional data on Clothing module please refer to UDN page
- Per-actor scaling. Each actor can now be scaled individually and simulated correspondingly.
- Asynchronous cooking. Cooking will be delayed if another actor already started cooking, in case if several actors with different per-actor scale are created. Actors will not be simulated during this process.
This option is also enabled by default:
- Adaptive Target Frequency reduces the high frequency jittering that happens due to slightly varying timesteps, by adapting the per-cloth gravity slightly.
Target frequency is computed as the average over the real last N (normally 60) simulation steps. Number of steps can be defined with following parameter:
We’ll update this page as more official information will be released.