APEX 1.4 requires PhysX 3.4 to build when build with PhysX.
To build the APEX projects in this distribution, the PhysX SDK path in the nxpath.vsprops files must be modified. The UpdatePhysXPaths.vbs script is provided for this purpose. It will modify the nxpath.vsprops files under the compiler folders. See the readme.txt at the top level of the APEX distribution for details.
We recommend at least Microsoft Visual Studio 2010 SP1 to build APEX.
APEX ships in four configurations: release, profile, checked, and debug.
Our recommendation when using PhysX 3.x is to develop with checked, profile with profile, and ship with release.
PhysX 3.x: APEX and PhysX 3.x contain shared code, so it is important that the configurations match. For example, if you link to the checked PhysX build you must also link to the checked APEX build.
| PhysX version | PhysX config | Use this APEX config |
|---|---|---|
| 3.x | release | release |
| 3.x | profile | profile |
| 3.x | checked | checked |
| 3.x | debug | debug |
APEX standard modules are only able to load the latest version of APEX assets. The legacy module (APEX_Legacy) is used for loading older versions of APEX assets. For example, the 1.2.0 version of APEX_Clothing can only load APEX 1.2.0 clothing assets, but APEX_Legacy can also load assets from APEX 1.1 or 1.0.
If you upgrade your APEX version during development, you should update all your APEX assets to the latest version before shipping your application. When you serialize an APEX asset it is automatically stored as the latest version, so upgrading is as simple as deserializing and serializing all APEX assets.
The legacy module is typically used during application development, but shouldn’t need to be shipped with the application.
For more information on serializing assets for specific platforms, see nxparam-serialization-label.
Typically your application should ship with the release configuration of APEX. An exception would be if you want to give end users the ability to author APEX assets, for example if you include a game editor with your game. In that case you would want to ship with the profile or checked configuration instead, because the release configuration strips out all authoring code.
You do not typically need to ship the legacy module at all.
You do not typically need to link every APEX library with your application. Here are the libraries you need to include with your application for each APEX feature. These examples list the Win32 DLLs, but substitute the equivalent name for your platform. For example, APEX_Clothing_x86.dll could be APEX_Clothing.a or APEX_Clothing.lib.
Clothing
Destructibles
APEX Particles (Windows only)
Turbulence (Windows only)
Force Fields (PhysX 3.x only)
If your application employs APEX modules that use CUDA and you have made local modifications to your APEX DLLs, you should use a GUID so that patches for new GPU architectures can be released for your application. You can obtain a GUID for your application from NVIDIA. If you do not pass your own GUID into APEX, when future patches are released you will get the default patched version of APEX, which could be problematic if you’ve modified APEX. Also, remember that you should also pass this same GUID to PhysX when you create the PhysX SDK and the CUDA Context Manager.
Give the application GUID to APEX through the nvidia::apex::ApexSDKDesc when creating the APEX SDK.
Give the application GUID to the CUDA Context Manager through the physx::PxCudaContextManagerDesc when creating the CUDA Context Manager.